Re: RFD: Kernel release numbering
Linus wrote (back on 4th March): :The even/odd situation would have made for a situation that some people :seem to be arguing for (more explicit calming-down period), but with the :difference that I think the odd ones should definitely have been :user-release quality already. But that one was apparently hated by so many :people that it's not even worth trying. :The fact is, there is no perfect way of doing things, and this discussion :has degenerated into nothing but whining. Which is kind of expected, but :let's hope that the only non-whining that came out of this (Greg co's :trials with 2.6.x.y) ends up being worthwhile. I'm sorry I didn't get to read this earlier. I apologise for stepping in here, not being a core developer, however, this is what I tend to think about kernel releases. Even/odd at the next level down would confuse p.o.u like me. We kind of grasped that 2.4 was okay to run (generally, anyone remember 2.4.12?) but a walk with 2.5 was definitely taking your hard drive for a walk. When 2.6 came along as the new devel kernel (as I perceived everyone saying) I got confused, then decided to wait to see what happened. It ended up looking like I would hawe perceived a true 2.6 tree to be - mostly stable, yet a few nice features being added. The MAJOR difference for me was that there WASN'T a 2.7 feeding nice stuff to the 2.6 tree - it was all going in directly. Nice. The new 2.6.x.y has turned out to be an interesting change for me, being previously used to 2.x.y. I'm guessing the reason for this is that Greg decided to be a little more fine-grained with releases, so as to reduce (somewhat) the major jump from 2.6.x to 2.6.x+1 for the developers, who internally went through 2.6.x+1-rc[123...], and 2.6.x+1-pre[n]. Frankly, I wasn't seeing the major jump, and was thinking of it as perhaps a few bugs found each time, maybe a couple of fixes, and by the time you'd gone from 2.6.4 (for example) to 2.6.12, or maybe even 2.6.19, lots of new features were added, and 98% of the bugs shaken out. So much for the view of a simple desktop user. I'm finding the finer granularity a little confusing, as I'm not sure if the patches are cumulative (not the case in the past for patches on a Linus kernel) or I just happen to hit a couple of weird patches. Going from 2.6.11.2 to .3, I was told I had seemingly applied one of the patches already, and it was the same when going from .3 to .4 - not many failures, usually only one or two. I like 2.6. I don't think any of my machines will ever go back to 2.4 (except perhaps for my wife's machine, but that's another matter ), I like using it. And next time, I won't wait for 20 days before making a comment. Hopefully. -- /| _,.:*^*:., |\ Cheers from the Viking family, including Pippin, our cat | |_/' viking@ `\_| | |flying-brick| $FunnyMail : What do you mean, I've lost the plot? \_.caverock.net.nz_/ 5.40 : I planted them carrots right here!! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Linus wrote (back on 4th March): :The even/odd situation would have made for a situation that some people :seem to be arguing for (more explicit calming-down period), but with the :difference that I think the odd ones should definitely have been :user-release quality already. But that one was apparently hated by so many :people that it's not even worth trying. :The fact is, there is no perfect way of doing things, and this discussion :has degenerated into nothing but whining. Which is kind of expected, but :let's hope that the only non-whining that came out of this (Greg nbsp;co's :trials with 2.6.x.y) ends up being worthwhile. I'm sorry I didn't get to read this earlier. I apologise for stepping in here, not being a core developer, however, this is what I tend to think about kernel releases. Even/odd at the next level down would confuse p.o.u like me. We kind of grasped that 2.4 was okay to run (generally, anyone remember 2.4.12?) but a walk with 2.5 was definitely taking your hard drive for a walk. When 2.6 came along as the new devel kernel (as I perceived everyone saying) I got confused, then decided to wait to see what happened. It ended up looking like I would hawe perceived a true 2.6 tree to be - mostly stable, yet a few nice features being added. The MAJOR difference for me was that there WASN'T a 2.7 feeding nice stuff to the 2.6 tree - it was all going in directly. Nice. The new 2.6.x.y has turned out to be an interesting change for me, being previously used to 2.x.y. I'm guessing the reason for this is that Greg decided to be a little more fine-grained with releases, so as to reduce (somewhat) the major jump from 2.6.x to 2.6.x+1 for the developers, who internally went through 2.6.x+1-rc[123...], and 2.6.x+1-pre[n]. Frankly, I wasn't seeing the major jump, and was thinking of it as perhaps a few bugs found each time, maybe a couple of fixes, and by the time you'd gone from 2.6.4 (for example) to 2.6.12, or maybe even 2.6.19, lots of new features were added, and 98% of the bugs shaken out. So much for the view of a simple desktop user. I'm finding the finer granularity a little confusing, as I'm not sure if the patches are cumulative (not the case in the past for patches on a Linus kernel) or I just happen to hit a couple of weird patches. Going from 2.6.11.2 to .3, I was told I had seemingly applied one of the patches already, and it was the same when going from .3 to .4 - not many failures, usually only one or two. I like 2.6. I don't think any of my machines will ever go back to 2.4 (except perhaps for my wife's machine, but that's another matter grin), I like using it. And next time, I won't wait for 20 days before making a comment. Hopefully. -- /| _,.:*^*:., |\ Cheers from the Viking family, including Pippin, our cat | |_/' viking@ `\_| | |flying-brick| $FunnyMail : What do you mean, I've lost the plot? \_.caverock.net.nz_/ 5.40 : I planted them carrots right here!! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes: Andrew> Linus Torvalds <[EMAIL PROTECTED]> wrote: >> >> Now, I haven't actually gotten any complaints about 2.6.11 (apart >> from "gcc4 still has problems" with fairly trivial solutions) Andrew> There have been quite a few. Mainly driver stuff again: [...] Andrew> The biggest problem is the new ACPI-based i8042 probing on Andrew> Dells. I'm kicking myself over that because we *knew* the damn Andrew> thing was busted, and people kept on having to add Andrew> i8042.noacpi=1. We now have a three-line Andrew> work-around-it-until-we-fix-it-for-real patch. FWIW, this "minor regression" also occurs on other laptops, such as my Sharp Mebius. --J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Andrew == Andrew Morton [EMAIL PROTECTED] writes: Andrew Linus Torvalds [EMAIL PROTECTED] wrote: Now, I haven't actually gotten any complaints about 2.6.11 (apart from gcc4 still has problems with fairly trivial solutions) Andrew There have been quite a few. Mainly driver stuff again: [...] Andrew The biggest problem is the new ACPI-based i8042 probing on Andrew Dells. I'm kicking myself over that because we *knew* the damn Andrew thing was busted, and people kept on having to add Andrew i8042.noacpi=1. We now have a three-line Andrew work-around-it-until-we-fix-it-for-real patch. FWIW, this minor regression also occurs on other laptops, such as my Sharp Mebius. --J. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Hi! > > The fact that not a script, but Linus Torvalds, decides that the tree is > > in a state he likes to share with others. You have been doing -pre's all > > this time, it's just that you are calling them -rc's. > > No. > > I used to do "-pre", a long time ago. Exactly because they were > synchronization points for developers. > > These days, that's pointless. We keep the tree in pretty good working > order (certainly as good as my -pre's ever were) constantly, and > developers who need to can synchronize with either the BK tree or the > nightly snapshots. The fact is, 99% of the developers don't even need to Actually, sync to -pre is easier than sync to -bk snapshot: * you get incremental patches from kernel.org * there's reasonable number of pre-s so that you can be up-to-date without syncing each day Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Hi! The fact that not a script, but Linus Torvalds, decides that the tree is in a state he likes to share with others. You have been doing -pre's all this time, it's just that you are calling them -rc's. No. I used to do -pre, a long time ago. Exactly because they were synchronization points for developers. These days, that's pointless. We keep the tree in pretty good working order (certainly as good as my -pre's ever were) constantly, and developers who need to can synchronize with either the BK tree or the nightly snapshots. The fact is, 99% of the developers don't even need to Actually, sync to -pre is easier than sync to -bk snapshot: * you get incremental patches from kernel.org * there's reasonable number of pre-s so that you can be up-to-date without syncing each day Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Lee Revell <[EMAIL PROTECTED]> wrote: > On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: > > --- Dave Jones <[EMAIL PROTECTED]> a écrit : > > Taking into account that nobody responded on lkml nor > > on alsa (the message was awaiting modderator aprouval > > on alsa-devel) i don't think i will send more bug reports > > to alsa. > > How long ago was this? alsa-devel has been accepting messages > from > non-subscribers for at least 6 months. > It's from 10th of september 2004 I managed to find it on the internet: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/0996.html The same problem appears in 2.6.11 I'll repost the bug report asap > Lee > > > -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Maw, 2005-03-08 at 23:50, Lee Revell wrote: > This only works because those OS'es come bundled with a toy softsynth. > With ALSA, you either need a supported hardware wavetable synth > (emu10k1) or a real soft synth like Timidity or Fluidsynth. CS4239 has a toy synth of sorts (its more "doorbell" than synth admittedly). There are a pile of funnies with IBM laptops and CS423x to watch out for that might be worth mentioning - in particular you need to turn the fast boot stuff -off-. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
szonyi calin wrote: Let me tell you what i understood from this thread: 2.6.12 "almost stable" 2.6.13 devel (new drivers,fixes and stuff -- may be broken) 2.6.14 (based on 2.6.13) tries to became stable again 2.6.15 also devel (see above) 2.6.16 (based on 2.6.15) also tries to became stable again So we will _want_ to have a stable kernel (like 2.4 now) but this will never happen (see above) No. Linus' proposal was shouted down. What is happening is that Linus will continue to release 2.6.x as usual, with no even/odd stuff. Then a review committee will maintain 2.6.x.y (where y starts at 1 and increments). This will contain obvious fixes against 2.6.x. When Linus comes out with 2.6.x+1, then they will start a new stable tree 2.6.x+1.y. Please see the thread entitled "[RFC] -stable, how it's going to work.", started by Greg KH for more information on the "stable" release process. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Jeff Garzik <[EMAIL PROTECTED]> a écrit : > > Tangent: I would like to see requests-for-testing for FC > kernels on LKML. > > If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why > not distro > kernels? > > Because some people switched to other distribution also because of the distribution kernel ;-). When i was using redhat (6.x) the only compilable kernel was from kernel.org. I couldn't get the kernel shipped by redhat to compile on my machine. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Jeff Garzik [EMAIL PROTECTED] a écrit : Tangent: I would like to see requests-for-testing for FC kernels on LKML. If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why not distro kernels? Because some people switched to other distribution also because of the distribution kernel ;-). When i was using redhat (6.x) the only compilable kernel was from kernel.org. I couldn't get the kernel shipped by redhat to compile on my machine. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
szonyi calin wrote: Let me tell you what i understood from this thread: 2.6.12 almost stable 2.6.13 devel (new drivers,fixes and stuff -- may be broken) 2.6.14 (based on 2.6.13) tries to became stable again 2.6.15 also devel (see above) 2.6.16 (based on 2.6.15) also tries to became stable again So we will _want_ to have a stable kernel (like 2.4 now) but this will never happen (see above) No. Linus' proposal was shouted down. What is happening is that Linus will continue to release 2.6.x as usual, with no even/odd stuff. Then a review committee will maintain 2.6.x.y (where y starts at 1 and increments). This will contain obvious fixes against 2.6.x. When Linus comes out with 2.6.x+1, then they will start a new stable tree 2.6.x+1.y. Please see the thread entitled [RFC] -stable, how it's going to work., started by Greg KH for more information on the stable release process. Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Maw, 2005-03-08 at 23:50, Lee Revell wrote: This only works because those OS'es come bundled with a toy softsynth. With ALSA, you either need a supported hardware wavetable synth (emu10k1) or a real soft synth like Timidity or Fluidsynth. CS4239 has a toy synth of sorts (its more doorbell than synth admittedly). There are a pile of funnies with IBM laptops and CS423x to watch out for that might be worth mentioning - in particular you need to turn the fast boot stuff -off-. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Lee Revell [EMAIL PROTECTED] wrote: On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: --- Dave Jones [EMAIL PROTECTED] a écrit : Taking into account that nobody responded on lkml nor on alsa (the message was awaiting modderator aprouval on alsa-devel) i don't think i will send more bug reports to alsa. How long ago was this? alsa-devel has been accepting messages from non-subscribers for at least 6 months. It's from 10th of september 2004 I managed to find it on the internet: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.1/0996.html The same problem appears in 2.6.11 I'll repost the bug report asap Lee -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: > --- Dave Jones <[EMAIL PROTECTED]> a écrit : > Taking into account that nobody responded on lkml nor > on alsa (the message was awaiting modderator aprouval > on alsa-devel) i don't think i will send more bug reports > to alsa. How long ago was this? alsa-devel has been accepting messages from non-subscribers for at least 6 months. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: > I reported once a bug on alsa-devel and cc-ed on lkml > The sequencer isn't working with my card cs4239 with alsa. > What exactly do you mean by "it isn't working"? 90% of "MIDI does not work" bug reports are from users who expect playing MIDI files to work OOTB like it does on Mac and Windows. This only works because those OS'es come bundled with a toy softsynth. With ALSA, you either need a supported hardware wavetable synth (emu10k1) or a real soft synth like Timidity or Fluidsynth. Anyway, please repost your bug report to alsa-devel. There is no point in cc'ing LKML for ALSA problems, unless you find a problem like a regression in ALSA functionality from one kernel release to another. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Jeff Garzik <[EMAIL PROTECTED]> wrote: > Greg KH wrote: > > On Wed, Mar 02, 2005 at 05:15:36PM -0800, Linus Torvalds > wrote: > > > > > > But when pressed about the issue of speed of development, > rate of > > change, feature increase, driver updates, and so on, no one > else has any > > clue of what to do. They respond with, "but only put > bugfixes into a > > stable release." My comeback is explaining how we handle > lots of > > different types of bugfixes, by api changes, real fixes, and > driver > > updates for new hardware. Sometimes these cause other bugs > to happen, > > or just get shaken out where they were previously hiding > (acpi is a > > great example of this issue.) In the end, they usually fall > back on > > muttering, "well, I'm just glad that I'm not a kernel > developer..." and > > back away. > > The pertinent question for a point release (2.6.X.Y) would > simply be > "does a 2.6.11 user really need this fix?" > no. If something is not working in 2.6.11 i will switch to 2.6.10 ;-) and _maybe_ report a bug > > > Like I previously said, I think we're doing a great job. > The current > > -mm staging area could use some more testers to help weed > out the real > > issues, and we could do "real" releases a bit faster than > every 2 months > > or so. But other than that, we have adapted over the years > to handle > > this extremely high rate of change in a pretty sane manner. > > I think Linus's "even/odd" proposal is an admission that 2.6.X > releases > need some important fixes after it hits kernel.org. > > Otherwise 2.6.X is simply a constantly indeterminent state. > Let me tell you what i understood from this thread: 2.6.12 "almost stable" 2.6.13 devel (new drivers,fixes and stuff -- may be broken) 2.6.14 (based on 2.6.13) tries to became stable again 2.6.15 also devel (see above) 2.6.16 (based on 2.6.15) also tries to became stable again So we will _want_ to have a stable kernel (like 2.4 now) but this will never happen (see above) > We need to serve users, not just make life easier for kernel > developers ;-) > You said it. Hopefully you will make our life easier and we (as testers) will make your's. > Jeff > -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
szonyi calin <[EMAIL PROTECTED]> wrote: > > I reported once a bug on alsa-devel and cc-ed on lkml > The sequencer isn't working with my card cs4239 with alsa. > I cannot find your report (checked back to the start of the year). Please send a new one. I'm collection them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Dave Jones <[EMAIL PROTECTED]> a écrit : > > Grump. Have all these regressions received the appropriate > level of > > visibility on this mailing list? > > For the most part these things are usually known about by > their upstream > authors. To give an example: ALSA update in 2.6.10 broke > sound for a > bunch of IBM thinkpads. As it turns out there are quite a lot > of these > out there, so when I released a 2.6.10 update for Fedora, > bugzilla lit > up like a christmas tree with "Hey, where'd my sound go?" > reports. > (It was further confused by a load of other sound card > problems, but > thats another issue). This got so out of control, Alan asked > the ALSA > folks to take a look, and iirc Takashi figured out what had > caused the > problem, and it got fixed in the ALSA folks tree, and > subsequently, in 2.6.11rc. > > Now, during all this time, there hadn't been any reports of > this problem > at all on Linux-kernel. Not even from Linus' tree, let alone > -mm. > Which amazes me given how widespread the problem was. > I reported once a bug on alsa-devel and cc-ed on lkml The sequencer isn't working with my card cs4239 with alsa. Taking into account that nobody responded on lkml nor on alsa (the message was awaiting modderator aprouval on alsa-devel) i don't think i will send more bug reports to alsa. Maybe more people are testing the kernel but they don't have time to report the bugs (for me it takes about 15 minutes to do it properly). And some bugs like "i had a crash last night" are irrelevant if i don't have some logs traces. And _you_ (most of you) _want_ _people_ _to_ _test_ _2.6_ _kernels_ *and in the mean time* _you_ _recommend_ _using_ _vendor_ _kernels_. So if i want also a stable kernel i should use two trees (a vendor tree and a "2.6..whatever" tree) to compile the kernel ? How about mm-tree ? The whole 2.6. tree is strange. On one side you have -mm where all the "experimental" stuff goes and on the other side there is Linus's tree (2.6.x) where also some "experimental" stuff goes. (from a luser/tester point of view) Also some people need time to test. I have 4 hours free every day. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://mail.yahoo.fr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Zwane Mwaikambo <[EMAIL PROTECTED]> wrote: > > Certainly -mm can be the feature tree, but i've noticed that > not that many > people run -mm aside from developers. Meaning that a fair > number of bugs > seep into Linus' tree before they get attended to. It would > even be more > effective if we could get more -mm user coverage. A Linus > based odd number > might be closer to that if we hope on people unwittingly > running them. I used to run mm. I don't submit bug reports because i'm lazy ;-). Now i don't run it because 2.6 doesn't look very usable and i don't want to test two development versions. Also sometimes is handy to have a stable version around when something goes wrong (i.e. filesystem corruption after a crash or power failure). I had my filesystem trashed with 2.6 so i'm more carefull now. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Linus Torvalds wrote: Okay, I stayed out of this until the dust has settled, but I do have a few thoughts. First is that naming is important if people are to understand the release system, and I think a lot of people don't. So why not: - put out -devN kernel for testing, lots of people don't know about -bk or how to patch. And have the changelog list only the major new features and bug fixes, no author, no date, just a list of the important changes. That means that the user can see, not internal performance tuning and such. - call the first rc -rc0, which indicates that only bug fixes from this point on, and the level of stability (no much). I think about rc1 people would be more willing to test, and if I have a problem and the -dev claims a solution, I would be more willing to test, which might catch more of the "this crap doesn't even compile" errors. So let's loook at how we could set that up. We need: - some very _technical_ and objective rules on patches. And they should limit the patches severely, so that people can never blame the sucker who does the job. For example, I would suggest that "size" be one hard technical rule. If the patch is more than 100 lines (with context) in size, it's not trivial any more. Really. Two big screenfuls (or four, for people who still use the ISO-ANSI standard 80x24 vt100) It's your ruleset, but I think the next rule is adequate. If there's a serious problem, and the solution means fixing bad locking in 50 places easily identified, it's probably still worth fixing if there's no band-aid available. In short, trust the maintainer to make a good call on this. Also, I'd suggest that a _hard_ rule (ie nobody can override it) would also be that the problem causes an oops, a hang, or a real security problem that somebody can come up with an exploit for (ie no "there could be a two-instruction race" crap. Only "there is a race, and here's how you exploit it"). The exploit wouldn't need to be full code that gets root, but an explanation of it, at least. Yeah. - a vetting process. You'd have ten people, and five of them would have to sign off on the patch, and even a single veto would shoot it down. Way overkill, if the maintainer can be trusted to either understand or pass the vetting to someone who does, more eyes increase the probability if someone rejecting a valid patch because they didn't understand it. Again, this is really to protect the sucker, and make it possible to work: I don't think this can work with a creative person (everybody else calls me "flaky", and I much prefer that "creative" word, it sounds so much better), which I personally believe means that we don't _want_ people like Alan, Andrea, Andrew etc etc that have historically maintained their own trees that sometimes have tried to do something like this. I doubt he feels the need, paperwork for the sake of paperwork... - Finally: this tree never has any history past the "last release". When a new kernel comes, the tree is frozen, and never to be touched again. Which bouncds the effort to maintain a stable tree. Does this mean that some patches would never go into this tree? Yes. It would mean that patches that some people might feel very _strongly_ are good patches would never ever show up in this tree, but on the other hand, I can see this tree being useful regardless, and I think the lack of flexibility in this case is actually the whole _point_ of the tree. The lack of flexibility is the very thing that makes this be the kind of base that anybody else can then hang their own patches on top of. There should never be a situation where "I'd like that tree, but I think was done wrong". As must be to be stable. Might something like this make people happier? (I wrote "happy" rather than "happier" at first, but let's face it, people are better at whining than they are at being happy ;) I think this is just what's needed, and it addresses both the delay in getting new features in as well as delay in getting fixes in a stable kernel. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote: > > Looking at the http://l4x.org/k/ site, it appears that all -mm versions > > have broken ARM support with the defconfig, while Linus kernels at least > > build fine. > > It's very much in an arch maintainer's interest to make sure that > cross-compilers are easily obtainable. Any hints? In theory. In practice on some platforms we need special compiler patches which will never be accepted into gcc upstream or are restricted to particular versions of tools. Building crosstools is tricky and yet it seems every moron really has to toll it's own from his private mouldy collection of patches. The whole tools stuff has become very much a battlefield of it's own. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- "Randy.Dunlap" <[EMAIL PROTECTED]> a écrit : > > Maybe I don't understand? Is someone expecting distro > quality/stability from kernel.org kernels? > I don't, but maybe I'm one of those minorities. > yes. Some people (like me) would like to use from time to time some _new_ stable kernel. It's annoying to see that sometimes kernel people say that you have a hardware problem in 2.6.0 release and then the bug is silently fixed in a 2.6.5 release for example. The 2.6 kernel is not good enough for desktop -- sound skips on a 700Mhz duron when there is a lot (50M of 256) of free memory and mozilla is using CPU. 2.4 with preemptible patches was better in that respect. What i would like to really have is a stable version not a demo version. I like testing but sometimes i also want stability and it seems that a good enough 2.6 kernel is still away. I don't care how you call it 2.6.x.y.z-rc-kappa i just want to be sure that it will not mess up my system. (and no, i'm not going to use kernel ) Just my 2 euro cents (if somebody cares) P.S. I know this message is late. Sorry if it annoys you. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Randy.Dunlap [EMAIL PROTECTED] a écrit : Maybe I don't understand? Is someone expecting distro quality/stability from kernel.org kernels? I don't, but maybe I'm one of those minorities. yes. Some people (like me) would like to use from time to time some _new_ stable kernel. It's annoying to see that sometimes kernel people say that you have a hardware problem in 2.6.0 release and then the bug is silently fixed in a 2.6.5 release for example. The 2.6 kernel is not good enough for desktop -- sound skips on a 700Mhz duron when there is a lot (50M of 256) of free memory and mozilla is using CPU. 2.4 with preemptible patches was better in that respect. What i would like to really have is a stable version not a demo version. I like testing but sometimes i also want stability and it seems that a good enough 2.6 kernel is still away. I don't care how you call it 2.6.x.y.z-rc-kappa i just want to be sure that it will not mess up my system. (and no, i'm not going to use insert your favourite distro kernel ) Just my 2 euro cents (if somebody cares) P.S. I know this message is late. Sorry if it annoys you. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 03:26:32AM -0800, Andrew Morton wrote: Looking at the http://l4x.org/k/ site, it appears that all -mm versions have broken ARM support with the defconfig, while Linus kernels at least build fine. It's very much in an arch maintainer's interest to make sure that cross-compilers are easily obtainable. Any hints? In theory. In practice on some platforms we need special compiler patches which will never be accepted into gcc upstream or are restricted to particular versions of tools. Building crosstools is tricky and yet it seems every moron really has to toll it's own from his private mouldy collection of patches. The whole tools stuff has become very much a battlefield of it's own. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Linus Torvalds wrote: Okay, I stayed out of this until the dust has settled, but I do have a few thoughts. First is that naming is important if people are to understand the release system, and I think a lot of people don't. So why not: - put out -devN kernel for testing, lots of people don't know about -bk or how to patch. And have the changelog list only the major new features and bug fixes, no author, no date, just a list of the important changes. That means that the user can see, not internal performance tuning and such. - call the first rc -rc0, which indicates that only bug fixes from this point on, and the level of stability (no much). I think about rc1 people would be more willing to test, and if I have a problem and the -dev claims a solution, I would be more willing to test, which might catch more of the this crap doesn't even compile errors. So let's loook at how we could set that up. We need: - some very _technical_ and objective rules on patches. And they should limit the patches severely, so that people can never blame the sucker who does the job. For example, I would suggest that size be one hard technical rule. If the patch is more than 100 lines (with context) in size, it's not trivial any more. Really. Two big screenfuls (or four, for people who still use the ISO-ANSI standard 80x24 vt100) It's your ruleset, but I think the next rule is adequate. If there's a serious problem, and the solution means fixing bad locking in 50 places easily identified, it's probably still worth fixing if there's no band-aid available. In short, trust the maintainer to make a good call on this. Also, I'd suggest that a _hard_ rule (ie nobody can override it) would also be that the problem causes an oops, a hang, or a real security problem that somebody can come up with an exploit for (ie no there could be a two-instruction race crap. Only there is a race, and here's how you exploit it). The exploit wouldn't need to be full code that gets root, but an explanation of it, at least. Yeah. - a vetting process. You'd have ten people, and five of them would have to sign off on the patch, and even a single veto would shoot it down. Way overkill, if the maintainer can be trusted to either understand or pass the vetting to someone who does, more eyes increase the probability if someone rejecting a valid patch because they didn't understand it. Again, this is really to protect the sucker, and make it possible to work: I don't think this can work with a creative person (everybody else calls me flaky, and I much prefer that creative word, it sounds so much better), which I personally believe means that we don't _want_ people like Alan, Andrea, Andrew etc etc that have historically maintained their own trees that sometimes have tried to do something like this. I doubt he feels the need, paperwork for the sake of paperwork... - Finally: this tree never has any history past the last release. When a new kernel comes, the tree is frozen, and never to be touched again. Which bouncds the effort to maintain a stable tree. Does this mean that some patches would never go into this tree? Yes. It would mean that patches that some people might feel very _strongly_ are good patches would never ever show up in this tree, but on the other hand, I can see this tree being useful regardless, and I think the lack of flexibility in this case is actually the whole _point_ of the tree. The lack of flexibility is the very thing that makes this be the kind of base that anybody else can then hang their own patches on top of. There should never be a situation where I'd like that tree, but I think was done wrong. As must be to be stable. Might something like this make people happier? (I wrote happy rather than happier at first, but let's face it, people are better at whining than they are at being happy ;) I think this is just what's needed, and it addresses both the delay in getting new features in as well as delay in getting fixes in a stable kernel. -- -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Zwane Mwaikambo [EMAIL PROTECTED] wrote: Certainly -mm can be the feature tree, but i've noticed that not that many people run -mm aside from developers. Meaning that a fair number of bugs seep into Linus' tree before they get attended to. It would even be more effective if we could get more -mm user coverage. A Linus based odd number might be closer to that if we hope on people unwittingly running them. I used to run mm. I don't submit bug reports because i'm lazy ;-). Now i don't run it because 2.6 doesn't look very usable and i don't want to test two development versions. Also sometimes is handy to have a stable version around when something goes wrong (i.e. filesystem corruption after a crash or power failure). I had my filesystem trashed with 2.6 so i'm more carefull now. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Dave Jones [EMAIL PROTECTED] a écrit : Grump. Have all these regressions received the appropriate level of visibility on this mailing list? For the most part these things are usually known about by their upstream authors. To give an example: ALSA update in 2.6.10 broke sound for a bunch of IBM thinkpads. As it turns out there are quite a lot of these out there, so when I released a 2.6.10 update for Fedora, bugzilla lit up like a christmas tree with Hey, where'd my sound go? reports. (It was further confused by a load of other sound card problems, but thats another issue). This got so out of control, Alan asked the ALSA folks to take a look, and iirc Takashi figured out what had caused the problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc. Now, during all this time, there hadn't been any reports of this problem at all on Linux-kernel. Not even from Linus' tree, let alone -mm. Which amazes me given how widespread the problem was. I reported once a bug on alsa-devel and cc-ed on lkml The sequencer isn't working with my card cs4239 with alsa. Taking into account that nobody responded on lkml nor on alsa (the message was awaiting modderator aprouval on alsa-devel) i don't think i will send more bug reports to alsa. Maybe more people are testing the kernel but they don't have time to report the bugs (for me it takes about 15 minutes to do it properly). And some bugs like i had a crash last night are irrelevant if i don't have some logs traces. And _you_ (most of you) _want_ _people_ _to_ _test_ _2.6_ _kernels_ *and in the mean time* _you_ _recommend_ _using_ _vendor_ _kernels_. So if i want also a stable kernel i should use two trees (a vendor tree and a 2.6..whatever tree) to compile the kernel ? How about mm-tree ? The whole 2.6. tree is strange. On one side you have -mm where all the experimental stuff goes and on the other side there is Linus's tree (2.6.x) where also some experimental stuff goes. (from a luser/tester point of view) Also some people need time to test. I have 4 hours free every day. -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://mail.yahoo.fr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
szonyi calin [EMAIL PROTECTED] wrote: I reported once a bug on alsa-devel and cc-ed on lkml The sequencer isn't working with my card cs4239 with alsa. I cannot find your report (checked back to the start of the year). Please send a new one. I'm collection them. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
--- Jeff Garzik [EMAIL PROTECTED] wrote: Greg KH wrote: On Wed, Mar 02, 2005 at 05:15:36PM -0800, Linus Torvalds wrote: But when pressed about the issue of speed of development, rate of change, feature increase, driver updates, and so on, no one else has any clue of what to do. They respond with, but only put bugfixes into a stable release. My comeback is explaining how we handle lots of different types of bugfixes, by api changes, real fixes, and driver updates for new hardware. Sometimes these cause other bugs to happen, or just get shaken out where they were previously hiding (acpi is a great example of this issue.) In the end, they usually fall back on muttering, well, I'm just glad that I'm not a kernel developer... and back away. The pertinent question for a point release (2.6.X.Y) would simply be does a 2.6.11 user really need this fix? no. If something is not working in 2.6.11 i will switch to 2.6.10 ;-) and _maybe_ report a bug Like I previously said, I think we're doing a great job. The current -mm staging area could use some more testers to help weed out the real issues, and we could do real releases a bit faster than every 2 months or so. But other than that, we have adapted over the years to handle this extremely high rate of change in a pretty sane manner. I think Linus's even/odd proposal is an admission that 2.6.X releases need some important fixes after it hits kernel.org. Otherwise 2.6.X is simply a constantly indeterminent state. Let me tell you what i understood from this thread: 2.6.12 almost stable 2.6.13 devel (new drivers,fixes and stuff -- may be broken) 2.6.14 (based on 2.6.13) tries to became stable again 2.6.15 also devel (see above) 2.6.16 (based on 2.6.15) also tries to became stable again So we will _want_ to have a stable kernel (like 2.4 now) but this will never happen (see above) We need to serve users, not just make life easier for kernel developers ;-) You said it. Hopefully you will make our life easier and we (as testers) will make your's. Jeff -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: I reported once a bug on alsa-devel and cc-ed on lkml The sequencer isn't working with my card cs4239 with alsa. What exactly do you mean by it isn't working? 90% of MIDI does not work bug reports are from users who expect playing MIDI files to work OOTB like it does on Mac and Windows. This only works because those OS'es come bundled with a toy softsynth. With ALSA, you either need a supported hardware wavetable synth (emu10k1) or a real soft synth like Timidity or Fluidsynth. Anyway, please repost your bug report to alsa-devel. There is no point in cc'ing LKML for ALSA problems, unless you find a problem like a regression in ALSA functionality from one kernel release to another. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Wed, 2005-03-09 at 00:25 +0100, szonyi calin wrote: --- Dave Jones [EMAIL PROTECTED] a écrit : Taking into account that nobody responded on lkml nor on alsa (the message was awaiting modderator aprouval on alsa-devel) i don't think i will send more bug reports to alsa. How long ago was this? alsa-devel has been accepting messages from non-subscribers for at least 6 months. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Sul, 2005-03-06 at 07:53, Andres Salomon wrote: > On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote: > There's also no other (suitable) place to announce kernel trees. Debian > kernels get announced on various debian-related lists; I'd imagine FC > kernels have the same thing. The only place to announce non-distro trees > is lkml (and I've had requests for an -as specific announce list, I > haven't haven't found the time to get something going). Please keep announcing them here - its useful to see all the trees in one place. I certainly look at the others to make sure I don't miss stuff. We might not agree on what should be merged but the cross checking is valuable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Sul, 2005-03-06 at 22:43, Pavel Machek wrote: > > 2.6.x.y needs several people to keep it tight and to ensure there is > > always cover on a security fix. > > Eh? > > Like you add security fix and then some formatting change to hide it? Cover has rather too many meanings I guess. Cover as in "there is someone available to handle it" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Hi! > > The point is that it's happening anyway. See Andres' -as tree which > > is the basis for the Debian vendor kernel. Getting that up to an > > official status as 2.6.x.y would be very nice (and having it on > > linux.bkbits.net) > > IMHO it is nowhere near conservative enough (or at times complete > enough) to be a 2.6.x.y kernel. In some respects -ac is closer but it > also isn't as conservative as a real 2.6.x.y should be. > > 2.6.x.y needs several people to keep it tight and to ensure there is > always cover on a security fix. Eh? Like you add security fix and then some formatting change to hide it? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Sun, Mar 06, 2005 at 02:53:26AM -0500, Andres Salomon wrote: > There's also no other (suitable) place to announce kernel trees. Debian > kernels get announced on various debian-related lists; I'd imagine FC > kernels have the same thing. The only place to announce non-distro trees > is lkml (and I've had requests for an -as specific announce list, I > haven't haven't found the time to get something going). Andres, considering that your kernels' purpose is to provide a stabler base than mainline to people who still want to stay close to mainline, I think that your announces bring some real value here. What does not have its place here are the announces of full-featured patchsets not targetted at developpers nor testers. Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Sun, Mar 06, 2005 at 02:53:26AM -0500, Andres Salomon wrote: There's also no other (suitable) place to announce kernel trees. Debian kernels get announced on various debian-related lists; I'd imagine FC kernels have the same thing. The only place to announce non-distro trees is lkml (and I've had requests for an -as specific announce list, I haven't haven't found the time to get something going). Andres, considering that your kernels' purpose is to provide a stabler base than mainline to people who still want to stay close to mainline, I think that your announces bring some real value here. What does not have its place here are the announces of full-featured patchsets not targetted at developpers nor testers. Cheers, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Hi! The point is that it's happening anyway. See Andres' -as tree which is the basis for the Debian vendor kernel. Getting that up to an official status as 2.6.x.y would be very nice (and having it on linux.bkbits.net) IMHO it is nowhere near conservative enough (or at times complete enough) to be a 2.6.x.y kernel. In some respects -ac is closer but it also isn't as conservative as a real 2.6.x.y should be. 2.6.x.y needs several people to keep it tight and to ensure there is always cover on a security fix. Eh? Like you add security fix and then some formatting change to hide it? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Sul, 2005-03-06 at 22:43, Pavel Machek wrote: 2.6.x.y needs several people to keep it tight and to ensure there is always cover on a security fix. Eh? Like you add security fix and then some formatting change to hide it? Cover has rather too many meanings I guess. Cover as in there is someone available to handle it - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Sul, 2005-03-06 at 07:53, Andres Salomon wrote: On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote: There's also no other (suitable) place to announce kernel trees. Debian kernels get announced on various debian-related lists; I'd imagine FC kernels have the same thing. The only place to announce non-distro trees is lkml (and I've had requests for an -as specific announce list, I haven't haven't found the time to get something going). Please keep announcing them here - its useful to see all the trees in one place. I certainly look at the others to make sure I don't miss stuff. We might not agree on what should be merged but the cross checking is valuable. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote: > On Thu, Mar 03, 2005 at 04:28:52PM -0500, Jeff Garzik wrote: >> Bill Rugolsky Jr. wrote: >> >I've watched you periodically announce "hey, I'm doing an update for >> >FC3/FC2, please test" on the mail list, and a handful of people go test. >> >If we could convince many of the the less risk-averse but lazy users to >> >grab kernels automatically from updates/3/testing/ or updates/3/unstable/ >> >as part of "yum update", and have a way to manage the plethora of (even >> >daily) kernel updates by removing old unused kernels, then we'd only >> >have to convince them *once* to set up their YUM repos, and then get them >> >to poweroff or reboot [or use a Xen domain] occasionally. :-) >> >> >> Tangent: I would like to see requests-for-testing for FC kernels on LKML. >> >> If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why not distro >> kernels? > > Debian unstable currently contains only for kernel 2.6.8 (which is AFAIK > still the main kernel in Debian unstable although there are also 2.6.10 > sources and 2.6.10 kernel images on some architectures) for eight > different architectures - many of them containing or depending on their > own patches. > There's also no other (suitable) place to announce kernel trees. Debian kernels get announced on various debian-related lists; I'd imagine FC kernels have the same thing. The only place to announce non-distro trees is lkml (and I've had requests for an -as specific announce list, I haven't haven't found the time to get something going). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Clearly I picked a bad week to go on vacation.. On Fri, 04 Mar 2005 10:18:41 -0800, Linus Torvalds wrote: [...] > > Alan, I think your problem is that you really think that the tree _I_ want > is what _you_ want. > > I look at this from a _layering_ standpoint. Not from a "stable tree" > standpoint at all. > > We're always had the "wild" kernels, and 90% of the time the point of the > "wild" kernels has been to let people test out the experimental stuff, > that's not always ready for merging. Like it or not, I've considered even > the -ac kernel historically very much a "wild" thing, not a "bugfixes" > thing. > > What I'd like to set up is the reverse. The same way the "wild" kernels > tend to layer on top of my standard kernel, I'd like to have a lower > level, the "anti-wild" kernel. Something that is comprised of patches > that _everybody_ can agree on, and that doesn't get anything else. AT ALL. > That is what I'm trying to do w/ my tree; obvious fixes only. Most of the patches I've included in 2.6.10-asX have been stupid build fixes, and basic C problems (ie, deref'ing a pointer before it's been assigned). The main time I make exceptions for that is for security fixes. > And that means that such a kernel would not get all patches that you'd > want. That's fine. That was never the aim of it. The _only_ point of > this kernel would be to have a baseline that nobody can disagree with. > > In other words, it's not a "let's fix all serious bugs we can fix", but > a "this is the least common denominator that is basically acceptable to > everybody, regardless of what their objectives are". > > So if you want to fix a security issue, and the fix is too big or > invasive or ugly for the "least common denominator" thing, then it > simply does not _go_ into that kernel. At that point, it goes into an > -ac kernel, or into my kernel, or into a vendor kernel. See? > This is understandable. I have included security fixes in -as that were non-trivial; if a 2.6.x.y tree is not willing to include them, then I guess it won't be what I was hoping. I had emailed Chris before going on vacation, offering to work with him on 2.6.x.y (which would allow me to drop -as), but if security fixes aren't a higher priority thing (even in the face of invasive/ugly changes), then I guess there's still a need for -as/-ac. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 08:41:34PM +0100, Jesper Juhl wrote: > That's true. I guess my lack of trust in vendor kernels is part being > bitten by them in the past where my own custom build vanilla kernels have > worked fine, and part the fear of getting locked-in to some vendor > specific feature... Perhaps things are different these days and I should > reevaluate my view on vendor kernels - but that's why I haven't been > trusting them. Traditionally the vendor kernels from the big two vendors have been full of crap, for one of them it seems to be slowly changing now.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Russell King: Two things - are you sure that openembedded contains the patches to fix the two biggest binutils issues we have, as documented on http://www.arm.linux.org.uk/developer/toolchain/ ? I've checked and it contains the tc-arm.c.patch but does not have the ARM mapping symbols fix. As recent kernels have fixes for that, its not so much of a problem as it was however it should be staightforward to add into oe and I will aim to do that. Secondly, are you seriously suggesting people like Jan Dittmer, who provide a cross-architecture service should jump through some loops just to get a working toolchain for the ARM architecture? You said nobody was willing/interested in maintaining a toolchain. I'm saying that a toolchain is maintained within openembedded and that pointing people at that is better than nothing. Maintaining a set of patches to ensure bugs in binutils etc are fixed is easy within oe's framework. (To add the above patch, in theory I just need to add a line to a file). Jan Dittmer: As long it is documented and it _works_ that's no problem. But it was quite a hassle to get working cross-compilers for all 23 archs to build, because for some there is no real documentation which target is the correct one and upstream gcc and/or binutils sometimes don't compile. This is why openembedded exists - it tracks known working build configurations of every bit of software needed to make complete linux distributions. How much work is it to set-up an openembedded environment anyways? I've written a quick and dirty set of instructions on setting up openembedded below. Please note that oe is used for building complete linux distributions so there is a lot of functionality being unused here (as you can imagine from my statement above). bitbake is a known memory hog (it can use up to 1GB of ram) - we all know this is appalling and a rewrite to address this is in progress. cd /work/ svn co svn://svn.berlios.de/bitbake/trunk/bitbake export PATH=/work/bitbake/bin:$PATH bk clone bk://openembedded.bkbits.net/openembeded export BBPATH=/work/build:/work/openembedded mkdir build mkdir build/conf/ cp openembedded/conf/local.conf.sample build/conf/local.conf Edit local.conf as appropriate. local.conf.sample has details about what the variables do. My local.conf to generate the arm toolchain has: DL_DIR="/work/sources" BBFILES="/work/openembedded/packages/*/*.bb" TARGET_ARCH="arm" TARGET_OS="linux" INHERIT="package_tar" (everything else is left unchanged) cd build bitbake binutils-cross-sdk bitbake gcc-cross-sdk Output ends up in /work/build/tmp/deploy Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 11:32:18AM +, Ian Campbell wrote: > On Fri, 2005-03-04 at 11:16 +, Russell King wrote: > > On Fri, Mar 04, 2005 at 11:11:38AM +, Ian Campbell wrote: > > > On Fri, 2005-03-04 at 10:52 +, Russell King wrote: > > > > Unfortunately, http://l4x.org/k/ doesn't save any build logs for > > > > investigation. > > > > > > If you click the 'Fail' then it seems to keep the make output etc. > > > > elinks doesn't show any of the "fail" in the matrix as links - this > > seems to be using javascript. > > > > In fact there doesn't appear to be a reason to use javascript for > > this - it seems to be implementing a standard link to: > > The links and row headers high-light when you mouse over each cell, > which appears to be why there is javascript involved at all. > > I don't know if javascript is necessary for that feature, but I agree > that using it for the links seems wrong. No it isn't necessary; the CSS attribute :hover is the correct way to do this. Using Javascript for any kind of design is just wrong, wrong, wrong. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
John Alvord wrote: One way to handle the transition into bug-fix only would be to turn the tree over to the $stability crew at that moment. They would have the job of nursing it to stability under the given ground rules. Yes. However, the discussion is now over due to the .1 work which solves a different problem than was intended, which was getting more people to test kernels before they become 2.6.N final. It's going to take another few months again now for people to notice that, but oh well. Personally, I don't have a problem anyway. I think 2.6 is great ... Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 03 Mar 2005 14:23:37 +0100, Rene Herman
<[EMAIL PROTECTED]> wrote:
>Jeff Garzik wrote:
>
>> Rene Herman wrote:
>>
>>> Doing -pre and real -rc will get you more testers for -rc. Whether or
>>
>>> Add in the fourth level .k releases for real problematic bugs found
>>> after release as you did with 2.6.8.1, and I believe things should work.
>>
>> Precisely.
>
>I assume that one of the main problems with doing -pre is that actually
>doing a real -rc isn't much fun -- I can certainly understand that
>sitting around twiddling your thumbs by decree every few weeks is not a
>good model.
>
>You commented on the .k 4th level releases being an actual branch, BK
>wise. To not let the forced thumb-twiddling -rc period be a problem,
>this branch could happen at -rc1, after which Linus is again free to go
>merge up stuff into mainline for the next one, if he wants to.
>
>That's to say, I propose Linus doesn't change _anything_ other than
>renaming his -rc's -pre's, and his final -rc1 (well, and making it a
>branch if -final isn't a branch now, sorry, not a clue).
>
>The -rc branch then just sits there, and if nothing turns up that needs
>an -rc2, it gets released as final, and possibly onto .1, .2 and so on
>if useful or need be.
>
>Now, coaching that -rc branch from -rc1 through maybe -rcN to -final and
>possibly beyond may not be something Linus wants to do. The -rc branch
>would by definition see _no_ activity other than the really needed so I
>don't believe it would be much of a burden time-wise, but it is in fact
>not unlike what Alan is already doing with -ac. So, if Linus doesn't
>want that job, Alan may? Or someone else?
>
>Summarising:
>
>- Linus:
>
> 1) rename 2.6.N-rcX to 2.6.N-preX
> 2) when you'd now release, branch off, release as -rc1
> 3) go on with 2.6.(N+1)-pre1
>
>- Linus, Alan, or whoever else wants the job:
>
> 1) release -rc{2,3,...} only if needed.
> 2) release 2.6.N
> 3) do a 2.6.N.{1,2,...} only if needed.
>
>Is this sane? The advantage is, real -pre's and -rc's which will get
>more people onboard testing -rc, and hopefully without annoying Linus
>with real no-changing -rc's. How many more, enough or not, remains to be
> seen but certainly more.
One way to handle the transition into bug-fix only would be to turn
the tree over to the $stability crew at that moment. They would have
the job of nursing it to stability under the given ground rules.
john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 03 Mar 2005 14:23:37 +0100, Rene Herman
[EMAIL PROTECTED] wrote:
Jeff Garzik wrote:
Rene Herman wrote:
Doing -pre and real -rc will get you more testers for -rc. Whether or
Add in the fourth level .k releases for real problematic bugs found
after release as you did with 2.6.8.1, and I believe things should work.
Precisely.
I assume that one of the main problems with doing -pre is that actually
doing a real -rc isn't much fun -- I can certainly understand that
sitting around twiddling your thumbs by decree every few weeks is not a
good model.
You commented on the .k 4th level releases being an actual branch, BK
wise. To not let the forced thumb-twiddling -rc period be a problem,
this branch could happen at -rc1, after which Linus is again free to go
merge up stuff into mainline for the next one, if he wants to.
That's to say, I propose Linus doesn't change _anything_ other than
renaming his -rc's -pre's, and his final -rc1 (well, and making it a
branch if -final isn't a branch now, sorry, not a clue).
The -rc branch then just sits there, and if nothing turns up that needs
an -rc2, it gets released as final, and possibly onto .1, .2 and so on
if useful or need be.
Now, coaching that -rc branch from -rc1 through maybe -rcN to -final and
possibly beyond may not be something Linus wants to do. The -rc branch
would by definition see _no_ activity other than the really needed so I
don't believe it would be much of a burden time-wise, but it is in fact
not unlike what Alan is already doing with -ac. So, if Linus doesn't
want that job, Alan may? Or someone else?
Summarising:
- Linus:
1) rename 2.6.N-rcX to 2.6.N-preX
2) when you'd now release, branch off, release as -rc1
3) go on with 2.6.(N+1)-pre1
- Linus, Alan, or whoever else wants the job:
1) release -rc{2,3,...} only if needed.
2) release 2.6.N
3) do a 2.6.N.{1,2,...} only if needed.
Is this sane? The advantage is, real -pre's and -rc's which will get
more people onboard testing -rc, and hopefully without annoying Linus
with real no-changing -rc's. How many more, enough or not, remains to be
seen but certainly more.
One way to handle the transition into bug-fix only would be to turn
the tree over to the $stability crew at that moment. They would have
the job of nursing it to stability under the given ground rules.
john alvord
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
John Alvord wrote: One way to handle the transition into bug-fix only would be to turn the tree over to the $stability crew at that moment. They would have the job of nursing it to stability under the given ground rules. Yes. However, the discussion is now over due to the .1 work which solves a different problem than was intended, which was getting more people to test kernels before they become 2.6.N final. It's going to take another few months again now for people to notice that, but oh well. Personally, I don't have a problem anyway. I think 2.6 is great ... Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 11:32:18AM +, Ian Campbell wrote: On Fri, 2005-03-04 at 11:16 +, Russell King wrote: On Fri, Mar 04, 2005 at 11:11:38AM +, Ian Campbell wrote: On Fri, 2005-03-04 at 10:52 +, Russell King wrote: Unfortunately, http://l4x.org/k/ doesn't save any build logs for investigation. If you click the 'Fail' then it seems to keep the make output etc. elinks doesn't show any of the fail in the matrix as links - this seems to be using javascript. In fact there doesn't appear to be a reason to use javascript for this - it seems to be implementing a standard link to: The links and row headers high-light when you mouse over each cell, which appears to be why there is javascript involved at all. I don't know if javascript is necessary for that feature, but I agree that using it for the links seems wrong. No it isn't necessary; the CSS attribute :hover is the correct way to do this. Using Javascript for any kind of design is just wrong, wrong, wrong. Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Russell King: Two things - are you sure that openembedded contains the patches to fix the two biggest binutils issues we have, as documented on http://www.arm.linux.org.uk/developer/toolchain/ ? I've checked and it contains the tc-arm.c.patch but does not have the ARM mapping symbols fix. As recent kernels have fixes for that, its not so much of a problem as it was however it should be staightforward to add into oe and I will aim to do that. Secondly, are you seriously suggesting people like Jan Dittmer, who provide a cross-architecture service should jump through some loops just to get a working toolchain for the ARM architecture? You said nobody was willing/interested in maintaining a toolchain. I'm saying that a toolchain is maintained within openembedded and that pointing people at that is better than nothing. Maintaining a set of patches to ensure bugs in binutils etc are fixed is easy within oe's framework. (To add the above patch, in theory I just need to add a line to a file). Jan Dittmer: As long it is documented and it _works_ that's no problem. But it was quite a hassle to get working cross-compilers for all 23 archs to build, because for some there is no real documentation which target is the correct one and upstream gcc and/or binutils sometimes don't compile. This is why openembedded exists - it tracks known working build configurations of every bit of software needed to make complete linux distributions. How much work is it to set-up an openembedded environment anyways? I've written a quick and dirty set of instructions on setting up openembedded below. Please note that oe is used for building complete linux distributions so there is a lot of functionality being unused here (as you can imagine from my statement above). bitbake is a known memory hog (it can use up to 1GB of ram) - we all know this is appalling and a rewrite to address this is in progress. cd /work/ svn co svn://svn.berlios.de/bitbake/trunk/bitbake export PATH=/work/bitbake/bin:$PATH bk clone bk://openembedded.bkbits.net/openembeded export BBPATH=/work/build:/work/openembedded mkdir build mkdir build/conf/ cp openembedded/conf/local.conf.sample build/conf/local.conf Edit local.conf as appropriate. local.conf.sample has details about what the variables do. My local.conf to generate the arm toolchain has: DL_DIR=/work/sources BBFILES=/work/openembedded/packages/*/*.bb TARGET_ARCH=arm TARGET_OS=linux INHERIT=package_tar (everything else is left unchanged) cd build bitbake binutils-cross-sdk bitbake gcc-cross-sdk Output ends up in /work/build/tmp/deploy Richard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 08:41:34PM +0100, Jesper Juhl wrote: That's true. I guess my lack of trust in vendor kernels is part being bitten by them in the past where my own custom build vanilla kernels have worked fine, and part the fear of getting locked-in to some vendor specific feature... Perhaps things are different these days and I should reevaluate my view on vendor kernels - but that's why I haven't been trusting them. Traditionally the vendor kernels from the big two vendors have been full of crap, for one of them it seems to be slowly changing now.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Clearly I picked a bad week to go on vacation.. On Fri, 04 Mar 2005 10:18:41 -0800, Linus Torvalds wrote: [...] Alan, I think your problem is that you really think that the tree _I_ want is what _you_ want. I look at this from a _layering_ standpoint. Not from a stable tree standpoint at all. We're always had the wild kernels, and 90% of the time the point of the wild kernels has been to let people test out the experimental stuff, that's not always ready for merging. Like it or not, I've considered even the -ac kernel historically very much a wild thing, not a bugfixes thing. What I'd like to set up is the reverse. The same way the wild kernels tend to layer on top of my standard kernel, I'd like to have a lower level, the anti-wild kernel. Something that is comprised of patches that _everybody_ can agree on, and that doesn't get anything else. AT ALL. That is what I'm trying to do w/ my tree; obvious fixes only. Most of the patches I've included in 2.6.10-asX have been stupid build fixes, and basic C problems (ie, deref'ing a pointer before it's been assigned). The main time I make exceptions for that is for security fixes. And that means that such a kernel would not get all patches that you'd want. That's fine. That was never the aim of it. The _only_ point of this kernel would be to have a baseline that nobody can disagree with. In other words, it's not a let's fix all serious bugs we can fix, but a this is the least common denominator that is basically acceptable to everybody, regardless of what their objectives are. So if you want to fix a security issue, and the fix is too big or invasive or ugly for the least common denominator thing, then it simply does not _go_ into that kernel. At that point, it goes into an -ac kernel, or into my kernel, or into a vendor kernel. See? This is understandable. I have included security fixes in -as that were non-trivial; if a 2.6.x.y tree is not willing to include them, then I guess it won't be what I was hoping. I had emailed Chris before going on vacation, offering to work with him on 2.6.x.y (which would allow me to drop -as), but if security fixes aren't a higher priority thing (even in the face of invasive/ugly changes), then I guess there's still a need for -as/-ac. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 03 Mar 2005 23:15:03 +0100, Adrian Bunk wrote: On Thu, Mar 03, 2005 at 04:28:52PM -0500, Jeff Garzik wrote: Bill Rugolsky Jr. wrote: I've watched you periodically announce hey, I'm doing an update for FC3/FC2, please test on the mail list, and a handful of people go test. If we could convince many of the the less risk-averse but lazy users to grab kernels automatically from updates/3/testing/ or updates/3/unstable/ as part of yum update, and have a way to manage the plethora of (even daily) kernel updates by removing old unused kernels, then we'd only have to convince them *once* to set up their YUM repos, and then get them to poweroff or reboot [or use a Xen domain] occasionally. :-) Tangent: I would like to see requests-for-testing for FC kernels on LKML. If people announce -ac/-as/-aa/-ck/etc. kernels on LKML, why not distro kernels? Debian unstable currently contains only for kernel 2.6.8 (which is AFAIK still the main kernel in Debian unstable although there are also 2.6.10 sources and 2.6.10 kernel images on some architectures) for eight different architectures - many of them containing or depending on their own patches. There's also no other (suitable) place to announce kernel trees. Debian kernels get announced on various debian-related lists; I'd imagine FC kernels have the same thing. The only place to announce non-distro trees is lkml (and I've had requests for an -as specific announce list, I haven't haven't found the time to get something going). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 3 Mar 2005, Linus Torvalds wrote: > On Thu, 3 Mar 2005, Jeff Garzik wrote: > > > > We have all these problems precisely because _nobody_ is saying "I'm > > only going to accept bug fixes". We _need_ some amount of release > > engineering. Right now we basically have none. > > I agree that this is one of the main problems. > > But look at how to solve it. The _logical_ solution is to have a third > line of defense: we have the -mm trees (wild and wacky patches), and we > have my tree (hopefully not wacky any more), and it would be good to have > a third level tree (which I'm just not interested in, because that one > doesn't do any development any more) which only takes the "so totally not > wild that it's really boring" patches. > > In fact, if somebody maintained that kind of tree, especially in BK, it > would be trivial for me to just pull from it every once in a while (like > ever _day_ if necessary). But for that to work, then that tree would have > to be about so _obviously_ not wild patches that it's a no-brainer. Sorry, I'm just on the end of this thread but I wanted to put in my 2 bits, I was maintaining this type of tree for 2.4 before. It was well received by those who used it and it was stable (h, I'm still running that puppy on a couple well hidden 7.2 servers). The key then was to only put in patches that fixed issues. If it was a hard factual solution to a problem then it went into the patch. BTW, it was just that, a patch (or set of patches) not actually a seperate tree. It was completely focused on stability as that's what I needed for work at the time. > So what's the problem with this approach? It would seem to make everybody > happy: it would reduce my load, it would give people the alternate "2.6.x > base kernel plus fixes only" parallell track, and it would _not_ have the > testability issue (because I think a lot of people would be happy to test > that tree, and if it was always based on the last 2.6.x release, there > would be no issues. It was good for 2.4 and I think for 2.6, the legitimacy (coming from the top down) will be a good thing. It wasn't as widely received in 2.4 due to it not being "officially sanctioned"... BTW, it's not actually that much work. Watching the list and getting feed back on what works and what doesn't is all that it takes. Naturally, there will be a couple "frell, where was I when I did that" patches but that's life in the semi-fast lane. This will be a good thing. Regards James -- James Bourne | Email:[EMAIL PROTECTED] UNIX Systems Administration | WWW: http://www.hardrock.org Custom UNIX Programming | Linux: The choice of a GNU generation -- "All you need's an occasional kick in the philosophy." Frank Herbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Rene Herman wrote: Linus Torvalds wrote: I've long since decided that there's no point to making "-pre". What's the difference between a "-pre" and a daily -bk snapshot? Really? The fact that not a script, but Linus Torvalds, decides that the tree is in a state he likes to share with others. You have been doing -pre's all this time, it's just that you are calling them -rc's. remember that there are the nightly CVS dumps and patches being created as well. from my point of view it appears that when Linus releases -rc1 he is hopeing that it's actually going to be final, but since nobody bothers to test before that it has never actually been the case. As a result additional changes need to be done and Linus chooses to fix it by moving forward and doing additional fixes rather then by reverting patches. He does allow some additional patches to move in as well for a little while, but all of them are expected to be fixes. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 12:37:05PM -0800, Linus Torvalds wrote: >... > I used to do "-pre", a long time ago. Exactly because they were > synchronization points for developers. >... > So the point of -pre's are gone. Have people actually _looked_ at the -rc > releases? They are very much done when I reach the point and say "ok, > let's calm down". The first one is usually pretty big and often needs some > fixing, simply because the first one is _inevitably_ (and by design) the > one that gets the pent-up demand from the previous calming down period. > > But it's very much a call to "ok, guys, calm down now". My impression about your releases is that -rc1 is a first snapshot, but there are still invasive changes until -rc3 or -rc4 when you _really_ say "only obvious bug fixes will be accepted". It's _only about naming_: Name the first one -pre1 instead of -rc1 and the snapshot you announce with "only obvious bug fixes will be accepted" -rc1. It might not matter for you how it's called, but it does matter for other people and it doesn't cost you any extra effort. > And if you aren't calming down, it's _your_ problem. Complaining about > naming of -pre vs -rc is pointless. >... If I send a non-bugfix patch to Marcelo after 2.4.30-rc1 he'll say: "Thanks, queued for 2.4.31 ." > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Linus Torvalds wrote: > > > On Fri, 4 Mar 2005, Nicolas Pitre wrote: > > > > It might still be worth a try, especially since so many people are > > convinced this is the way to go (your fault or not is not the point). > > Making releases is actually a fair bit of work. Not the script itself, but > just deciding and trying to synchronize. The fatc that people won't really > appreciate it anyway, and just complain about "that's not stable anyway" > just makes me even less interested. Don't read me wrong. It's not the work that is being done which is the problem. To the contrary, the current process is really great and for one I hope 2.7.x will _never_ happen, and here's why: Coming from the embedded world I can tell you that 2.5.x was simply too "instable" to use as a basis for a product, and communities around non i386 architectures simply don't have enough man power to follow two kernel trees (2.4.x and 2.5.x) in parallel. The embedded world therefore ended up developing on 2.4.x only because that was the stable tree that could bring revenues to sustain said development, even if 2.4.x was a dead end. Now the catch up phase on 2.6.x within the embedded world is almost done and 2.6.x is also where the major developments are happening. It's therefore way easier for smaller communities to stay in the game since 2.6.x is also stable enough for commercial products despite the rapid development actually occurring there. There are certainly a few more stability glitches than you could have found in 2.4.x but overall 2.6.x is a much better compromise bringing much more value to us -- thanks to your hard work and Andrew's (and RMK's) and everybody else for making the current process so efficient and dynamic. Now back to the current discussion. What people are complaining about is the lack of testing on the official 2.6.x releases. This lack of testing comes from the fact that your -rc releases are not seen like stable enough for the mass to test, and this is due mainly because the people outside of the development loop have no idea when you actually called for a patch calm down. It's not like you don't actually call for a calm down in order to have a release stabilized because, as Andrew pointed out, you effectively only merged true bug fixes into 2.6.11-rc[45]. See? You _do_ it and you _did_ it already. The only issue is to actually have way more people to jump in and try out kernels which are in that "calm down" phase. And for that to happen you need a clear signal to the people outside the development loop who currently can't trust your -rc releases since they end up including more than just bug fixes up to a randomly chosen particular -rc. That's why many are suggesting that you consider switching to -pre releases for developer sync points, and for the last -pre release where you call for a calm down. Then subsequent releases are -rc releases with strictly bug fixes. For example, 2.6.11-rc[123] would have been 2.6.11-pre[123] and 2.6.11-rc[45] would have been 2.6.11-rc[12]. See how this won't change anything to your work methodology besides the naming? And this has the potential of bringing more testers not closely following lkml or the commit log (granted that -rc becomes real release-candidate-bug_fix_only releases but again you do that already) since they'll see those -rc releases as nearly official releases. Of course it might not bring the hoped result but it costs nothing to try it out. That's what I meant in my previous email. P.S.: this is not incompatible with the "sucker" tree -- in fact both of those things might be useful and effective for their own purpose. Nicolas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Friday 04 March 2005 15:37, Linus Torvalds wrote: [...] >No. > >I used to do "-pre", a long time ago. Exactly because they were >synchronization points for developers. > >These days, that's pointless. We keep the tree in pretty good > working order (certainly as good as my -pre's ever were) > constantly, and developers who need to can synchronize with either > the BK tree or the nightly snapshots. The fact is, 99% of the > developers don't even need to do that, since most of the > development process is quite well parallellised by now, and there > is seldom any serious overlap. And I think your use of bitkeeper is largely responsible for that. >So the point of -pre's are gone. Have people actually _looked_ at > the -rc releases? They are very much done when I reach the point > and say "ok, let's calm down". The first one is usually pretty big > and often needs some fixing, simply because the first one is > _inevitably_ (and by design) the one that gets the pent-up demand > from the previous calming down period. > >But it's very much a call to "ok, guys, calm down now". > >And if you aren't calming down, it's _your_ problem. Complaining > about naming of -pre vs -rc is pointless. > >The even/odd situation would have made for a situation that some > people seem to be arguing for (more explicit calming-down period), > but with the difference that I think the odd ones should definitely > have been user-release quality already. But that one was apparently > hated by so many people that it's not even worth trying. > >The fact is, there is no perfect way of doing things, and this > discussion has degenerated into nothing but whining. Which is kind > of expected, but let's hope that the only non-whining that came out > of this (Greg & co's trials with 2.6.x.y) ends up being worthwhile. > > Linus One last Q I guess. When was the last time somebody flushed a bug out of forcedeth? I built a kernel last night after turning off the broken flag, and when I rebooted to it this morning I was surprised to see that because its still marked experimental, I had no networking. And when I went to turn that back on, I also had to go turn that back on seperately. IMO, no usefull purpose is achieved by keeping it experimental after the amount of time thats gone by with 1/4 of the world whose mobo has an NForce2 chipset on it, using that as their networking driver. My $0.02. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
> That's now eight architectures I'll compile-test mm kernels on.
Cool, but please check whether this produces an error:
echo "mov r0, #foo" | arm-linux-as -o /dev/null -
you should get:
{standard input}: Assembler messages:
{standard input}:1: Error: undefined symbol foo used as an immediate value
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
"Richard Purdie" <[EMAIL PROTECTED]> wrote: > > As an experiment I ran "bitbake meta-sdk" on my copy of openemedded. A while > later I have these in the deploy directory amongst other things. > > http://www.rpsys.net/openzaurus/arm-cross/binutils-cross-sdk-2.15.91.0.2-r5.tar.gz > > (3.8MB) > http://www.rpsys.net/openzaurus/arm-cross/gcc-cross-sdk-3.4.2-r0.tar.gz > (17.5MB) Bless you. I just built an arm kernel! That compiler is *fast*. 47 seconds. Weird. For reference, untar the above in / and use #!/bin/sh export ARCH=arm export CROSS_COMPILE=arm-linux- W=/usr/local/arm/oe/bin MAKE="make" if [ -z "$1" ] then WHAT="vmlinux" else WHAT="$1" fi nr_cpus=$(grep processor /proc/cpuinfo|wc -l) j=$(expr $nr_cpus \* 3 / 2) MAKE_ARGS="ARCH=$ARCH CROSS_COMPILE=$W/arm-linux-" if [ x"$DISTCC_HOSTS" != x ] then $MAKE -j 12 CC="ccache distcc --ccache-skip $W/$CROSS_COMPILE""gcc" $MAKE_ARGS $WHAT 2>/tmp/log else $MAKE -j $j $MAKE_ARGS CC="$W/$CROSS_COMPILE""gcc" $WHAT 2>/tmp/log fi cat /tmp/log That's now eight architectures I'll compile-test mm kernels on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Russell King <[EMAIL PROTECTED]> wrote:
>
> On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
> > That's now eight architectures I'll compile-test mm kernels on.
>
> Cool, but please check whether this produces an error:
>
> echo "mov r0, #foo" | arm-linux-as -o /dev/null -
>
> you should get:
> {standard input}: Assembler messages:
> {standard input}:1: Error: undefined symbol foo used as an immediate value
I did get that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 02:48:08PM -0800, Andrew Morton wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Mar 04, 2005 at 02:22:19PM -0800, Andrew Morton wrote:
> > > That's now eight architectures I'll compile-test mm kernels on.
> >
> > Cool, but please check whether this produces an error:
> >
> > echo "mov r0, #foo" | arm-linux-as -o /dev/null -
> >
> > you should get:
> > {standard input}: Assembler messages:
> > {standard input}:1: Error: undefined symbol foo used as an immediate value
>
> I did get that.
Great - this will help ensure that any breakage due to that binutils
problem should get caught relatively quickly no matter how it gets in
to either your or Linus' kernel. This is a definite plus. Thanks.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Matt Mackall wrote:
> One last plea for the 2.4 scheme:
>
> I think naming the interim releases -pre/-rc has done this admirably
> for 2.4.
I agree. This makes more sense to me than some implicit understanding
about the parity of the revision.
rc is easy to understand, and '-pre' is easy to understand
once you recognize it means 'beta'.
I've been bothered in the 2.6 series that rc ("release candidate"?)
tags were applied to kernels that were clearly NOT release candidates.
=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 12:07:23PM -0700, Steven Cole wrote:
>
> Here's an idea which might just be too simple, but here it is anyway:
>
> Modifiy the bk snapshot scripts to name the 2.6.x series snapshots as -PREy
> instead of -BKy. That way, the general population of users will see
> the -bk snapshots as -pre releases. According to Linus, pre == bk. So,
> name them as such.
I heartily second this!! If "pre" == "bk", then make it "pre"!
> Linus, wait for at least two weeks before releasing the first -rc.
> That way, the bulk on the thundering herd of patches will be hopefully
> be merged by then. And users will have 2.6.x-PRE[1..14] to test.
> The hard part for the kernel.org script writer might be to disable
> the -bk/-pre snapshot once the first -rc is out.
Errh... personally, I find the -rc-bk snapshots to be useful sync
points. They're also what seems to make it into davej's
"rawhide"/"fc-devel" Fedora testing kernels. (Perhaps those don't get
widely tested, but they do get *some* testing -- e.g. they're how I
managed to hit (and get fixed) the TCP stack overflow.)
I guess the best thing would be for the script to revert to the current
("-bk") naming scheme once -rc1 is out. Otherwise it would need to do,
say, 2.6.12-rc2-pre1 instead of 2.6.12-rc1-bk1, and while that seems
natural to me, I don't know how the rest of the planet's human population
would react...
-Barry K. Nathan <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Rene Herman wrote: > > Linus Torvalds wrote: > > > I've long since decided that there's no point to making "-pre". What's the > > difference between a "-pre" and a daily -bk snapshot? Really? > > The fact that not a script, but Linus Torvalds, decides that the tree is > in a state he likes to share with others. You have been doing -pre's all > this time, it's just that you are calling them -rc's. No. I used to do "-pre", a long time ago. Exactly because they were synchronization points for developers. These days, that's pointless. We keep the tree in pretty good working order (certainly as good as my -pre's ever were) constantly, and developers who need to can synchronize with either the BK tree or the nightly snapshots. The fact is, 99% of the developers don't even need to do that, since most of the development process is quite well parallellised by now, and there is seldom any serious overlap. So the point of -pre's are gone. Have people actually _looked_ at the -rc releases? They are very much done when I reach the point and say "ok, let's calm down". The first one is usually pretty big and often needs some fixing, simply because the first one is _inevitably_ (and by design) the one that gets the pent-up demand from the previous calming down period. But it's very much a call to "ok, guys, calm down now". And if you aren't calming down, it's _your_ problem. Complaining about naming of -pre vs -rc is pointless. The even/odd situation would have made for a situation that some people seem to be arguing for (more explicit calming-down period), but with the difference that I think the odd ones should definitely have been user-release quality already. But that one was apparently hated by so many people that it's not even worth trying. The fact is, there is no perfect way of doing things, and this discussion has degenerated into nothing but whining. Which is kind of expected, but let's hope that the only non-whining that came out of this (Greg & co's trials with 2.6.x.y) ends up being worthwhile. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Nicolas Pitre wrote: > > It might still be worth a try, especially since so many people are > convinced this is the way to go (your fault or not is not the point). Making releases is actually a fair bit of work. Not the script itself, but just deciding and trying to synchronize. The fatc that people won't really appreciate it anyway, and just complain about "that's not stable anyway" just makes me even less interested. The undeniable _fact_ in this discussion is that we're merging a lot of patches - which is good, because that's how we keep 2.6.x relevant, and not just a dead branch. And that is also what makes it fundamentally different from 2.4.x, and I think a lot of people are just ignoring that fact. If people want a stable branch, they have to freeze their own thing. I and Andrew do a lot of work to keep 2.6.x releases high-quality, and I think we've been very successful in it too. The _whining_ from people who don't realize that we can't just stop running (because if we did, quality would go _down_ when we're then overwhelmed afterwards) is really quite grating, though. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFD: Kernel release numbering
> -fixup or -fixes maybe. x.y is OK too. :) How about Service Pack? :joke: I could never understand why we have confused users in the naming in 2.6 serials and are trying to confuse them even more.. Hua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Greg KH wrote: On Fri, Mar 04, 2005 at 11:12:22AM -0800, Linus Torvalds wrote: Let's try with the 2.6.x.y numbering scheme, it's simple, and maybe it ends up being sufficient. I just wanted to bring up the point that I don't think the sucker tree _has_ to be seen as a 2.6.x.y tree at all. Fair enough, I'll stick with 2.6.x.y, as I think it's a good representation of what people expect. If people start objecting, I'm always open for change. So far, 2.6.11.1 was what I was hoping, and expecting, it would be. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Jens Axboe wrote: > On Fri, Mar 04 2005, Jesper Juhl wrote: > > I run vanilla kernels on all my boxes, workstations and > > servers, since I don't really trust vendor kernels. > > That's a strange statement, I don't think you are aware of > the level of testing that goes into a vendor kernel, at > least for the 'enterprise' products. There's just no comparison > to the vanilla kernels. > I can't claim to have any detailed knowledge of that, no. > Of course fixes get merged back into the vanilla kernels, but > these just don't have the lengthy test and maturity period > of vendor kernels (by a long stretch). > That's true. I guess my lack of trust in vendor kernels is part being bitten by them in the past where my own custom build vanilla kernels have worked fine, and part the fear of getting locked-in to some vendor specific feature... Perhaps things are different these days and I should reevaluate my view on vendor kernels - but that's why I haven't been trusting them. -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Linus Torvalds wrote: I've long since decided that there's no point to making "-pre". What's the difference between a "-pre" and a daily -bk snapshot? Really? The fact that not a script, but Linus Torvalds, decides that the tree is in a state he likes to share with others. You have been doing -pre's all this time, it's just that you are calling them -rc's. So when I do a release, it _is_ an -rc. The fact that people have trouble understanding this is not _my_ fault. You have no intent whatsoever to release your -rc1's as the next -final, so what is this private definition of "release candidate" we are not understanding? Note, I am not complaining about 2.6. I think it's an absolute wonderful kernel, it works beautifully for me, I have no stability issues, but you indicated you wanted more testers for -rc and that's simply not going to happen when there aren't any real -rc's. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Richard Purdie wrote: Writing instructions for setting up oe to build it may be the best option. As it happens I was editing that exact page in the wiki t'other day: http://openembedded.org/cgi-bin/moin.cgi/GettingStarted I actually only wanted a toolchain but oe and scratchbox[1] seemed the rational alternatives. Scratchbox seems to offer : arm-gcc-3.3.4-glibc-2.3.2 but I've not gotten round to using it yet. Thanks for the comment on "bitbake binutils-cross-sdk" and "bitbake gcc-cross-sdk". I'll add more notes to the page once I figure it all out. David [1] http://www.scratchbox.org/download/scratchbox-1.0/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 11:12:22AM -0800, Linus Torvalds wrote: > But automation takes time to build up and learn, and in the meantime doing > it by hand and learning early is definitely the right thing to do. Maybe > you doing it by hand just makes it clear that I was wrong about the need > for some strict rules that are automatically enforced in the first place. Heh, it will have to be done by hand for a while, as I don't think any of us want to write a kernel-patch-managemement-system in our spare time. Although, I do know that osdl's PLM at one time was planned to be such a tool, I'll go kick the developers over there to see what they say... > > And if you disagree, what _should_ we call it? "-sucker" isn't good, as > > it only describes the people creating the tree, not any of the users :) > > Let's try with the 2.6.x.y numbering scheme, it's simple, and maybe it > ends up being sufficient. I just wanted to bring up the point that I don't > think the sucker tree _has_ to be seen as a 2.6.x.y tree at all. Fair enough, I'll stick with 2.6.x.y, as I think it's a good representation of what people expect. If people start objecting, I'm always open for change. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 10:59:54AM -0800, Randy.Dunlap wrote: > > Can/will/should it also include *required* (showstopper) build fixes, > if there are any of those? I think so, the ppc fix is such a thing. But not for things marked CONFIG_BROKEN :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Jeff Garzik wrote: Linus Torvalds wrote: I've long since decided that there's no point to making "-pre". What's the difference between a "-pre" and a daily -bk snapshot? Really? Several non-BK developers use the first -rc1 as a merge point. Others simply trust that _Linus_ has a lot more smarts than an automated script, about deciding when a good testing point should occur. Holy Penguin Pee has value, they feel. So when I do a release, it _is_ an -rc. The fact that people have trouble understanding this is not _my_ fault. If you want people to start testing, a good first step would be understanding why this is so. Users have been trained that -rc means "serious bugfixes only". You are trying to re-train them. That just won't work. When you do an -rc1 or -rc2, it is not serious bugfixes only. _Especially_ rc1. rc1 is in no way "bugfixes only." Non-BK developers just treat the first couple -rc's as a merge point, while the rest of us BK developers have already gone into "send bugfixes only" mode. You are fighting an uphill battle against user perceptions and training. Jeff Here's an idea which might just be too simple, but here it is anyway: Modifiy the bk snapshot scripts to name the 2.6.x series snapshots as -PREy instead of -BKy. That way, the general population of users will see the -bk snapshots as -pre releases. According to Linus, pre == bk. So, name them as such. Linus, wait for at least two weeks before releasing the first -rc. That way, the bulk on the thundering herd of patches will be hopefully be merged by then. And users will have 2.6.x-PRE[1..14] to test. The hard part for the kernel.org script writer might be to disable the -bk/-pre snapshot once the first -rc is out. Since your _intent_ is that an -rc really be an -rc, make it so. It shouldn't take more than a release or two to train the maintainers that the post-2.6.11 -rc's are _really_ release candidates. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Greg KH wrote: On Fri, Mar 04, 2005 at 10:27:37AM -0800, Linus Torvalds wrote: Btw, I also think that this means that the sucker-tree should never aim to be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the sucker tree would be _included_ in that release (and it may indeed be all of it - most of the time it probably would be), but we should not assume that "2.6.x.y" _has_ to be just the sucker tree. Ah crap, I just called the first release of such a tree, 2.6.11.1. Darn, I thought that we were converging to that also unless we can get back to -pre and -rc naming. We might want to release a "2.6.x.y" that contains a patch that is too big or too intrusive (or otherwise controversial) to really be valid in the sucker-tree. Are you sure we would ever do that? We never have before... I think we should call it the 2.6.x.y tree, as that way users can easily understand it. They see it and say, "Ah look, it's 2.6.x with only real bugfixes in it." It's very simple to explain to others. And if you disagree, what _should_ we call it? "-sucker" isn't good, as it only describes the people creating the tree, not any of the users :) -fixup or -fixes maybe. x.y is OK too. :) Can/will/should it also include *required* (showstopper) build fixes, if there are any of those? -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Linus Torvalds wrote: > > > On Fri, 4 Mar 2005, Andrew Morton wrote: > > > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, Mar 04 2005, Andrew Morton wrote: > > > > The average user has learnt "rc1 == pre1". I don't expect that it > > > > matters much at all. > > > > > > The average user and lkml reader, perhaps. But I don't understand > > > why Linus refuses to use proper -preX/-rcX naming > > > > Me either. And because people just will insist on arbitrarily dinking with > > Cc: lines, he's not listening to us any more. > > I've long since decided that there's no point to making "-pre". What's the > difference between a "-pre" and a daily -bk snapshot? Really? > > So when I do a release, it _is_ an -rc. The fact that people have trouble > understanding this is not _my_ fault. What is this whole thread all about then? It might still be worth a try, especially since so many people are convinced this is the way to go (your fault or not is not the point). Nicolas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Greg KH wrote: > > Ah crap, I just called the first release of such a tree, 2.6.11.1. I don't think any of us really _know_ where we are going, and we're all just discussing our personal ideas of what should work. As such, I think experimentation comes into it. Dammit, I want everybody to know that I'm perfectly happy to change my mind and admit when I'm wrong. I may not like it any more than the average person, but if the 2.6.x.y approach ends up working fine, why not? Iow, let's be open to some experimentation, and see what actually works. > Are you sure we would ever do that? We never have before... Well, I think we've only ever done a single 2.6.x.y release before, and I think it's good that you try to make more of them. I'm not at all unhappy with your 2.6.11.1 - I just think that there might be more automation involved in the long run. But automation takes time to build up and learn, and in the meantime doing it by hand and learning early is definitely the right thing to do. Maybe you doing it by hand just makes it clear that I was wrong about the need for some strict rules that are automatically enforced in the first place. > And if you disagree, what _should_ we call it? "-sucker" isn't good, as > it only describes the people creating the tree, not any of the users :) Let's try with the 2.6.x.y numbering scheme, it's simple, and maybe it ends up being sufficient. I just wanted to bring up the point that I don't think the sucker tree _has_ to be seen as a 2.6.x.y tree at all. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 2005-03-04 at 09:57 -0800, Linus Torvalds wrote: > I've long since decided that there's no point to making "-pre". What's the > difference between a "-pre" and a daily -bk snapshot? Really? -preX are milestones mainly for developers When -preX is converted to -rc1 then it defines feature freeze and the testing / polishing steps to the final release take place, with "serious bugfixes only" policy. I know you think the -rc polishing is boring, so why don't you give it to somebody else ? In fact the 2.6.x.y tree is a substitution for this. So the official 2.6.X release will be considered a real release candidate within no time. If this is your intention, then please state it loud and clearly and use generally known and understandable naming conventions for it. > So when I do a release, it _is_ an -rc. The fact that people have trouble > understanding this is not _my_ fault. If you are referring to rc == "ridiculous count", I agree that it is not your fault. Its not necessary to understand that. If you refer to rc == "release candidate", please start to act in a way which people _can_ actually understand without reading LKML and finding the proclamation mail, in which you declare that ridiculous count should now be considered as a release candidate. There is no way to change common practice by proclamation. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Linus Torvalds <[EMAIL PROTECTED]> wrote: > > What I'd like to set up is the reverse. The same way the "wild" kernels > tend to layer on top of my standard kernel, I'd like to have a lower > level, the "anti-wild" kernel. Something that is comprised of patches > that _everybody_ can agree on, and that doesn't get anything else. AT ALL. > > And that means that such a kernel would not get all patches that you'd > want. That's fine. Let's see if I understand your intent: this new tree would be a better base for things like -ac than the mainline Linus kernel. It would always be a single short branch off the latest mainline stable kernel. It would probably form a good base for vendor kernels and other stability-needed kernels, but by itself wouldn't necessarily be at that level of predictability. Does that accurately sum up what you're trying to get across? Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Or to put it more simply: The people we want testing these kernels have been trained to expect certain things from a Release Candidate. These people don't have time to read LKML and understand Linus's deviation from the norm. Therefore, if you want them to test, follow their expectations. As I said... it's a human not technical issue. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 09:57:38AM -0800, Linus Torvalds wrote:
> I've long since decided that there's no point to making "-pre". What's
> the difference between a "-pre" and a daily -bk snapshot? Really?
>
> So when I do a release, it _is_ an -rc. The fact that people have
> trouble understanding this is not _my_ fault.
My feeling is that there is too many numbers in the kernel version.
I think 3 numbers are good enough to get people to try out (knowingly or
not). So,
2.6.{11,12,13,...} -- for testing (a.k.a. -rc, -pre)
2.7 -- stable release
2.7.{1,2,3,...} -- for testing
2.8 -- another stable release
...
2.125 -- when last IDE bug is fixed.
3.0 -- stable release
3.0.{1,2,3,...} -- for testing
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Gwe, 2005-03-04 at 18:18, Linus Torvalds wrote: > Alan, I think your problem is that you really think that the tree _I_ want > is what _you_ want. No I think you just misunderstood the point I was trying to make. They are different trees and the difference is what stops you just doing the layering Andrew seemed to think would work. > I look at this from a _layering_ standpoint. Not from a "stable tree" > standpoint at all. >From a layering perspective the .x.y.z kernel is a dead end fork each 2.x.y and that means it can and should make use of the ugly short term fixes that solve problems. > And that means that such a kernel would not get all patches that you'd > want. That's fine. That was never the aim of it. The _only_ point of this > kernel would be to have a baseline that nobody can disagree with. Thats fine. It's a useful check, although it means we now have another layer of obfuscation. > In other words, it's not a "let's fix all serious bugs we can fix", but a > "this is the least common denominator that is basically acceptable to > everybody, regardless of what their objectives are". Acceptable to whom ? Users want all the security issues fixed. > So if you want to fix a security issue, and the fix is too big or invasive > or ugly for the "least common denominator" thing, then it simply does not > _go_ into that kernel. At that point, it goes into an -ac kernel, or into > my kernel, or into a vendor kernel. See? If you put the corresponding "ugghh" fix into the 2.6.x.y sure. Thats what I'm trying to say. > So think of it as a piece in the puzzle, not the whole picture. I think a lot of the folks who are using the 2.6 kernels and not using vendor kernels have enough puzzles already 8) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 10:27:37AM -0800, Linus Torvalds wrote: > Btw, I also think that this means that the sucker-tree should never aim to > be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the > sucker tree would be _included_ in that release (and it may indeed be all > of it - most of the time it probably would be), but we should not assume > that "2.6.x.y" _has_ to be just the sucker tree. Ah crap, I just called the first release of such a tree, 2.6.11.1. > We might want to release a "2.6.x.y" that contains a patch that is too big > or too intrusive (or otherwise controversial) to really be valid in the > sucker-tree. Are you sure we would ever do that? We never have before... I think we should call it the 2.6.x.y tree, as that way users can easily understand it. They see it and say, "Ah look, it's 2.6.x with only real bugfixes in it." It's very simple to explain to others. And if you disagree, what _should_ we call it? "-sucker" isn't good, as it only describes the people creating the tree, not any of the users :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Russell King wrote: > On Fri, Mar 04, 2005 at 05:33:33PM -, Richard Purdie wrote: > >>I'm in two minds though as generating >>your own from openembedded isn't difficult. Writing instructions for setting >>up oe to build it may be the best option. > > > Two things - are you sure that openembedded contains the patches to > fix the two biggest binutils issues we have, as documented on > http://www.arm.linux.org.uk/developer/toolchain/ ? > > Secondly, are you seriously suggesting people like Jan Dittmer, who > provide a cross-architecture service should jump through some loops > just to get a working toolchain for the ARM architecture? As long it is documented and it _works_ that's no problem. But it was quite a hassle to get working cross-compilers for all 23 archs to build, because for some there is no real documentation which target is the correct one and upstream gcc and/or binutils sometimes don't compile. For example where can I find information about the arm26 arch? I suppose it can be build with a normal arm toolchain (and the breakage looks like a real compiler failure), but is this documented somewhere? It would be nice to have such documentation in kernel under Documentation/$arch/HOW-TO-BUILD for every arch. How much work is it to set-up an openembedded environment anyways? Jan -- http://l4x.org/k/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Linus Torvalds wrote: I've long since decided that there's no point to making "-pre". What's the difference between a "-pre" and a daily -bk snapshot? Really? Several non-BK developers use the first -rc1 as a merge point. Others simply trust that _Linus_ has a lot more smarts than an automated script, about deciding when a good testing point should occur. Holy Penguin Pee has value, they feel. So when I do a release, it _is_ an -rc. The fact that people have trouble understanding this is not _my_ fault. If you want people to start testing, a good first step would be understanding why this is so. Users have been trained that -rc means "serious bugfixes only". You are trying to re-train them. That just won't work. When you do an -rc1 or -rc2, it is not serious bugfixes only. _Especially_ rc1. rc1 is in no way "bugfixes only." Non-BK developers just treat the first couple -rc's as a merge point, while the rest of us BK developers have already gone into "send bugfixes only" mode. You are fighting an uphill battle against user perceptions and training. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Linus Torvalds wrote: > > In other words: I'm talking about scalability of development, not about > fixing every single serious bug. I think this one will catch the > embarrassing brown-paper-bag kinds of things, and maybe 90% of the "duh, > we had this race forever, but we never even realized", but it wouldn't > solve the ones where we had "damn, we did the locking wrong". Btw, I also think that this means that the sucker-tree should never aim to be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the sucker tree would be _included_ in that release (and it may indeed be all of it - most of the time it probably would be), but we should not assume that "2.6.x.y" _has_ to be just the sucker tree. We might want to release a "2.6.x.y" that contains a patch that is too big or too intrusive (or otherwise controversial) to really be valid in the sucker-tree. And I'd want that to be very much explicit in the "charter" for the sucker-tree. Exactly because the whole point (to me, at least) is to make it _easy_ to maintain. There should never be any discussion at all about patches: either they are universally loved, or they are not. And if the sucker-tree is seen as a 2.6.x.y release tree, then that will _inevitably_ mean that people will start discussing whether one patch or the other is supposed to go in. My personal gut feeling is that 90% of the patches I _ever_ see are "obvious". If we also cut them down to "must fix an oops/hang/roothole", I think we'll actually get quite far with a sucker tree. We'll never get all the way, but exactly because the tree wouldn't _try_ to get all the way, it would be a lot easier to maintain. And let's face it, just getting 50% of the way and having somethign that catches the brown-paper-bag stuff so that nobody else every needs to worry about them is really worthwhile. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Thu, 3 Mar 2005, Neil Brown wrote: > On Wednesday March 2, [EMAIL PROTECTED] wrote: > > A Linus based odd number > > might be closer to that if we hope on people unwittingly running them. >^^^ > > I think this is a very unhelpful attitude. Don't expect people to do > things unwittingly. It won't work. I think you may be reading too much into that, by unwittingly i meant that people tend to run Linus' releases more than others because they are considered to be more stable. Thanks, Zwane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Alan Cox wrote: > > On Gwe, 2005-03-04 at 11:28, Andrew Morton wrote: > > I think you're assuming that 2.6.x.y will have larger scope than is > > intended. > > The examples I gave for remap_vm_area and exec are both from real world > "gosh look I am root isn't that fun" type security holes. If that is > outside the scope of 2.6.x.y then you need to go back to the drawing > board. Alan, I think your problem is that you really think that the tree _I_ want is what _you_ want. I look at this from a _layering_ standpoint. Not from a "stable tree" standpoint at all. We're always had the "wild" kernels, and 90% of the time the point of the "wild" kernels has been to let people test out the experimental stuff, that's not always ready for merging. Like it or not, I've considered even the -ac kernel historically very much a "wild" thing, not a "bugfixes" thing. What I'd like to set up is the reverse. The same way the "wild" kernels tend to layer on top of my standard kernel, I'd like to have a lower level, the "anti-wild" kernel. Something that is comprised of patches that _everybody_ can agree on, and that doesn't get anything else. AT ALL. And that means that such a kernel would not get all patches that you'd want. That's fine. That was never the aim of it. The _only_ point of this kernel would be to have a baseline that nobody can disagree with. In other words, it's not a "let's fix all serious bugs we can fix", but a "this is the least common denominator that is basically acceptable to everybody, regardless of what their objectives are". So if you want to fix a security issue, and the fix is too big or invasive or ugly for the "least common denominator" thing, then it simply does not _go_ into that kernel. At that point, it goes into an -ac kernel, or into my kernel, or into a vendor kernel. See? The point is not to make a perfect kernel. Two reasons: - aiming for perfect doesn't work, and would just stress out the maintainer of the sucker-tree. In contrast, aiming for "is this _totally_ non-offensive to everybody" is something that can be done by consensus fairly easily - it's enough that one person says "no", and the issue is solved. No stress, no gray areas. - perfect doesn't _exist_. As you yourself point out, different people have different goals. The development kernel is not supposed to just revert a patch unless the patch itself was fundamentally flawed. And the development kernel is generally much more geared towards "let's fix this right" rather than "let's apply an ugly bandaid that makes it harder to fix it properly later". So as long as you see this sucker-tree as a _replacement_ for the -ac kernels, you will _never_ be happy. But my whole point is that it's not a replacement at all. It's a starting point for others. It's something that should be fairly easy to set up, and exactly _because_ the aim is to be inoffensive, it's somethign where people can basically rely on the fact that they don't have to think about things that go into the sucker-tree: we'll set it up so that it's an acceptable base-line for everybody. Is it an acceptable _solution_ for everybody? No. It's not even aiming to be. It's aiming to be a "let's get at 45% of the way, with 5% of the effort". And the way we make the effort low is by having the hard rules, and having the "single vote throws it out" approach. That's also what limits the tree, but hey, that's ok. So how do you get to your solution? You could have a "slightly more wild" tree that takes the "other" patches. That "slightly more wild" tree would be for somebody _else_ to maintain (ie it might be you), and that would be the fixes that aren't acceptable to everybody. In other words: I'm talking about scalability of development, not about fixing every single serious bug. I think this one will catch the embarrassing brown-paper-bag kinds of things, and maybe 90% of the "duh, we had this race forever, but we never even realized", but it wouldn't solve the ones where we had "damn, we did the locking wrong". But let's face it - _most_ security bugs are of the "duh" variety. That's easy to overlook, because those are the ones you don't worry about, but the fact is, if we can get a tree that makes it possible for most people to just get those fixes without thinking about it, then that's a _good_ thing. So think of it as a piece in the puzzle, not the whole picture. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 05:33:33PM -, Richard Purdie wrote: > I'm in two minds though as generating > your own from openembedded isn't difficult. Writing instructions for setting > up oe to build it may be the best option. Two things - are you sure that openembedded contains the patches to fix the two biggest binutils issues we have, as documented on http://www.arm.linux.org.uk/developer/toolchain/ ? Secondly, are you seriously suggesting people like Jan Dittmer, who provide a cross-architecture service should jump through some loops just to get a working toolchain for the ARM architecture? Jan, how do you feel about this? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, 4 Mar 2005, Andrew Morton wrote: > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > On Fri, Mar 04 2005, Andrew Morton wrote: > > > The average user has learnt "rc1 == pre1". I don't expect that it > > > matters much at all. > > > > The average user and lkml reader, perhaps. But I don't understand > > why Linus refuses to use proper -preX/-rcX naming > > Me either. And because people just will insist on arbitrarily dinking with > Cc: lines, he's not listening to us any more. I've long since decided that there's no point to making "-pre". What's the difference between a "-pre" and a daily -bk snapshot? Really? So when I do a release, it _is_ an -rc. The fact that people have trouble understanding this is not _my_ fault. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Russell King: On Fri, Mar 04, 2005 at 12:40:30PM -, Richard Purdie wrote: I've found the arm cross compiler generated from openembedded (http://openembedded.org) to be very reliable. The big advantage in using oe would be that it is in active use so it is always highly likely to generate a working compiler. Someone just needs to make it generate a toolchain/compiler for external use[1], make it available somewhere and advertise the fact its available. Generation of the toolchain could probably be almost entirely automated. I'll only believe it when I see it. The problem is this "someone"... Who's going to forfill that space and produce some results? Something tells me that we'll be very lucky to get a volunteer, let alone see any results. As an experiment I ran "bitbake meta-sdk" on my copy of openemedded. A while later I have these in the deploy directory amongst other things. http://www.rpsys.net/openzaurus/arm-cross/binutils-cross-sdk-2.15.91.0.2-r5.tar.gz (3.8MB) http://www.rpsys.net/openzaurus/arm-cross/gcc-cross-sdk-3.4.2-r0.tar.gz (17.5MB) "bitbake binutls-cross-sdk" and "bitbake gcc-cross-sdk" are more efficient as they won't build all the other things in the sdk. Generating a cross compiler from oe really is as simple as that. Setting up oe in the first place is a bit more tricky but too bad. An improvement to the current situation might be some instructions and links to oe to tell people they can build a toolchain this way. Better still someone could run the above commands now and again and upload the files somewhere. I don't have anywhere I can host files that size on a permanent basis. I possibly could be persuaded to run the commands now and again if people were going to use the results. I'm in two minds though as generating your own from openembedded isn't difficult. Writing instructions for setting up oe to build it may be the best option. Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 11:36:26AM +, Russell King wrote: >... > Anyway, going back to why -mm doesn't work: > > arch/arm/kernel/built-in.o(.init.text+0xb64): In function `$a': > : undefined reference to `rd_size' > make[1]: *** [.tmp_vmlinux1] Error 1 > > So "rd_size" got deleted in -mm kernels without reference to anyone else > who's using it. Graaa Sorry, this was my fault (I made it static and oversaw the ARM usage when grep'ing for it). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
> I'd love for the -mm tree to get more testing, but it doesn't. So the question is how to hook up more "customers" for testing thing? mm...maybe OSDL should provide special live mini-distro weekly, which will run entirely from 256 MB USB flashdrive :) Lot of automated testing, lot of nice and colorful progressbars, graphs (it is ubelieveable how people love to watch how defragmentation goes) etc. and you are there :) If the only question is to boot my computer from CD/flash (without touching my harddrive) and pushing at the end "I'm agree to send automatically collected results to OSDL" then you can count me as a tester :) thanks, Indrek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
I decided to write the following proposal after getting a headache trying to explain the Linux versioning scheme to a friend of mine. Only then did I find that the powers that be are talking about the same thing. It's far from a complete âengineering standardâ but it makes sense to me. Disclaimers: INAKD (I am not a kernel developer) and IANASA (I am not a systems analyst) ... is incremented when user-space ABI is broken. is incremented when there has been a big change/rewrite to one of the primary subsystems this would include times when for example the default scheduler was changed or the memory management algorithms were modifed. is incremented when a smaller change has been made to one of the primary subsystems, module has been added or depreciated. Modules should only be depreciated not be removed from the tree entirely during a release removal should be reserved for releases. Although it may be tempting to roll fixes that haven't yet been released in releases this should be avoided. is used and incremented as needed when fixing security vulnerabilities and bugs that cause systems to oops, panic and other nasty behavior. Features and speedups should never added in a bugfix release. Andrew's -mm tree would still exist though I think it would make sense if it were renamed to something like -dev or -exp (exp being short for experimental) to better convey the purpose of the tree to newbie kernel hackers and PHBs alike. The policy for this tree would be much more flexible as a development environment is required to be. With a designated development tree and more frequent release the odd/even minors could be done away with. Kernel developers, power users and other such folk should be encouraged to run the latest -dev/-exp releases where possible to test out current development directions. Although I have no experience with BK it seems to me that the it should be possible to implement a work flow as described above in any SCM. --adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04 2005, Jesper Juhl wrote: > I run vanilla kernels on all my boxes, workstations and > servers, since I don't really trust vendor kernels. That's a strange statement, I don't think you are aware of the level of testing that goes into a vendor kernel, at least for the 'enterprise' products. There's just no comparison to the vanilla kernels. Of course fixes get merged back into the vanilla kernels, but these just don't have the lengthy test and maturity period of vendor kernels (by a long stretch). In fact the 2.6 cycle is specially geared towards vendor stabilization. At some point this will slow down of course, but I don't expect that to happen in the near future. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
On Fri, Mar 04, 2005 at 12:40:30PM -, Richard Purdie wrote: > I've found the arm cross compiler generated from openembedded > (http://openembedded.org) to be very reliable. The big advantage in using oe > would be that it is in active use so it is always highly likely to generate > a working compiler. Someone just needs to make it generate a > toolchain/compiler for external use[1], make it available somewhere and > advertise the fact its available. Generation of the toolchain could probably > be almost entirely automated. > > Fixes for any problems with compiler would be more than welcome for > incorporation into oe short term and for submission upstream for "proper" > fixing. I'll only believe it when I see it. The problem is this "someone"... Who's going to forfill that space and produce some results? Something tells me that we'll be very lucky to get a volunteer, let alone see any results. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Alan Cox <[EMAIL PROTECTED]> wrote: > > On Gwe, 2005-03-04 at 11:28, Andrew Morton wrote: > > I think you're assuming that 2.6.x.y will have larger scope than is > > intended. > > The examples I gave for remap_vm_area and exec are both from real world > "gosh look I am root isn't that fun" type security holes. If that is > outside the scope of 2.6.x.y then you need to go back to the drawing > board. Well *obviously* things like that are in scope. It's hardly likely that "maintainers will forget the backport" in that case, is it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
El Fri, 4 Mar 2005 11:06:33 +, Russell King <[EMAIL PROTECTED]> escribió: > Overall, my experience with the kernel bugzilla has been rather > unproductive. Most bugs which came in my direction weren't for things > I could resolve. It's possible that there're other bug tracking systems that can fit? The main disadvantage of the (few) bug tracking systems I've seen is that at the end they end up being a "additional task" for the developers (ie: more work) instead of being something that really helps to developers and free them of doing some extra work, so people avoids them when they can. There're some mail-based bug tracking systems like the one from debian but they don't include a alternative web interface for final users (well, I think bugzilla has a "email mode" or something like that but I don't really know) Bug reporters running away is something that will happen always no matter what system is used, but is it important? If someone submits a bug and he don't answer when he's asked for more details, there's no way you can fix it and the bug should be closed given a reasonable time frame. There's no reason why this can't happen today when bug are reported to the lkml, except that people who reports bugs to the lkml is people who really wants to get their bugs fixed. If the bug is important enought, it'll get reported again by someone else who cares about getting it fixed. (There're other problems with traditional bug tracking systems, like "ownership" of a bug. Some bugs are reported, discussed, and then they get fixed silently outside of the scope of the bug tracking system, but the bug remains open for _years_ - IMHO all open bugs which have not been discussed and closed in such amount of time should be closed unless there're real reasons to keep them open, new versions could have fixed it and if it remains it could be re-submitted - and it can't get closed because the developer who owns it is not looking at it. Some bug tracking systems (like the one from joel spolsky, aka "joelonsoftware.com") just don't allow to have "ownership" of bugs, because if you want that the system helps to solve problems instead of being an additional task, _everyone_ should be allowed to solve problems - which is specially true in the open source world) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Linus Torvalds wrote: [...] Ie I'd organize it like some of the "checkin committees" work for other projects that have nowhere _near_ as much work going on as Linux has. That seems to work well for small projects - and we can try to keep this "small" exactly by having the strict rules in place that would mean that 99% of all patches wouldn't even be a consideration. Maybe setting up a mailing list where all the patches have to be posted before inclusion in this tree, would help the maintainer(s) a lot. Since we expect little traffic (at least compared to LKML) a lot of developers (even "small" developers like myself) can review all the patches for correctness, and throw quite a few eyes on them. The more eyes, the less a chance for bugs to slip by. Just a thought, -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
