Re: RFD: Kernel release numbering

Gene Heskett
2005-03-03T02:20:52Z

On Wednesday 02 March 2005 19:58, David S. Miller wrote:
>On Wed, 02 Mar 2005 19:29:35 -0500
>
>Jeff Garzik <jgarzik@pobox.com> wrote:
>
>The problem is people don't test until 2.6.whatever-final goes out.
>Nothing will change that.

Except more people who think like me. I usually enjoy playing the
canary, else I wouldn't do it.

More Canaries I say. I build, and run till the next rc comes out
almost every rc & I'm curently up on 2.6.11 for 5h:30m. I've only
got this one box thats fast enough to do that and still get anything
else done too, so this is the workhorse. I don't yelp about
deprecation notices during the build, I figure you people have eyes
too.

Basicly on my limited variety of hardware, I at least can play the
part of the canary here, and have a couple of times when problems
show up in less than a couple of days or during the build itself.

What you really need is a stronger plea for more people to go beat on
the rc releases, but I fear thats never going to happen as long as
there is nothing but the rc stuffs, and no -pre stuff for testing the
-mm stuff a little wider. Back in 2.4 days, even the -pre stuff was
often stable enough for extended uptimes, and I mean that I ran

May 1 2003 vmlinuz-2.4.21-pre7 on that 7.3 box until Jan 21 2005.

Its now got a 2.4.29 final on it and:
8:56pm up 23 days, 8:00, 6 users, load average: 2.12, 1.40, 1.14
sailing along just as smoothly as ever since Feb 7.

Not without a reboot over that nearly 2 years of course, but the
choice of when to do the reboot was mine in every case. Here on this
box, trying to play canary, uptimes are often less than a week,
sometimes less than 24 hours, and that isn't anywhere near long
enough to be able to say 'its stable'. Stuff is IMO, being shoved
out without an adequate amount of time to see what the 'canary' does.

If we could only get more people to 'bang on it, kick the tires etc',
AND fix those sorts of problems that do show up in the next
sequential rc, a lot of stuff like 2.6.8 could be headed off.
Note the caps on the word AND. That bugfix in the next rc release
seems to be broken when obviously needed fixes often have to go back
to the head of the queue and work their way back to Linus.

So how DO you go about getting the tires kicked by more users? I'm
not sure what would work.

One doesn't have to be a code monkey to do this 'canary' scene as long
as a bash script can be hacked up to do the majority of the work, I
have a couple of them that basicly make a new kernel install a no
brainer. Often under 30 minutes to being rebooted to a new rc from
going after the patch.

And I ramble, but this is my $0.02. And probably about what its worth
in the Grande Scheme of Things...

>And the day Linus releases we always get a pile of "missing
> MODULE_EXPORT()" type bug reports that are one liner fixes. Those
> fixes will not be seen by users until the next 2.6.x rev comes out
> and right now that takes months which is rediculious for such
> simple fixes.

I agree. Ditto for the 1394 fixes that have been upstream for at
least a month, maybe more. I haven't checked to see if kino can run
my movie camera yet, if it can, then maybe it made it into 2.6.11.
Otherwise I'll have to go nuke that dir in the drivers tree, and
again grab the svn from the 1394 site and rebuild/reinstall.
Provided the svn server is up, thats not a big deal here. The point
is that it is being tested, and it does work.

>We're talking about a one week "calming" period to collect the brown
> paper bag fixes for a 2.6.${even} release, that's all.
>
>All this "I have to hold onto my backlog longer, WAHHH!" arguments
> are bogus IMHO. We're using a week of quiescence to fix the tree
> for users so they are happy whilst we work on the 2.6.${odd}
> interesting stuff :-)

--
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.