Re: Linux-2.4.x patch submission policy

Re: Linux-2.4.x patch submission policy

[Ingo Oeser]

On Sun, Jan 07, 2001 at 02:37:47PM -0200, Rik van Riel wrote:
> Once we are sure 2.4 is stable for just about anybody I
> will submit some of the really trivial enhancements for
> inclusion; all non-trivial patches I will maintain in a
> VM bigpatch, which will be submitted for inclusion around
> 2.5.0 and should provide one easy patch for those distribution
> vendors who think 2.4 VM performance isn't good enough for
> them ;)

Hmm, could you instead follow Andreas approach and have a
directory with little patches, that do _exactly_ one thing and a
file along to describe what is related, dependend and what each
patch does?

So people could try to suit them to their needs.

And they can tell you exactly _what_ change breaks instead of "It
doesn't work".

Thanks & Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<       come and join the fun       >>>>>>>>>>>>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Linux-2.4.x patch submission policy

[Rik van Riel]

On Mon, 8 Jan 2001, Ingo Oeser wrote:
> On Sun, Jan 07, 2001 at 02:37:47PM -0200, Rik van Riel wrote:
> > Once we are sure 2.4 is stable for just about anybody I
> > will submit some of the really trivial enhancements for
> > inclusion; all non-trivial patches I will maintain in a
> > VM bigpatch, which will be submitted for inclusion around
> > 2.5.0 and should provide one easy patch for those distribution
> > vendors who think 2.4 VM performance isn't good enough for
> > them ;)
> 
> Hmm, could you instead follow Andreas approach and have a
> directory with little patches, that do _exactly_ one thing and a
> file along to describe what is related, dependend and what each
> patch does?

I wasn't aware Andrea switched the way he stored his patches
lately ;)

But seriously, you're right that this is a good thing. I'll
work on splitting out my patches and documenting what each
part does.

(but not now, I'm headed off for Australia ... maybe I can
split out the patches on my way there and cvs commit when
I'm there)

OTOH, the advantage of having a big patch means that it's
easier for me to get people to test all of the things I
have. Guess I'll need to find a way to easily get both the
small and the big patches ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Linux-2.4.x patch submission policy

[Eric W. Biederman]

> > > vendors who think 2.4 VM performance isn't good enough for
> > > them ;)
> > 
> > Hmm, could you instead follow Andreas approach and have a
> > directory with little patches, that do _exactly_ one thing and a
> > file along to describe what is related, dependend and what each
> > patch does?
> 
> I wasn't aware Andrea switched the way he stored his patches
> lately ;)
> 
> But seriously, you're right that this is a good thing. I'll
> work on splitting out my patches and documenting what each
> part does.
> 
> (but not now, I'm headed off for Australia ... maybe I can
> split out the patches on my way there and cvs commit when
> I'm there)
> 
> OTOH, the advantage of having a big patch means that it's
> easier for me to get people to test all of the things I
> have. Guess I'll need to find a way to easily get both the
> small and the big patches ;)

What we have done with dosemu is provide a tar ball that unpacks
it's patches into a subdirectory, and a script that applies all of
the patches, and deletes the new useless subdirectory.

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Linux-2.4.x patch submission policy

[Roeland Th. Jansen]

On Mon, Jan 08, 2001 at 06:40:21PM -0200, Rik van Riel wrote:
> I wasn't aware Andrea switched the way he stored his patches
> lately ;)

he's doing that for quite some time now (for suse's kernels too) and
that works pretty well :-)
 
> OTOH, the advantage of having a big patch means that it's
> easier for me to get people to test all of the things I
> have. Guess I'll need to find a way to easily get both the
> small and the big patches ;)


the trouble with that is also that the whole patch must be checked again
and again if a new version is being sent out. Andrea's patches have th
epossibility to be applied for several versions and indeed are easy to
use -- apply what you want.

it made SMP testing more fun compared to the big patches where nobody
exactly knows what patch may have caused [in]stability.

I for instance have the daunting task to check why 2.4.0 here crashes so
easily without messages, except some occasional APIC error. yuck.
-- 
Grobbebol's Home                   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel       | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |        on Usenet.             _\_v  
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/