Path: supernews.google.com!sn-xit-02!supernews.com!news-x.support.nl! newsfeeds.belnet.be!news.belnet.be!news.tele.dk!134.222.94.5! npeer.kpnqwest.net!EU.net!Norway.EU.net!uninett.no!ntnu.no!uio.no! hrotti.ifi.uio.no!ifi.uio.no!internet-mailinglist Newsgroups: fa.linux.kernel Return-Path: <linux-kernel-ow...@vger.kernel.org> X-Authentication-Warning: palladium.transmeta.com: mail set sender to n...@transmeta.com using -f To: linux-ker...@vger.kernel.org From: torva...@transmeta.com (Linus Torvalds) Subject: Linux-2.4.x patch submission policy Original-Date: 6 Jan 2001 10:17:02 -0800 Original-Message-ID: <937neu$p95$1@penguin.transmeta.com> Sender: linux-kernel-ow...@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Organization: Transmeta Corporation Date: Sat, 6 Jan 2001 18:18:28 GMT Message-ID: <fa.igetlbv.c2uj87@ifi.uio.no> Lines: 94 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 majord...@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Path: supernews.google.com!sn-xit-02!supernews.com!bignews.mediaways.net! newsfeeds.belnet.be!news.belnet.be!newsfeed.direct.ca!look.ca! newshub2.rdc1.sfba.home.com!news.home.com!newshub1-work.home.com! gehenna.pell.portland.or.us!nntp-server.caltech.edu!nntp-server.caltech.edu! mail2news96 Newsgroups: mlist.linux.kernel Subject: Re: Linux-2.4.x patch submission policy X-To: torva...@transmeta.com (Linus Torvalds) Date: Sat, 6 Jan 2001 19:33:22 +0000 (GMT) X-Cc: linux-ker...@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <linux.kernel.E14Ez5g-0001QJ-00@the-village.bc.nu> From: Alan Cox <a...@lxorguk.ukuu.org.uk> Approved: n...@nntp-server.caltech.edu Lines: 20 > 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 majord...@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
Path: supernews.google.com!sn-xit-02!supernews.com!sienna.impulse.net! newsxfer.interpacket.net!cyclone-sjo1.usenetserver.com!news-out.usenetserver.com! newshub2.rdc1.sfba.home.com!news.home.com!newshub1-work.home.com! gehenna.pell.portland.or.us!nntp-server.caltech.edu!nntp-server.caltech.edu! mail2news96 Newsgroups: mlist.linux.kernel Date: Sun, 7 Jan 2001 14:37:47 -0200 (BRDT) From: Rik van Riel <r...@conectiva.com.br> X-To: Linus Torvalds <torva...@transmeta.com> X-cc: linux-ker...@vger.kernel.org Subject: Re: Linux-2.4.x patch submission policy Message-ID: <linux.kernel.Pine.LNX.4.21.0101071434370.21675-100000@duckman.distro.conectiva> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved: n...@nntp-server.caltech.edu Lines: 33 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 majord...@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/