Re: RFD: Kernel release numbering

Randy.Dunlap
2005-03-03T05:41:52Z

Dave Jones wrote:
> On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
> > Dave Jones <davej@redhat.com> wrote:
> > >
> > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
> > >
> > > > I would not keep regular driver updates from a 2.6.<even> thing.
> > >
> > > Then the notion of it being stable is bogus, given how many regressions
> > > the last few kernels have brought in drivers. Moving from 2.6.9 -> 2.6.10
> > > broke ALSA, USB, parport, firewire, and countless other little bits and
> > > pieces that users tend to notice.
> >
> > 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 too am a little put off by the number of regressions which certain
> > (admittedly tricky) subsystems keep on introducing. One does wonder how
> > careful people are being at the development stage. And that's a thing
> > which we can surely fix.
> > For example, here's today's crop (so far):
> >
> > include/linux/soundcard.h:195: warning: `_PATCHKEY' redefined
> > include/linux/awe_voice.h:33: warning: this is the location of the previous definition
>
> compile time regressions we should be able to nail down fairly easily.
> (someone from OSDL is already doing compile stats and such on each release
> [too bad they're mostly incomprehensible to the casual viewer])
> The bigger problem is runtime testing. If things aren't getting the
> exposure they need, we're going to get screwed over by something or other
> every time Linus bk pull's some random driver repo.

I'll ding the OSDL release builder about that (I agree with you)....

--
~Randy