* Release Policy [was: Linux 2.4.16 ] [not found] <Pine.LNX.4.21.0111261003070.13400-100000@freak.distro.cone ctiva> @ 2001-11-26 16:38 ` David Relson 2001-11-26 15:33 ` Marcelo Tosatti 0 siblings, 1 reply; 42+ messages in thread From: David Relson @ 2001-11-26 16:38 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml Marcelo, Thank you for stepping forward to be the maintainer of the 2.4 tree. This is a very valuable and important service for use Linux users. Also, thank you for releasing 2.4.16. I have it building on my linux box as I write this message :-) Over the last few days, there have been lots of messages regarding "Kernel Release" and "-preX vs. -rcX". You, as the official maintainer of kernel 2.4 are the person who actually creates the release policy and makes it happen. Would you care to share your thoughts on this matter? David At 07:30 AM 11/26/01, Marcelo Tosatti wrote: >Hi, > >Due to the corruption problems on 2.4.15, I'm releasing 2.4.16. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 16:38 ` Release Policy [was: Linux 2.4.16 ] David Relson @ 2001-11-26 15:33 ` Marcelo Tosatti 2001-11-26 17:14 ` David Relson ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Marcelo Tosatti @ 2001-11-26 15:33 UTC (permalink / raw) To: David Relson; +Cc: lkml On Mon, 26 Nov 2001, David Relson wrote: > Marcelo, > > Thank you for stepping forward to be the maintainer of the 2.4 tree. This > is a very valuable and important service for use Linux users. > > Also, thank you for releasing 2.4.16. I have it building on my linux box > as I write this message :-) > > Over the last few days, there have been lots of messages regarding "Kernel > Release" and "-preX vs. -rcX". You, as the official maintainer of kernel > 2.4 are the person who actually creates the release policy and makes it happen. > > Would you care to share your thoughts on this matter? Sorry for not being able to discuss this issues... Its just that I'm too busy doing the maintenance and other stuff at Conectiva at the same time (people are flooding me with patches, btw, please stop for a while). Daniel Quinlan suggested me to release a "pre-final" release before the real final one (which would catch most "stupid" bugs), and I think thats a nice way of solving the problem. I'll _probably_ do that --- not sure yet, though. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 15:33 ` Marcelo Tosatti @ 2001-11-26 17:14 ` David Relson 2001-11-26 21:15 ` Bill Davidsen 2001-11-26 17:22 ` Chris Meadors 2001-11-27 1:04 ` Andrew Morton 2 siblings, 1 reply; 42+ messages in thread From: David Relson @ 2001-11-26 17:14 UTC (permalink / raw) To: lkml At 12:22 PM 11/26/01, Chris Meadors wrote: >Aren't all the -pre's pre-finals? And what if there is a big bug found in >the -final, it will obviously be followed up with a -final-final? > >I like the ISC's release methods. The do -rc's (-pre's would be fine for >the kernel as it is already established), each -rc fixes problems found >with the previous. When an -rc has been out long enough with no more bug >reports they release that code, WITHOUT changes. > >-Chris Chris, I think of -pre releases as beta code - testable and likely broken. An -rc release would be "possibly broken". If problems are encountered, fix ONLY those problems to generate the next -rc. If it's O.K., then make it "final". David ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:14 ` David Relson @ 2001-11-26 21:15 ` Bill Davidsen 0 siblings, 0 replies; 42+ messages in thread From: Bill Davidsen @ 2001-11-26 21:15 UTC (permalink / raw) To: Linux Kernel Mailing List On Mon, 26 Nov 2001, David Relson wrote: > At 12:22 PM 11/26/01, Chris Meadors wrote: > > >Aren't all the -pre's pre-finals? And what if there is a big bug found in > >the -final, it will obviously be followed up with a -final-final? All the -pre's are before the final, but not release candidates. I think the rc until recently has been the one where someone said "we've put a hell of a lot of new stuff in this..." and concentrated on reported bugs, if any. > >I like the ISC's release methods. The do -rc's (-pre's would be fine for > >the kernel as it is already established), each -rc fixes problems found > >with the previous. When an -rc has been out long enough with no more bug > >reports they release that code, WITHOUT changes. > I think of -pre releases as beta code - testable and likely broken. An -rc > release would be "possibly broken". If problems are encountered, fix ONLY > those problems to generate the next -rc. If it's O.K., then make it "final". Other than some quibbling about nomenclature, that's how I see it. We always had an alpha version for in-house testing only, then a beta for selected users, which for Linux would be those who have the guts to run the downloads, and then a release. I did commenrcial software development for a few decades and that was usually the practice, and that's what people like Microsoft were doing when I did a few beta tests for them. I think it's a good model for Linux stable kernel series. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 15:33 ` Marcelo Tosatti 2001-11-26 17:14 ` David Relson @ 2001-11-26 17:22 ` Chris Meadors 2001-11-26 15:54 ` Marcelo Tosatti 2001-11-26 18:48 ` Bjoern A. Zeeb 2001-11-27 1:04 ` Andrew Morton 2 siblings, 2 replies; 42+ messages in thread From: Chris Meadors @ 2001-11-26 17:22 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: David Relson, lkml On Mon, 26 Nov 2001, Marcelo Tosatti wrote: > Sorry for not being able to discuss this issues... Its just that I'm too > busy doing the maintenance and other stuff at Conectiva at the same time > (people are flooding me with patches, btw, please stop for a while). > > Daniel Quinlan suggested me to release a "pre-final" release before the > real final one (which would catch most "stupid" bugs), and I think thats a > nice way of solving the problem. > > I'll _probably_ do that --- not sure yet, though. Aren't all the -pre's pre-finals? And what if there is a big bug found in the -final, it will obviously be followed up with a -final-final? I like the ISC's release methods. The do -rc's (-pre's would be fine for the kernel as it is already established), each -rc fixes problems found with the previous. When an -rc has been out long enough with no more bug reports they release that code, WITHOUT changes. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:22 ` Chris Meadors @ 2001-11-26 15:54 ` Marcelo Tosatti 2001-11-26 17:41 ` David Rees 2001-11-26 18:12 ` H. Peter Anvin 2001-11-26 18:48 ` Bjoern A. Zeeb 1 sibling, 2 replies; 42+ messages in thread From: Marcelo Tosatti @ 2001-11-26 15:54 UTC (permalink / raw) To: Chris Meadors; +Cc: David Relson, lkml On Mon, 26 Nov 2001, Chris Meadors wrote: > On Mon, 26 Nov 2001, Marcelo Tosatti wrote: > > > Sorry for not being able to discuss this issues... Its just that I'm too > > busy doing the maintenance and other stuff at Conectiva at the same time > > (people are flooding me with patches, btw, please stop for a while). > > > > Daniel Quinlan suggested me to release a "pre-final" release before the > > real final one (which would catch most "stupid" bugs), and I think thats a > > nice way of solving the problem. > > > > I'll _probably_ do that --- not sure yet, though. > > Aren't all the -pre's pre-finals? No. Just the -pre-final is a -pre-final. :) -pre-final basically means that this is the "candidate" release for the final. I could call it "candidate" or whatever (I don't really care about the name). > And what if there is a big bug found in the -final, it will obviously > be followed up with a -final-final? If people don't like the -pre-final name, I can call it "-candidate" as I said previously. > I like the ISC's release methods. The do -rc's (-pre's would be fine > for the kernel as it is already established), each -rc fixes problems > found with the previous. When an -rc has been out long enough with no > more bug reports they release that code, WITHOUT changes. Thats exactly the idea with the "pre-final" thingie. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 15:54 ` Marcelo Tosatti @ 2001-11-26 17:41 ` David Rees 2001-11-26 18:12 ` H. Peter Anvin 1 sibling, 0 replies; 42+ messages in thread From: David Rees @ 2001-11-26 17:41 UTC (permalink / raw) To: lkml On Mon, Nov 26, 2001 at 01:54:11PM -0200, Marcelo Tosatti wrote: > > > I like the ISC's release methods. The do -rc's (-pre's would be fine > > for the kernel as it is already established), each -rc fixes problems > > found with the previous. When an -rc has been out long enough with no > > more bug reports they release that code, WITHOUT changes. > > Thats exactly the idea with the "pre-final" thingie. Most groups use -rc release candidate releases, so using that instead of -pre-final would lead to the least confusion. A 2.4.17 release might look like this: Release 2.4.17-preX until all the new stuff you want is in. Release 2.4.17-rcX until no-one complains about the new stuff. Release the last 2.4.17-rcX as 2.4.17 and hope no one finds anything embarassing (which will probably happen anyway. Seems to me though, that you can simply put a note in your Changelog which -pre releases are bound to be to the next final revision, this will save us from yet another numbering scheme. -Dave ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 15:54 ` Marcelo Tosatti 2001-11-26 17:41 ` David Rees @ 2001-11-26 18:12 ` H. Peter Anvin 2001-11-26 18:29 ` David Weinehall 1 sibling, 1 reply; 42+ messages in thread From: H. Peter Anvin @ 2001-11-26 18:12 UTC (permalink / raw) To: linux-kernel Followup to: <Pine.LNX.4.21.0111261351160.13786-100000@freak.distro.conectiva> By author: Marcelo Tosatti <marcelo@conectiva.com.br> In newsgroup: linux.dev.kernel > > No. Just the -pre-final is a -pre-final. :) > > -pre-final basically means that this is the "candidate" release for the > final. > > I could call it "candidate" or whatever (I don't really care about the > name). > That's what a release candidate is. Expect the possibility that you might have more than one release candidate. The -rc scheme proposed seems very clean indeed. Oh, and yes, if you settle on a naming scheme, *please* let me know ahead of time so I can update the scripts to track it, rather than finding out by having hundreds of complaints in my mailbox... -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 18:12 ` H. Peter Anvin @ 2001-11-26 18:29 ` David Weinehall 2001-11-26 18:31 ` H. Peter Anvin 0 siblings, 1 reply; 42+ messages in thread From: David Weinehall @ 2001-11-26 18:29 UTC (permalink / raw) To: H. Peter Anvin; +Cc: linux-kernel On Mon, Nov 26, 2001 at 10:12:50AM -0800, H. Peter Anvin wrote: > Followup to: <Pine.LNX.4.21.0111261351160.13786-100000@freak.distro.conectiva> > By author: Marcelo Tosatti <marcelo@conectiva.com.br> > In newsgroup: linux.dev.kernel > > > > No. Just the -pre-final is a -pre-final. :) > > > > -pre-final basically means that this is the "candidate" release for the > > final. > > > > I could call it "candidate" or whatever (I don't really care about the > > name). > > > > That's what a release candidate is. Expect the possibility that you > might have more than one release candidate. > > The -rc scheme proposed seems very clean indeed. > > Oh, and yes, if you settle on a naming scheme, *please* let me know > ahead of time so I can update the scripts to track it, rather than > finding out by having hundreds of complaints in my mailbox... I for one used the -pre and -pre-final naming for the v2.0.39-series, and I'll probably use the same naming for the final pre-patch of v2.0.40, _unless_ there's some sort of agreement on another naming scheme. I'd be perfectly content with using the -rc naming for the final instead. The important thing is not the naming itself, but consistency between the different kernel-trees. Regards: David Weinehall _ _ // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 18:29 ` David Weinehall @ 2001-11-26 18:31 ` H. Peter Anvin 2001-11-26 17:25 ` Marcelo Tosatti 2001-11-26 21:18 ` Gregory Maxwell 0 siblings, 2 replies; 42+ messages in thread From: H. Peter Anvin @ 2001-11-26 18:31 UTC (permalink / raw) To: David Weinehall; +Cc: linux-kernel David Weinehall wrote: >> >>Oh, and yes, if you settle on a naming scheme, *please* let me know >>ahead of time so I can update the scripts to track it, rather than >>finding out by having hundreds of complaints in my mailbox... >> > > I for one used the -pre and -pre-final naming for the v2.0.39-series, > and I'll probably use the same naming for the final pre-patch of > v2.0.40, _unless_ there's some sort of agreement on another naming > scheme. I'd be perfectly content with using the -rc naming for the > final instead. The important thing is not the naming itself, but > consistency between the different kernel-trees. > Consistency is a Very Good Thing[TM] (says the one who tries to teach scripts to understand the naming.) The advantage with the -rc naming is that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, -pre-final-really-i-mean-it-this-time phenomenon when the release candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no shame in needing more than one release candidate. -hpa ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 18:31 ` H. Peter Anvin @ 2001-11-26 17:25 ` Marcelo Tosatti 2001-11-26 18:49 ` H. Peter Anvin ` (4 more replies) 2001-11-26 21:18 ` Gregory Maxwell 1 sibling, 5 replies; 42+ messages in thread From: Marcelo Tosatti @ 2001-11-26 17:25 UTC (permalink / raw) To: H. Peter Anvin; +Cc: David Weinehall, linux-kernel On Mon, 26 Nov 2001, H. Peter Anvin wrote: > David Weinehall wrote: > > >> > >>Oh, and yes, if you settle on a naming scheme, *please* let me know > >>ahead of time so I can update the scripts to track it, rather than > >>finding out by having hundreds of complaints in my mailbox... > >> > > > > I for one used the -pre and -pre-final naming for the v2.0.39-series, > > and I'll probably use the same naming for the final pre-patch of > > v2.0.40, _unless_ there's some sort of agreement on another naming > > scheme. I'd be perfectly content with using the -rc naming for the > > final instead. The important thing is not the naming itself, but > > consistency between the different kernel-trees. > > > > > Consistency is a Very Good Thing[TM] (says the one who tries to teach > scripts to understand the naming.) The advantage with the -rc naming is > that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, > -pre-final-really-i-mean-it-this-time phenomenon when the release > candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no > shame in needing more than one release candidate. Agreed. I stick with the -rc naming convention for 2.4+... ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:25 ` Marcelo Tosatti @ 2001-11-26 18:49 ` H. Peter Anvin 2001-11-26 19:00 ` François Cami ` (3 subsequent siblings) 4 siblings, 0 replies; 42+ messages in thread From: H. Peter Anvin @ 2001-11-26 18:49 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: David Weinehall, linux-kernel, Linus Torvalds, Alan Cox Marcelo Tosatti wrote: >> >>Consistency is a Very Good Thing[TM] (says the one who tries to teach >>scripts to understand the naming.) The advantage with the -rc naming is >>that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, >>-pre-final-really-i-mean-it-this-time phenomenon when the release >>candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no >>shame in needing more than one release candidate. >> > > Agreed. I stick with the -rc naming convention for 2.4+... > I have updated the kernel.org scripts to recognize the -rc naming convention. Any -rc patch found is assumed to be newer than any -pre patch found. I will try to add tracking of the v2.0 and v2.2 trees sometime later this week. -hpa ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:25 ` Marcelo Tosatti 2001-11-26 18:49 ` H. Peter Anvin @ 2001-11-26 19:00 ` François Cami 2001-11-26 19:06 ` Jonathan Lundell ` (2 subsequent siblings) 4 siblings, 0 replies; 42+ messages in thread From: François Cami @ 2001-11-26 19:00 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linux-kernel Marcelo Tosatti wrote: > Agreed. I stick with the -rc naming convention for 2.4+... Thanks a lot - much better that way. François ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:25 ` Marcelo Tosatti 2001-11-26 18:49 ` H. Peter Anvin 2001-11-26 19:00 ` François Cami @ 2001-11-26 19:06 ` Jonathan Lundell 2001-11-26 19:28 ` Flavio Stanchina 2001-11-26 19:36 ` David Weinehall 2001-11-26 20:39 ` junio 4 siblings, 1 reply; 42+ messages in thread From: Jonathan Lundell @ 2001-11-26 19:06 UTC (permalink / raw) To: linux-kernel At 3:25 PM -0200 11/26/01, Marcelo Tosatti wrote: > > Consistency is a Very Good Thing[TM] (says the one who tries to teach >> scripts to understand the naming.) The advantage with the -rc naming is >> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, >> -pre-final-really-i-mean-it-this-time phenomenon when the release >> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no >> shame in needing more than one release candidate. > >Agreed. I stick with the -rc naming convention for 2.4+... A quibble: "release" seems an odd word to choose for a Linux kernel. Since we're calling the target kernel "final", how about -fc1, -fc2...? -- /Jonathan Lundell. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 19:06 ` Jonathan Lundell @ 2001-11-26 19:28 ` Flavio Stanchina 2001-11-26 19:43 ` Jonathan Lundell 0 siblings, 1 reply; 42+ messages in thread From: Flavio Stanchina @ 2001-11-26 19:28 UTC (permalink / raw) To: linux-kernel On Monday 26 November 2001 20:06, Jonathan Lundell wrote: > >Agreed. I stick with the -rc naming convention for 2.4+... > A quibble: "release" seems an odd word to choose for a Linux kernel. > Since we're calling the target kernel "final", how about -fc1, > -fc2...? Sounds a bit too much like the f-word. "rc" is the universally recognized name for such things (heck, even Microsoft) so I'd stick with it. -- Ciao, Flavio Stanchina Trento - Italy "The best defense against logic is ignorance." http://spazioweb.inwind.it/fstanchina/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 19:28 ` Flavio Stanchina @ 2001-11-26 19:43 ` Jonathan Lundell 0 siblings, 0 replies; 42+ messages in thread From: Jonathan Lundell @ 2001-11-26 19:43 UTC (permalink / raw) To: linux-kernel At 8:28 PM +0100 11/26/01, Flavio Stanchina wrote: >On Monday 26 November 2001 20:06, Jonathan Lundell wrote: > >> >Agreed. I stick with the -rc naming convention for 2.4+... >> A quibble: "release" seems an odd word to choose for a Linux kernel. >> Since we're calling the target kernel "final", how about -fc1, >> -fc2...? > >Sounds a bit too much like the f-word. > >"rc" is the universally recognized name for such things (heck, even >Microsoft) so I'd stick with it. So in a choice between sex, love and Microsoft, we choose Microsoft? I'm more used to -fc, myself; in fact I was unfamiliar with -rc. But if Microsoft uses -rc, by all means, let's follow suit. ;-) -- /Jonathan Lundell. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:25 ` Marcelo Tosatti ` (2 preceding siblings ...) 2001-11-26 19:06 ` Jonathan Lundell @ 2001-11-26 19:36 ` David Weinehall 2001-11-26 20:39 ` junio 4 siblings, 0 replies; 42+ messages in thread From: David Weinehall @ 2001-11-26 19:36 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: H. Peter Anvin, linux-kernel On Mon, Nov 26, 2001 at 03:25:24PM -0200, Marcelo Tosatti wrote: > > > On Mon, 26 Nov 2001, H. Peter Anvin wrote: > > > David Weinehall wrote: > > > > >> > > >>Oh, and yes, if you settle on a naming scheme, *please* let me know > > >>ahead of time so I can update the scripts to track it, rather than > > >>finding out by having hundreds of complaints in my mailbox... > > >> > > > > > > I for one used the -pre and -pre-final naming for the v2.0.39-series, > > > and I'll probably use the same naming for the final pre-patch of > > > v2.0.40, _unless_ there's some sort of agreement on another naming > > > scheme. I'd be perfectly content with using the -rc naming for the > > > final instead. The important thing is not the naming itself, but > > > consistency between the different kernel-trees. > > > > > > > > > Consistency is a Very Good Thing[TM] (says the one who tries to teach > > scripts to understand the naming.) The advantage with the -rc naming is > > that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, > > -pre-final-really-i-mean-it-this-time phenomenon when the release > > candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no > > shame in needing more than one release candidate. > > Agreed. I stick with the -rc naming convention for 2.4+... Ok, then I'll do likewise. Linus, Alan? Regards: David Weinehall _ _ // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:25 ` Marcelo Tosatti ` (3 preceding siblings ...) 2001-11-26 19:36 ` David Weinehall @ 2001-11-26 20:39 ` junio 2001-11-26 20:55 ` David Weinehall 4 siblings, 1 reply; 42+ messages in thread From: junio @ 2001-11-26 20:39 UTC (permalink / raw) To: Marcelo Tosatti, Alan Cox, David Weinehall; +Cc: H. Peter Anvin, linux-kernel >>>>> "MT" == Marcelo Tosatti <marcelo@conectiva.com.br> writes: MT> On Mon, 26 Nov 2001, H. Peter Anvin wrote: >> Consistency is a Very Good Thing[TM] (says the one who tries to teach >> scripts to understand the naming.) The advantage with the -rc naming is >> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, >> -pre-final-really-i-mean-it-this-time phenomenon when the release >> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no >> shame in needing more than one release candidate. MT> Agreed. I stick with the -rc naming convention for 2.4+... (This is a request to maintainers of three stable trees). While we are on the topic, could you also coordinate to keep the EXTRAVERSION strings consistent? 2.4.X-preN uses "-preN" but 2.2.X-preN uses "preN" without leading "-". ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 20:39 ` junio @ 2001-11-26 20:55 ` David Weinehall 2001-11-26 20:59 ` H. Peter Anvin 0 siblings, 1 reply; 42+ messages in thread From: David Weinehall @ 2001-11-26 20:55 UTC (permalink / raw) To: junio; +Cc: Marcelo Tosatti, Alan Cox, H. Peter Anvin, linux-kernel On Mon, Nov 26, 2001 at 12:39:34PM -0800, junio@siamese.dhis.twinsun.com wrote: > >>>>> "MT" == Marcelo Tosatti <marcelo@conectiva.com.br> writes: > > MT> On Mon, 26 Nov 2001, H. Peter Anvin wrote: > >> Consistency is a Very Good Thing[TM] (says the one who tries to teach > >> scripts to understand the naming.) The advantage with the -rc naming is > >> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, > >> -pre-final-really-i-mean-it-this-time phenomenon when the release > >> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no > >> shame in needing more than one release candidate. > > MT> Agreed. I stick with the -rc naming convention for 2.4+... > > (This is a request to maintainers of three stable trees). > > While we are on the topic, could you also coordinate to keep the > EXTRAVERSION strings consistent? 2.4.X-preN uses "-preN" but > 2.2.X-preN uses "preN" without leading "-". I'm using "-preN" with a leading "-", and will probably continue doing so. Regards: David _ _ // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 20:55 ` David Weinehall @ 2001-11-26 20:59 ` H. Peter Anvin 0 siblings, 0 replies; 42+ messages in thread From: H. Peter Anvin @ 2001-11-26 20:59 UTC (permalink / raw) To: David Weinehall; +Cc: junio, Marcelo Tosatti, Alan Cox, linux-kernel David Weinehall wrote: >> >>While we are on the topic, could you also coordinate to keep the >>EXTRAVERSION strings consistent? 2.4.X-preN uses "-preN" but >>2.2.X-preN uses "preN" without leading "-". >> > > I'm using "-preN" with a leading "-", and will probably continue > doing so. > This matches the filename convention, and seems to be what most users expect. -hpa ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 18:31 ` H. Peter Anvin 2001-11-26 17:25 ` Marcelo Tosatti @ 2001-11-26 21:18 ` Gregory Maxwell 2001-11-27 8:02 ` Svein Erik Brostigen ` (2 more replies) 1 sibling, 3 replies; 42+ messages in thread From: Gregory Maxwell @ 2001-11-26 21:18 UTC (permalink / raw) To: H. Peter Anvin; +Cc: David Weinehall, linux-kernel On Mon, Nov 26, 2001 at 10:31:41AM -0800, H. Peter Anvin wrote: > Consistency is a Very Good Thing[TM] (says the one who tries to teach > scripts to understand the naming.) The advantage with the -rc naming is > that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, > -pre-final-really-i-mean-it-this-time phenomenon when the release > candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no > shame in needing more than one release candidate. Why not just disguard this sillyness of alphabetic characters in version numbers... Just carry through the same structure used by major/minor: I.e. 2.0.39 < released 2.0.39 2.0.39.1.1 < first development snapshot of the kernel which will eventually be 2.0.40 2.0.39.1.2 < second 2.0.39.1.n < Nth 2.0.39.2.1 < first RC 2.0.39.2.2 < second RC 2.0.39.3.1 < opps! Development went too long and we had to break feature freeze to add important features. 2.0.39.4.1 < Trying to stablize again 2.0.39.4.2 < a few more bugs fixxed 2.0.40 < Looks like 2.0.39.4.2 got it right! ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 21:18 ` Gregory Maxwell @ 2001-11-27 8:02 ` Svein Erik Brostigen 2001-11-27 8:28 ` Allan Sandfeld 2001-11-27 10:07 ` Alex Bligh - linux-kernel 2001-11-27 14:43 ` Sven Vermeulen 2 siblings, 1 reply; 42+ messages in thread From: Svein Erik Brostigen @ 2001-11-27 8:02 UTC (permalink / raw) To: Gregory Maxwell; +Cc: H. Peter Anvin, David Weinehall, linux-kernel Gregory Maxwell wrote: >On Mon, Nov 26, 2001 at 10:31:41AM -0800, H. Peter Anvin wrote: > >>Consistency is a Very Good Thing[TM] (says the one who tries to teach >>scripts to understand the naming.) The advantage with the -rc naming is >>that it avoids the -pre5, -pre6, -pre-final, -pre-final-really, >>-pre-final-really-i-mean-it-this-time phenomenon when the release >>candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no >>shame in needing more than one release candidate. >> > >Why not just disguard this sillyness of alphabetic characters in version >numbers... Just carry through the same structure used by major/minor: >I.e. > >2.0.39 < released 2.0.39 >2.0.39.1.1 < first development snapshot of the kernel which will eventually > be 2.0.40 >2.0.39.1.2 < second >2.0.39.1.n < Nth >2.0.39.2.1 < first RC >2.0.39.2.2 < second RC >2.0.39.3.1 < opps! Development went too long and we had to break feature > freeze to add important features. >2.0.39.4.1 < Trying to stablize again >2.0.39.4.2 < a few more bugs fixxed >2.0.40 < Looks like 2.0.39.4.2 got it right! >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > What really scares me is not so much the way the kernels are numbered as the way features gets added to the kernels. Internally in Oracle we do not add new features to a release number, just bug-fixes. Hence 2.4.0 is the base release of the 2.4.x kernel series. the minor x-number should just indicate a bug-fix release. Thus, no new features should get added to the 2.4 kernel with this numbering schema. If you really want to add features into the 2.4.x kernel, you also need to extend the numbering schema. I.e 2.4.0.x wil then be the bug-fix releases and 2.4.1.x will have new features. This makes it easier to maintain and to understand what is happening between the various releases. As far as I can understand, today, new features are added to a released kernel without any sensible numbering scheme identifying this fact. I don't know if a 2.4.10 kernel contains the same features as 2.4.16 with the only difference beeing bug-fixes or if there have been added new features. By using a numbering scheme that is consistent across both development and production kernels, it is easier to identify the features in a kernel. I realize that this is a lot easier to do when you are using a source code repository than by hand administration. I think the time has come for the kernel to find it's way into a cvs form. It has to be done, sooner or later, why not now when the 2.5 kernel has been forked? And I do agree with people who has asked for a bug system to identify the various bugs and their fixes. I have been looking forward to the 2.5 kernel because I have wanted to get involved in the kernel devlopment, but have not wanted to jump in on an existing production/development kernel. The most confusing part today is all the various patches beeing sendt around on the lkml. A lot of people who wants to develop, do not have the time to keep on top of the mailing list. We do have other jobs too, that pays for our food and clothes. This is done on our spare time and having to spend a few hours every day, reading through the kernel list and applying various patches seems like a waste of time. Unless a different system is devised, I think I will stay away from the kernel development and concentrate on other things. I'm sorry if this seems like a flame-bait, it was not intended to be and I did not intend to offend anyone either. My apologies to anyone who feels so. -- Regards Svein Erik I've given up reading books; I find it takes my mind off myself. _____________________________________________________________ Svein Erik Brostigen e-mail: svein.brostigen@oracle.com Senior Technical Analyst Phone: 407.458.7168 EBC - Extended Business Critical Oracle Support Services 5955 T.G. Lee Blvd Orlando FL, 32822 Enabling the Information Age Through Internet Computing _____________________________________________________________ The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-27 8:02 ` Svein Erik Brostigen @ 2001-11-27 8:28 ` Allan Sandfeld 2001-11-27 9:08 ` Svein Erik Brostigen 0 siblings, 1 reply; 42+ messages in thread From: Allan Sandfeld @ 2001-11-27 8:28 UTC (permalink / raw) To: linux-kernel On Tuesday 27 November 2001 09:02, Svein Erik Brostigen wrote: > > What really scares me is not so much the way the kernels are numbered as > the way features gets added to > the kernels. > Internally in Oracle we do not add new features to a release number, > just bug-fixes. > Hence 2.4.0 is the base release of the 2.4.x kernel series. the minor > x-number should just indicate a bug-fix > release. Thus, no new features should get added to the 2.4 kernel with > this numbering schema. > If you really want to add features into the 2.4.x kernel, you also need > to extend the numbering schema. > I.e 2.4.0.x wil then be the bug-fix releases and 2.4.1.x will have new > features. > This makes it easier to maintain and to understand what is happening > between the various releases. > > As far as I can understand, today, new features are added to a released > kernel without any sensible numbering scheme > identifying this fact. I don't know if a 2.4.10 kernel contains the same > features as 2.4.16 with the only difference beeing bug-fixes > or if there have been added new features. By using a numbering scheme > that is consistent across both development and > production kernels, it is easier to identify the features in a kernel. > The problem is that for kernels new features _are_ bug-fixes. Like the new vm, work-around for discovered bugs in hardware, etc., etc. I an way what should't be done in a -rc release is new fixing features, but only the fixing _of_ features. ;-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-27 8:28 ` Allan Sandfeld @ 2001-11-27 9:08 ` Svein Erik Brostigen 0 siblings, 0 replies; 42+ messages in thread From: Svein Erik Brostigen @ 2001-11-27 9:08 UTC (permalink / raw) To: Allan Sandfeld; +Cc: linux-kernel Allan Sandfeld wrote: >On Tuesday 27 November 2001 09:02, Svein Erik Brostigen wrote: > >>What really scares me is not so much the way the kernels are numbered as >>the way features gets added to >>the kernels. >> >The problem is that for kernels new features _are_ bug-fixes. Like the new >vm, work-around for discovered bugs in hardware, etc., etc. >I an way what should't be done in a -rc release is new fixing features, but >only the fixing _of_ features. ;-) > Hmmm... workarounds are not new features, but bug-fixes ;-) The new vm is not a *new* feature, it is just a different vm than the old. Even if you treat it as a new feature, it should then be incorporated into a new-feature release, i.e not in a 2.4.10.4, but maybe in what would have been a 2.4.11.0. I'm not going to be anal about this, but a more structured way of handling new features/bug-fixes and release numbering would be nice. A lot easier to know what you are programming against and what you are installing/testing. -- Regards Svein Erik I've given up reading books; I find it takes my mind off myself. _____________________________________________________________ Svein Erik Brostigen e-mail: svein.brostigen@oracle.com Senior Technical Analyst Phone: 407.458.7168 EBC - Extended Business Critical Oracle Support Services 5955 T.G. Lee Blvd Orlando FL, 32822 Enabling the Information Age Through Internet Computing _____________________________________________________________ The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 21:18 ` Gregory Maxwell 2001-11-27 8:02 ` Svein Erik Brostigen @ 2001-11-27 10:07 ` Alex Bligh - linux-kernel 2001-11-27 14:43 ` Sven Vermeulen 2 siblings, 0 replies; 42+ messages in thread From: Alex Bligh - linux-kernel @ 2001-11-27 10:07 UTC (permalink / raw) To: Gregory Maxwell, H. Peter Anvin Cc: David Weinehall, linux-kernel, Alex Bligh - linux-kernel --On Monday, 26 November, 2001 4:18 PM -0500 Gregory Maxwell <greg@linuxpower.cx> wrote: > Why not just disguard this sillyness of alphabetic characters in version > numbers Express version numbers as a real number. Only the versions with perfectly accurate binary representations of irrational numbers will be bug-free release candidates :-p -- Alex Bligh ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 21:18 ` Gregory Maxwell 2001-11-27 8:02 ` Svein Erik Brostigen 2001-11-27 10:07 ` Alex Bligh - linux-kernel @ 2001-11-27 14:43 ` Sven Vermeulen 2001-11-27 15:01 ` Ian Molton ` (2 more replies) 2 siblings, 3 replies; 42+ messages in thread From: Sven Vermeulen @ 2001-11-27 14:43 UTC (permalink / raw) To: linux-kernel On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote: > Why not just disguard this sillyness of alphabetic characters in version > numbers... Just carry through the same structure used by major/minor: > I.e. > > 2.0.39 < released 2.0.39 > 2.0.39.1.1 < first development snapshot of the kernel which will eventually > be 2.0.40 > 2.0.39.1.2 < second > 2.0.39.1.n < Nth > 2.0.39.2.1 < first RC > 2.0.39.2.2 < second RC > 2.0.39.3.1 < opps! Development went too long and we had to break feature > freeze to add important features. > 2.0.39.4.1 < Trying to stablize again > 2.0.39.4.2 < a few more bugs fixxed > 2.0.40 < Looks like 2.0.39.4.2 got it right! Some people may find this more "logical", but imho most will find it confusing... It's already difficult to inform someone about the (number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into -pre: added some features, bugfixes etc... -fc : feature-freeze, only bugfixes and having some time (f.i. 48h) between the last -fc and the "real" release (without having a single addendum to the ChangeLog). Just my 2 cents, Sven Vermeulen -- Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen a angry penguin charging at them in excess of 100mph. They'd be a lot more careful about what they say if they had. ~(Linus Torvalds) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-27 14:43 ` Sven Vermeulen @ 2001-11-27 15:01 ` Ian Molton 2001-11-27 15:42 ` John Alvord 2001-11-27 16:03 ` Michel Angelo da Silva Pereira 2 siblings, 0 replies; 42+ messages in thread From: Ian Molton @ 2001-11-27 15:01 UTC (permalink / raw) To: linux-kernel On a sunny Tue, 27 Nov 2001 15:43:23 +0100 Sven Vermeulen gathered a sheaf of electrons and etched in their motions the following immortal words: > -fc : feature-freeze, only bugfixes Did it occur to anyone here that fc is an acronym for 'Feature Creep' ? :-) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-27 14:43 ` Sven Vermeulen 2001-11-27 15:01 ` Ian Molton @ 2001-11-27 15:42 ` John Alvord 2001-11-27 16:03 ` Michel Angelo da Silva Pereira 2 siblings, 0 replies; 42+ messages in thread From: John Alvord @ 2001-11-27 15:42 UTC (permalink / raw) To: Sven Vermeulen; +Cc: linux-kernel On Tue, 27 Nov 2001 15:43:23 +0100, Sven Vermeulen <sven.vermeulen@rug.ac.be> wrote: >On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote: >> Why not just disguard this sillyness of alphabetic characters in version >> numbers... Just carry through the same structure used by major/minor: >> I.e. >> >> 2.0.39 < released 2.0.39 >> 2.0.39.1.1 < first development snapshot of the kernel which will eventually >> be 2.0.40 >> 2.0.39.1.2 < second >> 2.0.39.1.n < Nth >> 2.0.39.2.1 < first RC >> 2.0.39.2.2 < second RC >> 2.0.39.3.1 < opps! Development went too long and we had to break feature >> freeze to add important features. >> 2.0.39.4.1 < Trying to stablize again >> 2.0.39.4.2 < a few more bugs fixxed >> 2.0.40 < Looks like 2.0.39.4.2 got it right! > >Some people may find this more "logical", but imho most will find it >confusing... It's already difficult to inform someone about the >(number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into > -pre: added some features, bugfixes etc... > -fc : feature-freeze, only bugfixes >and having some time (f.i. 48h) between the last -fc and the "real" release >(without having a single addendum to the ChangeLog). The bug-fixes only would have to be tightly defined. All of 2.4.0-2.4.15 were bug-fixes in some sense... john ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-27 14:43 ` Sven Vermeulen 2001-11-27 15:01 ` Ian Molton 2001-11-27 15:42 ` John Alvord @ 2001-11-27 16:03 ` Michel Angelo da Silva Pereira 2 siblings, 0 replies; 42+ messages in thread From: Michel Angelo da Silva Pereira @ 2001-11-27 16:03 UTC (permalink / raw) To: linux-kernel I agree with your opinion, it's so difficult to understand what is happening with the linux kernel. And the -rc (Release Candidate) it's not welcome, remember me another OS in development status. Bye Sven Vermeulen wrote: > On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote: > > > Some people may find this more "logical", but imho most will find it > confusing... It's already difficult to inform someone about the > (number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into > -pre: added some features, bugfixes etc... > -fc : feature-freeze, only bugfixes > and having some time (f.i. 48h) between the last -fc and the "real" release > (without having a single addendum to the ChangeLog). > > Just my 2 cents, > Sven Vermeulen > > -- ================================================= Borges & Rinolfi Soluções em Redes Corporativas Security Officer Profissional Certificado Conectiva Linux www.techs.com.br/kidmumu - UIN 4553082 - LC 83522 ... e querido papai do céu, em vez de botar as vitaminas no óleo de bacalhau, bota nos merengues que seu Manoel tem lá na venda. Amém. ================================================= ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 17:22 ` Chris Meadors 2001-11-26 15:54 ` Marcelo Tosatti @ 2001-11-26 18:48 ` Bjoern A. Zeeb 2001-11-26 23:15 ` J.A. Magallon 1 sibling, 1 reply; 42+ messages in thread From: Bjoern A. Zeeb @ 2001-11-26 18:48 UTC (permalink / raw) To: lkml On Mon, 26 Nov 2001, Chris Meadors wrote: > I like the ISC's release methods. The do -rc's (-pre's would be fine for > the kernel as it is already established), each -rc fixes problems found > with the previous. When an -rc has been out long enough with no more bug > reports they release that code, WITHOUT changes. Hi, I am neither a vendor nor maintainer nor a great kernel hacker but I think you all miss at least one point (what I for sure do too): The problem is that you kernel hackers out there fetch the pre stuff and test it that others run test cycles on them ... . But the lot of people out there will never fetch anything else than a "release" ; no -pre no -rc no -ac no whatever prefix or suffix. You will not get them just because somebody 's changing the name to something else. Make your test periods longer. If there are no real serious bug in the pre let the pre live for a week or 2 or even longer. Who cares ? We are in 'stable' branch at the moment! At some (early) point of pre-releases stop accepting any further features and if the -pre gets real close to being fine announce that it'll be the last one, make a note to the changelog, wait another week for seriuos bufixes and then release the tarballs (or if any have one more pre). There are for sure some points that there should be better no more different naming conventions: hpa will surely have to hack up more scripts, things might get inconsistent between different stable/dev. versions, we already have the -<some letter> releases for other kernel hacker's releases like -aa -ac, ... and so on... But if you really decide on another suffix my vote would be -rc 'cause it's the most common one (perhaps linus then will use it in the future too ?) And always keep in mind: another new 'release' is nothing else than another 'release candidate' to the next version with hopefully less bugs more stability (and sometimes more features ;) just my 5 cents -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 18:48 ` Bjoern A. Zeeb @ 2001-11-26 23:15 ` J.A. Magallon 0 siblings, 0 replies; 42+ messages in thread From: J.A. Magallon @ 2001-11-26 23:15 UTC (permalink / raw) To: Bjoern A. Zeeb; +Cc: lkml On 20011126 Bjoern A. Zeeb wrote: > >The problem is that you kernel hackers out there fetch the pre stuff >and test it that others run test cycles on them ... . But the >lot of people out there will never fetch anything else than >a "release" ; no -pre no -rc no -ac no whatever prefix or suffix. >You will not get them just because somebody 's changing the name >to something else. > The problem is the fear of people about -ac or -pre series. What should be done is to teach people that what they think is kernel 2.4.8 from RedHat or Mandrake is really 2.4.8-ac7 or the like. They are shipping -ac versions (beacuse of preferences and driver update, usually are -ac series and not -pre series). So your 'distro rock solid kernel' is an -ac kernel (and I do not say that an -ac kernel is not rock solid, I have run -ac's until 13-ac7). -- J.A. Magallon # Let the source be with you... mailto:jamagallon@able.es Mandrake Linux release 8.2 (Cooker) for i586 Linux werewolf 2.4.16-pre1 #1 SMP Sun Nov 25 02:06:34 CET 2001 i686 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy [was: Linux 2.4.16 ] 2001-11-26 15:33 ` Marcelo Tosatti 2001-11-26 17:14 ` David Relson 2001-11-26 17:22 ` Chris Meadors @ 2001-11-27 1:04 ` Andrew Morton 2001-11-27 1:13 ` Release Policy David S. Miller 2 siblings, 1 reply; 42+ messages in thread From: Andrew Morton @ 2001-11-27 1:04 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml Marcelo Tosatti wrote: > > (people are flooding me with patches, btw, please stop for a while). > That's funny. The rest of us haven't seen these patches. Marcelo, if someone sends you a patch which has not been thoroughly reviewed on the appropriate mailing list, I would urge you to peremptorily shitcan it. There is no reason why you alone should be responsible for reviewing kernel changes. - ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 1:04 ` Andrew Morton @ 2001-11-27 1:13 ` David S. Miller 2001-11-27 1:32 ` H. Peter Anvin 2001-12-05 14:27 ` Jes Sorensen 0 siblings, 2 replies; 42+ messages in thread From: David S. Miller @ 2001-11-27 1:13 UTC (permalink / raw) To: akpm; +Cc: marcelo, linux-kernel From: Andrew Morton <akpm@zip.com.au> Date: Mon, 26 Nov 2001 17:04:02 -0800 Marcelo, if someone sends you a patch which has not been thoroughly reviewed on the appropriate mailing list, I would urge you to peremptorily shitcan it. There is no reason why you alone should be responsible for reviewing kernel changes. Are you suggesting that, for example, I should send every Sparc change to this list? I bet a lot of what he is seeing are driver and arch updates. Such updates really only need to go through his "stupid filter" when it is coming from the maintainer, but it does add up and take up time. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 1:13 ` Release Policy David S. Miller @ 2001-11-27 1:32 ` H. Peter Anvin 2001-11-27 7:39 ` Anuradha Ratnaweera 2001-12-05 14:27 ` Jes Sorensen 1 sibling, 1 reply; 42+ messages in thread From: H. Peter Anvin @ 2001-11-27 1:32 UTC (permalink / raw) To: linux-kernel Followup to: <20011126.171301.50592818.davem@redhat.com> By author: "David S. Miller" <davem@redhat.com> In newsgroup: linux.dev.kernel > > From: Andrew Morton <akpm@zip.com.au> > Date: Mon, 26 Nov 2001 17:04:02 -0800 > > Marcelo, if someone sends you a patch which has not been thoroughly > reviewed on the appropriate mailing list, I would urge you to > peremptorily shitcan it. There is no reason why you alone should > be responsible for reviewing kernel changes. > > Are you suggesting that, for example, I should send every Sparc change > to this list? > appropriate != this. > I bet a lot of what he is seeing are driver and arch updates. > > Such updates really only need to go through his "stupid filter" > when it is coming from the maintainer, but it does add up and > take up time. Obviously. If it's for a maintained subsystem: a) if it's from the subsystem maintainer, sanity-check it. b) if it's not, dump it or reject with the appropriate notice. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 1:32 ` H. Peter Anvin @ 2001-11-27 7:39 ` Anuradha Ratnaweera 2001-11-27 7:40 ` H. Peter Anvin 2001-11-27 10:08 ` Harald Arnesen 0 siblings, 2 replies; 42+ messages in thread From: Anuradha Ratnaweera @ 2001-11-27 7:39 UTC (permalink / raw) To: H. Peter Anvin; +Cc: linux-kernel On Mon, Nov 26, 2001 at 05:32:18PM -0800, H. Peter Anvin wrote: > > > > Such updates really only need to go through his "stupid filter" > > when it is coming from the maintainer, but it does add up and > > take up time. > > Obviously. If it's for a maintained subsystem: > > a) if it's from the subsystem maintainer, sanity-check it. > b) if it's not, dump it or reject with the appropriate notice. A minor issue... How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from the subsystem aintainer himself? I mean anybody would have sent any crap, but not too bad enough to suspect. But if it came with a CC to a list, there is a much smaller chance of this happenning. Yes. This would be very rare and the effects would be very short lived. But still the _possibility_ exists. Cheers, Anuradha -- Debian GNU/Linux (kernel 2.4.13) When you make your mark in the world, watch out for guys with erasers. -- The Wall Street Journal ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 7:39 ` Anuradha Ratnaweera @ 2001-11-27 7:40 ` H. Peter Anvin 2001-11-27 7:53 ` Anuradha Ratnaweera 2001-11-27 10:08 ` Harald Arnesen 1 sibling, 1 reply; 42+ messages in thread From: H. Peter Anvin @ 2001-11-27 7:40 UTC (permalink / raw) To: Anuradha Ratnaweera; +Cc: linux-kernel Anuradha Ratnaweera wrote: > > A minor issue... > > How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from > the subsystem aintainer himself? I mean anybody would have sent any crap, but > not too bad enough to suspect. But if it came with a CC to a list, there is a > much smaller chance of this happenning. > > Yes. This would be very rare and the effects would be very short lived. But > still the _possibility_ exists. > How about sending a quick reply "got your patch, applied it?" The maintainer can then say "WHAT PATCH?" -hpa ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 7:40 ` H. Peter Anvin @ 2001-11-27 7:53 ` Anuradha Ratnaweera 0 siblings, 0 replies; 42+ messages in thread From: Anuradha Ratnaweera @ 2001-11-27 7:53 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Anuradha Ratnaweera, linux-kernel On Mon, Nov 26, 2001 at 11:40:30PM -0800, H. Peter Anvin wrote: > Anuradha Ratnaweera wrote: > > > > How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from > > the subsystem aintainer himself? I mean anybody would have sent any crap, but > > not too bad enough to suspect. But if it came with a CC to a list, there is a > > much smaller chance of this happenning. > > > > Yes. This would be very rare and the effects would be very short lived. But > > still the _possibility_ exists. > > How about sending a quick reply "got your patch, applied it?" The > maintainer can then say "WHAT PATCH?" Don't we need a consistent indexing system for patches? May be the subsystem maintainers can upload patches to some place over ssh/ssl and the maintainer can _download_ them from there. The maintainer will simply email the patch number and not the whole thing. And patches can be numbered/named in some consistent manner. Once the system is in place, we can even automate md5 checksums etc. Cheers, Anuradha -- Debian GNU/Linux (kernel 2.4.13) There's one consolation about matrimony. When you look around you can always see somebody who did worse. -- Warren H. Goldsmith ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 7:39 ` Anuradha Ratnaweera 2001-11-27 7:40 ` H. Peter Anvin @ 2001-11-27 10:08 ` Harald Arnesen 2001-11-27 10:29 ` Keith Owens 1 sibling, 1 reply; 42+ messages in thread From: Harald Arnesen @ 2001-11-27 10:08 UTC (permalink / raw) To: Anuradha Ratnaweera; +Cc: H. Peter Anvin, linux-kernel Anuradha Ratnaweera <anuradha@gnu.org> writes: > How does Marcelo (or Linus or Alan, say) know that the patch > _really_ came from the subsystem aintainer himself? They could reject patches that came without the maintainers GPG or PGP signature. -- Hilsen Harald. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 10:08 ` Harald Arnesen @ 2001-11-27 10:29 ` Keith Owens 2001-11-27 19:45 ` Mike Fedyk 0 siblings, 1 reply; 42+ messages in thread From: Keith Owens @ 2001-11-27 10:29 UTC (permalink / raw) To: Harald Arnesen; +Cc: linux-kernel On Tue, 27 Nov 2001 11:08:04 +0100, Harald Arnesen <gurre@start.no> wrote: >Anuradha Ratnaweera <anuradha@gnu.org> writes: > >> How does Marcelo (or Linus or Alan, say) know that the patch >> _really_ came from the subsystem aintainer himself? > >They could reject patches that came without the maintainers GPG or PGP >signature. Unfortunately the normal GPG/PGP signing changes '-' at start of line to '- -', even with clear text signing, and destroys the patch. You have to use --not-dash-escaped in GPG, where the man page says: --not-dash-escaped This option changes the behavior of cleartext signatures so that they can be used for patch files. You should not send such an armored file via email because all spaces and line endings are hashed too. You can not use this option for data which has 5 dashes at the beginning of a line, patch files don't have this. A special armor header line tells GnuPG about this cleartext signature option. I don't know if PGP accepts text signed by GPG with --not-dash-escaped nor do I know if there really is a problem with mailing such patches. But the warning above is nasty enough to rule it out. The only other option for signed patches is uuencode or MIME (with or without compression) and Linus does not like that format. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 10:29 ` Keith Owens @ 2001-11-27 19:45 ` Mike Fedyk 0 siblings, 0 replies; 42+ messages in thread From: Mike Fedyk @ 2001-11-27 19:45 UTC (permalink / raw) To: Keith Owens; +Cc: Harald Arnesen, linux-kernel On Tue, Nov 27, 2001 at 09:29:36PM +1100, Keith Owens wrote: > On Tue, 27 Nov 2001 11:08:04 +0100, > Harald Arnesen <gurre@start.no> wrote: > >Anuradha Ratnaweera <anuradha@gnu.org> writes: > > > >> How does Marcelo (or Linus or Alan, say) know that the patch > >> _really_ came from the subsystem aintainer himself? > > > >They could reject patches that came without the maintainers GPG or PGP > >signature. > > Unfortunately the normal GPG/PGP signing changes '-' at start of line > to '- -', even with clear text signing, and destroys the patch. You > have to use --not-dash-escaped in GPG, where the man page says: > > --not-dash-escaped > This option changes the behavior of cleartext signatures so that > they can be used for patch files. You should not send such an armored > file via email because all spaces and line endings are hashed too. > You can not use this option for data which has 5 dashes at the > beginning of a line, patch files don't have this. A special armor > header line tells GnuPG about this cleartext signature option. > Interesting. > I don't know if PGP accepts text signed by GPG with --not-dash-escaped > nor do I know if there really is a problem with mailing such patches. > But the warning above is nasty enough to rule it out. The only other > option for signed patches is uuencode or MIME (with or without > compression) and Linus does not like that format. > But we're not dealing with Linus with 2.4 anymore. Maybe Marcello will accept signed compressed patches. With a few modifications, most MUAs that support external processing could be setup to verify the sig, uncompress, and view in the message area. MF ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Release Policy 2001-11-27 1:13 ` Release Policy David S. Miller 2001-11-27 1:32 ` H. Peter Anvin @ 2001-12-05 14:27 ` Jes Sorensen 1 sibling, 0 replies; 42+ messages in thread From: Jes Sorensen @ 2001-12-05 14:27 UTC (permalink / raw) To: David S. Miller; +Cc: akpm, marcelo, linux-kernel "David S. Miller" <davem@redhat.com> writes: > Are you suggesting that, for example, I should send every Sparc change > to this list? > > I bet a lot of what he is seeing are driver and arch updates. > > Such updates really only need to go through his "stupid filter" > when it is coming from the maintainer, but it does add up and > take up time. A real problem is the large number of driver patches that come in from non maintainers. Jes ^ permalink raw reply [flat|nested] 42+ messages in thread
[parent not found: <fa.c4d6r2v.j10a8j@ifi.uio.no>]
[parent not found: <fa.h6dlovv.r28grf@ifi.uio.no>]
* Re: Release Policy [not found] ` <fa.h6dlovv.r28grf@ifi.uio.no> @ 2001-11-27 10:25 ` Giacomo Catenazzi 0 siblings, 0 replies; 42+ messages in thread From: Giacomo Catenazzi @ 2001-11-27 10:25 UTC (permalink / raw) To: Harald Arnesen; +Cc: Anuradha Ratnaweera, H. Peter Anvin, linux-kernel Harald Arnesen wrote: > Anuradha Ratnaweera <anuradha@gnu.org> writes: > > >>How does Marcelo (or Linus or Alan, say) know that the patch >>_really_ came from the subsystem aintainer himself? >> > > They could reject patches that came without the maintainers GPG or PGP > signature. > Why? If the patch seem to come from a maintainer AND the quality of patch is ok, why to require some other 'burocratic' steps? giacomo ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2001-12-05 14:28 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.21.0111261003070.13400-100000@freak.distro.cone ctiva>
2001-11-26 16:38 ` Release Policy [was: Linux 2.4.16 ] David Relson
2001-11-26 15:33 ` Marcelo Tosatti
2001-11-26 17:14 ` David Relson
2001-11-26 21:15 ` Bill Davidsen
2001-11-26 17:22 ` Chris Meadors
2001-11-26 15:54 ` Marcelo Tosatti
2001-11-26 17:41 ` David Rees
2001-11-26 18:12 ` H. Peter Anvin
2001-11-26 18:29 ` David Weinehall
2001-11-26 18:31 ` H. Peter Anvin
2001-11-26 17:25 ` Marcelo Tosatti
2001-11-26 18:49 ` H. Peter Anvin
2001-11-26 19:00 ` François Cami
2001-11-26 19:06 ` Jonathan Lundell
2001-11-26 19:28 ` Flavio Stanchina
2001-11-26 19:43 ` Jonathan Lundell
2001-11-26 19:36 ` David Weinehall
2001-11-26 20:39 ` junio
2001-11-26 20:55 ` David Weinehall
2001-11-26 20:59 ` H. Peter Anvin
2001-11-26 21:18 ` Gregory Maxwell
2001-11-27 8:02 ` Svein Erik Brostigen
2001-11-27 8:28 ` Allan Sandfeld
2001-11-27 9:08 ` Svein Erik Brostigen
2001-11-27 10:07 ` Alex Bligh - linux-kernel
2001-11-27 14:43 ` Sven Vermeulen
2001-11-27 15:01 ` Ian Molton
2001-11-27 15:42 ` John Alvord
2001-11-27 16:03 ` Michel Angelo da Silva Pereira
2001-11-26 18:48 ` Bjoern A. Zeeb
2001-11-26 23:15 ` J.A. Magallon
2001-11-27 1:04 ` Andrew Morton
2001-11-27 1:13 ` Release Policy David S. Miller
2001-11-27 1:32 ` H. Peter Anvin
2001-11-27 7:39 ` Anuradha Ratnaweera
2001-11-27 7:40 ` H. Peter Anvin
2001-11-27 7:53 ` Anuradha Ratnaweera
2001-11-27 10:08 ` Harald Arnesen
2001-11-27 10:29 ` Keith Owens
2001-11-27 19:45 ` Mike Fedyk
2001-12-05 14:27 ` Jes Sorensen
[not found] <fa.c4d6r2v.j10a8j@ifi.uio.no>
[not found] ` <fa.h6dlovv.r28grf@ifi.uio.no>
2001-11-27 10:25 ` Giacomo Catenazzi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox