Linux-2.4.x patch submission policy

Linux-2.4.x patch submission policy

[Linus Torvalds]

I thought I'd mention the policy for 2.4.x patches so that nobody gets
confused about these things.  In some cases people seem to think that
"since 2.4.x is out now, we can relax, go party, and generally goof
off". 

Not so.

The linux kernel has had an interesting release pattern: usually the .0
release was actually fairly good (there's almost always _something_
stupid, but on the whole not really horrible).  And every single time so
far, .1 has been worse.  It usually takes until something like .5 until
it has caught up and surpassed the stability of .0 again. 

Why? Because there are a lot of pent-up patches waiting for inclusion,
that didn't get through the "we need to get a release out, that patch
can wait" filter.  So early on in the stable tree, some of those patches
make it.  And it turns out to be a bad idea. 

In an effort to avoid this mess this time, I have two guidelines:

 - I've basically thrown away all patches sent to me so far, and I will
   continue to do so at least over the weekend. I'm not going to bother
   thinking about patches for a few days.

 - In order for a patch to be accepted, it needs to be accompanied by
   some pretty strong arguments for the fact that not only is it really
   fixing bugs, but that those bugs are _serious_ and can cause real
   problems.

   Obviously, the size of the patch matters too: if you can make an
   obvious fix in 5 lines, do it.  Don't try to make a clean fix that
   fixes the problem the clever way in 150 lines. 

In short, releasing 2.4.0 does not open up the floor to just about
anything.  In fact, to some degree it will probably make patches _less_
likely to be accepted than before, at least for a while.  I want to be
absolutely convicned that the basic 2.4.x infrastructure is solid as a
rock before starting to accept more involved patches. 

Right now my ChangeLog looks like this:

 - Don't drop a megabyte off the old-style memory size detection
 - remember to UnlockPage() in ramfs_writepage()
 - 3c59x driver update from Andrew Morton

The first two are true one-liners that have already bitten some people
(not what I'd call a showstopper, but trivially fixable stuff that are
just thinkos).  The third one looks like a real fix for some rather
common hardware that could do bad things without it. 

Now, I'm sure that ChangeLog will grow.  There's the apparent fbcon bug
with MTRR handling that looks like a prime candidate already, and I'll
have people asking me for many many more.  But basically what I'm asking
people for is that before you send me a patch, ask yourself whether it
absolutely HAS to happen now, or whether it could wait another month.

Another way of putting it: if you have a patch, ask yourself what would
happen if it got left off the next RedHat/SuSE/Debian/Turbo/whatever
distribution CD.  Would it really be a big problem? If not, then I'd
rather spend the time _really_ beating on the patches that _would_ be a
big issue.  Things like security (_especially_ remote attacks), outright
crashes, or just totally unusable systems because it can't see the
harddisk. 

We'll all be happier if my ChangeLog is short and sweet, and if a 2.4.1
(tomorrow, in a week, in two, in a month, depending on what comes up)
actually ends up being _better_ than 2.4.0.  That would be a good new
tradition to start. 

And before you even bother asking about 2.5.x: it won't be opened until
I feel happy to pass on 2.4.x to somebody else (hopefully Alan Cox
doesn't feel burnt out and wants to continue to carry the torch and
feels ok with leaving 2.2.x behind by then).

Historically, that's been at least a few months.  In the 2.2.x series,
2.3.0 was the same as 2.2.8 with just the version changed - and it came
out in May, almost four months after 2.2.0.  In the 2.0.x series, 2.1.x
was based off 2.0.21, four and a half months after 2.0.0. 

Yes, I know this is boring, and all I'm asking is for people to not make
it any harder for me than they have to.  Think twice before sending me a
patch, and when you _do_ send me a patch, try to think like a release
manager and explain to me why the patch really makes sense to apply now. 

In short, I'm hoping for a fairly boring next few months. The more
boring, the better. 

		Thanks,

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux-2.4.x patch submission policy

[Alan Cox]

> rather spend the time _really_ beating on the patches that _would_ be a
> big issue.  Things like security (_especially_ remote attacks), outright
> crashes, or just totally unusable systems because it can't see the
> harddisk. 

In which case the priority should be fixing all the broken LFS support.

> Yes, I know this is boring, and all I'm asking is for people to not make
> it any harder for me than they have to.  Think twice before sending me a
> patch, and when you _do_ send me a patch, try to think like a release
> manager and explain to me why the patch really makes sense to apply now. 

Think of -ac as a way to get patches you need that everyone else might not
need yet, and a way to filter stuff. Im happy to take sane stuff Linus doesn't
(within reason) and propogate it on as (or more to the point if) it proves sane

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux-2.4.x patch submission policy (what about the -AC series?)

[Ben Greear]

Linus Torvalds wrote:
> 
> I thought I'd mention the policy for 2.4.x patches so that nobody gets
> confused about these things.  In some cases people seem to think that
> "since 2.4.x is out now, we can relax, go party, and generally goof
> off".
> 
> Not so.

Sounds like a perfectly valid argument to me.  Since Alan Cox's branch
seems to take on some of the more experimental stuff, perhaps it could
be used as an outlet for the pent-up patches untill 2.5 comes out?

Alan, could you elucidate your policy for accepting patches into the -ac
series?

Thanks,
Ben

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux-2.4.x patch submission policy

[Rik van Riel]

On 6 Jan 2001, Linus Torvalds wrote:

> In short, releasing 2.4.0 does not open up the floor to just
> about anything.  In fact, to some degree it will probably make
> patches _less_ likely to be accepted than before, at least for a
> while.

I think this is an excellent idea. To help with this I'll
gather all non-bug VM patches and combine them into a
special big patch periodically.

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 ;)

regards,

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

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Does reiserfs really meet the "Linux-2.4.x patch submission policy"?

[André Dahlqvist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1468 bytes --]

Hi Linus

I was very surprised when I checked my local kernel.org mirror this
morning, and noticed that the latest 2.4.1 pre-patch had grown to
~180 kb in size. I was even more surprised when I realized that the
inclusion of reiserfs was the reason for this. While I am certainly
happy for the reiserfs guys, I can't help but wondering if this really
had to happen for 2.4.1.

In my understanding of your "2.4.x patch sumission guidelines" these
large patches was exactly what you wanted to avoid at this point in
time. For example, isn't reiserfs to be considered a "more involved
patch" the way you described it in this e-mail:

On Sat, Jan 06, 2001 at 10:17:02AM -0800, Linus Torvalds wrote:

> In short, releasing 2.4.0 does not open up the floor to just about
> anything.  In fact, to some degree it will probably make patches _less_
> likely to be accepted than before, at least for a while.  I want to be
> absolutely convicned that the basic 2.4.x infrastructure is solid as a
> rock before starting to accept more involved patches. 

Don't get me wrong, I am personally really excited that reiserfs was
included. I just thought that you basically wanted 2.4.1 to be "boring".

I guess it's the "pushover and wimp" showing his face again:-)
-- 

André Dahlqvist <anedah-9@sm.luth.se>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Does reiserfs really meet the "Linux-2.4.x patch submission policy"?

[Linus Torvalds]

In article <20010116205558.A1171@sm.luth.se>,
=?us-ascii?Q?Andr=E9?= Dahlqvist  <anedah-9@sm.luth.se> wrote:
>
>Don't get me wrong, I am personally really excited that reiserfs was
>included. I just thought that you basically wanted 2.4.1 to be "boring".

Reiserfs inclusion in 2.4.1 was basically the plan for the very
beginning: it was so widely known that it was even reported in the
press, so I didn't even bother to point out reiserfs as a 2.4.1 patch. 

That said, I wanted to leave the window open for any showstopper bugs,
and have a pure "bug-fixes only" 2.4.1 if needed. I'm actually fairly
happy that there haven't been any really serious reports so far.

Inclusion of reiserfs is not going to add any bugs for the non-reiserfs
case (apart from a stupid merge issue, and now I've watched all the
non-reiserfs diffs with a microscope), so in that sense it's safe.
Peopel who would have used reiserfs anyway would have gotten more
problem reports, so..

If I were you, I'd worry more about the blk-patches from Jens, but
they've been around for a long time, and Alan also put them in his tree. 
Which makes them as safe as any patch we've seen.  So I took the
approach that "we'll obviously have to put this _somewhere_ in 2.4.x". 
But that is, at least to me, a potentially bigger worry than reiserfs. 

(Actually I'm not so much worried that the blk patches themselves would
have bugs, as worried about them showing bugs in block drivers by being
better at merging requests.  Those kinds of bugs we'll have to figure
out during 2.4.x anyway though, but it's a case of a latent bug maybe
showing up more easily under higher load generated by the blk fixes).

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Does reiserfs really meet the "Linux-2.4.x patch submission policy"?

[Aaron Lehmann]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Tue, Jan 16, 2001 at 08:55:58PM +0100, Andr? Dahlqvist wrote:
> I was very surprised when I checked my local kernel.org mirror this
> morning, and noticed that the latest 2.4.1 pre-patch had grown to
> ~180 kb in size. I was even more surprised when I realized that the
> inclusion of reiserfs was the reason for this.

On a related note, how about XFS? It certainly shouldn't go in before
the developers are ready, but I've been using it without any problems
for awhile now and await its inclusion in the mainstream kernel.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Does reiserfs really meet the "Linux-2.4.x patch submission policy"?

[Linus Torvalds]

On Tue, 16 Jan 2001, Aaron Lehmann wrote:
> On Tue, Jan 16, 2001 at 08:55:58PM +0100, Andr? Dahlqvist wrote:
> > I was very surprised when I checked my local kernel.org mirror this
> > morning, and noticed that the latest 2.4.1 pre-patch had grown to
> > ~180 kb in size. I was even more surprised when I realized that the
> > inclusion of reiserfs was the reason for this.
> 
> On a related note, how about XFS? It certainly shouldn't go in before
> the developers are ready, but I've been using it without any problems
> for awhile now and await its inclusion in the mainstream kernel.

Note that ResierFS really is a fairly special case: it's been one of the
main filesystems at SuSE for a longish time, and of the journalling
filesystems it's the only one I know of that is in major real production
use already, and has been for some time.

There's no question that there are other Journalling filesystems on the
horizon, but I'm not hearing anybody who can't do the patching themselves
who is interested in using it. Remember: one of the main criteria for
2.4.x inclusion was the "vendor would want it" part. If it's a "developers
might want to play with it" kind of thing, then it might as well live as
an external patch for a while.

For that reason, I would expect Ext3 to be the next filesystem to be
integrated, but I would _also_ expect that RedHat will actually integrate
it into their kernel _first_, and expect me to integrate it into the
standard kernel only afterwards.

But no, vendors aren't everything. And there are other vendors than just
SuSE and RedHat. So take all of the above with a pinch of salt. And
remember: these are just the 2.4.x rules - it's a different game when the
development kernel opens again, and "vendor wishes" are much less of an
issue when that happens. In the meantime, I see the stable kernel mainly
as a way to support vendors, and am thus always weighing things from that
angle when worrying about 2.4.x features.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/