Re: RFD: Kernel release numbering

[Randy.Dunlap]

Dave Jones wrote:
> On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
>  > Dave Jones <davej@xxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/