Just to counteract all the 2.5.60 bug reports...
After the akpm wave of compile fixes, I booted 2.5.60-BK on my Wal-Mart
PC [via epia], and ran LTP on it, while also stressing it using
fsx-linux in another window. The LTP run showed a few minor failures,
but overall 2.5.60-BK is surviving just fine, and with no corruption.
So, it's working great for me :)
On Wed, 2003-02-12 at 09:52, Jeff Garzik wrote:
> Just to counteract all the 2.5.60 bug reports...
>
> After the akpm wave of compile fixes, I booted 2.5.60-BK on my Wal-Mart
> PC [via epia], and ran LTP on it, while also stressing it using
> fsx-linux in another window. The LTP run showed a few minor failures,
> but overall 2.5.60-BK is surviving just fine, and with no corruption.
Can you send me your list of failures and version of LTP? I'd like to
make sure they match up with the known list of problems.
Thanks,
Paul Larson
Paul Larson wrote:
> On Wed, 2003-02-12 at 09:52, Jeff Garzik wrote:
>
>>Just to counteract all the 2.5.60 bug reports...
>>
>>After the akpm wave of compile fixes, I booted 2.5.60-BK on my Wal-Mart
>>PC [via epia], and ran LTP on it, while also stressing it using
>>fsx-linux in another window. The LTP run showed a few minor failures,
>>but overall 2.5.60-BK is surviving just fine, and with no corruption.
>
> Can you send me your list of failures and version of LTP? I'd like to
> make sure they match up with the known list of problems.
Version is CVS-latest, checked out last night.
Some of the failures were obvious: kernel module syscalls were failing,
as I would expect them to if they had not been updated for 2.5.x module
support. There were also a couple signal-related things, IIRC.
Unexpected failures included some file locking test failures.
Anyway, don't worry... you will be getting more concrete info soon :) I
am tracking down right now why the 2.5.x floppy driver ends all I/O
requests with an error. After that, I'll have output from a full LTP
run for you :)
On Wed, Feb 12, 2003 at 10:52:29AM -0500, Jeff Garzik wrote:
> Just to counteract all the 2.5.60 bug reports...
/me tries to blank vision of Jeff in cheerleader outfit.
8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Jeff Garzik wrote
> So, it's working great for me :)
I always wonder what should be said by testers when beta software actually
*works*. ;)
I've been successfully running 2.5.60 on my Tycho system since a few minutes
after Linus announced it. The major bugs I'd had in 2.5.59 were with Alsa,
which seems to be running well in 2.5.60.
Tycho
Debian 'sid' GNU/Linux, Kernel 2.5.60 SMP (custom)
2.8GHz Pentium 4 w/HT, Intel D850EMV2, 533MHz FSB
512 MB PC800 RDRAM, 80GB Maxtor D740X 7200 RPM ATA-100 HD
WinFast A170, GeForce 4 MX 440 GPU, 64MB DDR
I wonder if testers should post configs that worked, so developers can
compare against configs that failed?
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Professional programming for science and engineering;
Interesting and unusual bits of very free code.
> > Just to counteract all the 2.5.60 bug reports...
>
> /me tries to blank vision of Jeff in cheerleader outfit.
>
> 8-)
That reminds me, I used this as a placeholder on my website for a
while, why don't we use it as an oops graphic!?
root@darkstar:~# cat cheerleader
|\/| |\/|
/****\ /|||||\ /****\
\****/// ^.^ \\\****/
|/\\//| V |\\//\|
\\|\_____/|//
/|\\| |//|\
|||\\| |//|||
||||\ /||||
| |
/ \
/ \
WWWWWWWWW
| | | |
| | | |
| | | |
| | | |
/ / \ \
/_/ \_\
John.
This brings up an interesting point. It seems like it's very common to
have a release that doesn't boot, or produces immediately obvious
problems. I'm curious if you do any testing (LTP or otherwise) on the
kernels you intend to release. If not, would it be possible for someone
to do this? I know we could never catch every problem, but at least the
annoying, immediately noticeable problems could be caught and fixed
quickly.
If you wanted to do this, I think that would be great. If you don't
have time, I understand but would you be ok with me or anyone else doing
at least a quick sniff test before release? It doesn't have to be
anything fancy or time consuming. I'm not looking to add delays, just a
small amount of extra testing before release so that hopefully more
people will be willing to try the releases on their systems.
Thanks,
Paul Larson
On Wed, 2003-02-12 at 09:52, Jeff Garzik wrote:
> Just to counteract all the 2.5.60 bug reports...
>
> After the akpm wave of compile fixes, I booted 2.5.60-BK on my Wal-Mart
> PC [via epia], and ran LTP on it, while also stressing it using
> fsx-linux in another window. The LTP run showed a few minor failures,
> but overall 2.5.60-BK is surviving just fine, and with no corruption.
>
> So, it's working great for 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/
>
> > So, it's working great for me :)
>
> I always wonder what should be said by testers when beta software actually
> *works*. ;)
>
> I've been successfully running 2.5.60 on my Tycho system since a few minutes
> after Linus announced it. The major bugs I'd had in 2.5.59 were with Alsa,
> which seems to be running well in 2.5.60.
>
> I wonder if testers should post configs that worked, so developers can
> compare against configs that failed?
Feel free to open a 'bug report' on my bug database just to upload a
working .config - I.E. you can use it as a somewhat-organised, and
comment-onable .config storage repository, if that's any use.
http://grabjohn.com/kernelbugdatabase/
If there is sufficient interest, I can add some code to pick out the
common config options out of a set of config files, or whatever you
want. Just ask, and the feature will be, (eventually), added :-)
John.
On Wed, Feb 12, 2003 at 01:17:27PM -0500, Scott Robert Ladd wrote:
> I wonder if testers should post configs that worked, so developers can
> compare against configs that failed?
Please don't. .configs tend to be huge, and a flood of
'me too' type posts will increase size of linux-kernel
dramatically.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, Feb 12, 2003 at 12:43:34PM -0600, Paul Larson wrote:
> This brings up an interesting point. It seems like it's very common to
> have a release that doesn't boot, or produces immediately obvious
> problems. I'm curious if you do any testing (LTP or otherwise) on the
> kernels you intend to release.
In the words of our fearless leader:
"regression testing"? What's that? If it compiles, it is good,
if it boots up it is perfect.
:-)
> If not, would it be possible for someone
> to do this? I know we could never catch every problem, but at least the
> annoying, immediately noticeable problems could be caught and fixed
> quickly.
>
> If you wanted to do this, I think that would be great. If you don't
> have time, I understand but would you be ok with me or anyone else doing
> at least a quick sniff test before release? It doesn't have to be
> anything fancy or time consuming. I'm not looking to add delays, just a
> small amount of extra testing before release so that hopefully more
> people will be willing to try the releases on their systems.
>
> Thanks,
> Paul Larson
>
> On Wed, 2003-02-12 at 09:52, Jeff Garzik wrote:
> > Just to counteract all the 2.5.60 bug reports...
> >
> > After the akpm wave of compile fixes, I booted 2.5.60-BK on my Wal-Mart
> > PC [via epia], and ran LTP on it, while also stressing it using
> > fsx-linux in another window. The LTP run showed a few minor failures,
> > but overall 2.5.60-BK is surviving just fine, and with no corruption.
> >
> > So, it's working great for 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/
> >
>
>
--
Grief can take care of itself, but to get the full value of a joy you must
have somebody to divide it with. -- Mark Twain
On Wed, 2003-02-12 at 13:33, Edesio Costa e Silva wrote:
> On Wed, Feb 12, 2003 at 12:43:34PM -0600, Paul Larson wrote:
> > This brings up an interesting point. It seems like it's very common to
> > have a release that doesn't boot, or produces immediately obvious
> > problems. I'm curious if you do any testing (LTP or otherwise) on the
> > kernels you intend to release.
>
> In the words of our fearless leader:
>
> "regression testing"? What's that? If it compiles, it is good,
> if it boots up it is perfect.
It would be nice if that were true, but back here in reality things are
rarely if ever even stable enough for testing if they merely build and
boot.
If Linus really is building and booting every kernel prior to release,
it would be quick and simple to add a fast subset of LTP to the mix and
do a quick regression run. It's convenient, fast and could save a lot
of headaches for a lot of people later on.
-Paul Larson
On Thu, 13 February 2003 09:29:12 -0600, Paul Larson wrote:
>
> If Linus really is building and booting every kernel prior to release,
> it would be quick and simple to add a fast subset of LTP to the mix and
> do a quick regression run. It's convenient, fast and could save a lot
> of headaches for a lot of people later on.
The problem I see with this approach is that "a lot of people" scales
far better than Linus.
Saving 100 people a day of work by offloading it to Linus is quite an
optimisation, but it doesn't optimize the overall development speed.
Let the crowd build the kernel, see the breakage and fix it up, until
we get back to -preX and -rcY kernels.
J?rn
--
Victory in war is not repetitious.
-- Sun Tzu
On Thu, Feb 13, 2003 at 09:29:12AM -0600, Paul Larson wrote:
> It would be nice if that were true, but back here in reality things are
> rarely if ever even stable enough for testing if they merely build and
> boot.
>
> If Linus really is building and booting every kernel prior to release,
> it would be quick and simple to add a fast subset of LTP to the mix and
> do a quick regression run. It's convenient, fast and could save a lot
> of headaches for a lot of people later on.
Nothing stops people from LTPtesting the -bk nightlies.
Sure, they won't catch the last-minute-torvalds-breaks-the-compile
type bugs, but for the most part it should be useful enough info.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Thu, 2003-02-13 at 10:03, Dave Jones wrote:
> Nothing stops people from LTPtesting the -bk nightlies.
> Sure, they won't catch the last-minute-torvalds-breaks-the-compile
> type bugs, but for the most part it should be useful enough info.
Already been doing that for a long time now. How about a quick note out
to lkml that says "The current bk is what I'm going to release at <NN
Time> today unless someone gives me a good reason not to."?
-Paul Larson
On Thu, Feb 13, 2003 at 04:03:00PM +0000, Dave Jones wrote:
> On Thu, Feb 13, 2003 at 09:29:12AM -0600, Paul Larson wrote:
> > It would be nice if that were true, but back here in reality things are
> > rarely if ever even stable enough for testing if they merely build and
> > boot.
> >
> > If Linus really is building and booting every kernel prior to release,
> > it would be quick and simple to add a fast subset of LTP to the mix and
> > do a quick regression run. It's convenient, fast and could save a lot
> > of headaches for a lot of people later on.
>
> Nothing stops people from LTPtesting the -bk nightlies.
> Sure, they won't catch the last-minute-torvalds-breaks-the-compile
> type bugs, but for the most part it should be useful enough info.
Agreed... at least the past few releases, the just-after-the-release BK
snapshot often compiles and boots more reliably than the release <g>
Current 2.5.60-BK is looking _really_ nice, LTP-wise.
Jeff
> > Nothing stops people from LTPtesting the -bk nightlies.
> > Sure, they won't catch the last-minute-torvalds-breaks-the-compile
> > type bugs, but for the most part it should be useful enough info.
> Already been doing that for a long time now. How about a quick note out
> to lkml that says "The current bk is what I'm going to release at <NN
> Time> today unless someone gives me a good reason not to."?
Why? That would just delay releases, and make more work for Linus.
If a release is badly broken, another one is usually quick to follow
it, anyway.
John.
On Thu, 2003-02-13 at 11:11, John Bradford wrote:
> > > Nothing stops people from LTPtesting the -bk nightlies.
> > > Sure, they won't catch the last-minute-torvalds-breaks-the-compile
> > > type bugs, but for the most part it should be useful enough info.
> > Already been doing that for a long time now. How about a quick note out
> > to lkml that says "The current bk is what I'm going to release at <NN
> > Time> today unless someone gives me a good reason not to."?
>
> Why? That would just delay releases, and make more work for Linus.
What I just suggested would be a short 1 line note to lkml. I know he's
very busy, but what's that, like 10 seconds?
> If a release is badly broken, another one is usually quick to follow
> it, anyway.
There's usually a lag of 30min to an hour between the last changeset and
the the one that changes the version tag anyway. I would
hope/assume(dangerous) this is when it's beeing built and tested. One
more script to that mix that runs a subset of ltp might add an
additional 5 min. Alternatively, a note of intent to lkml might add a
few seconds to that delay.
If I counted timezones etc. right, here's a quick picture of the number
of minutes between the last changeset and the changeset that tagged it
with the version number:
2.5.60 52 min.
2.5.59 42 min.
2.5.58 31 min.
2.5.57 16 min.
*** 2.5.58 was release something like 12 hours later
Is it less work to do a few minutes of extra testing, or go through
another release in the same day?
-Paul Larson
> > > How about a quick note out to lkml that says "The current bk is
> > > what I'm going to release at <NN Time> today unless someone
> > > gives me a good reason not to."?
> > Why? That would just delay releases, and make more work for Linus.
> What I just suggested would be a short 1 line note to lkml. I know he's
> very busy, but what's that, like 10 seconds?
10 seconds, plus the time waiting around for replies, and the time
spent reading the replies.
> > If a release is badly broken, another one is usually quick to follow
> > it, anyway.
> There's usually a lag of 30min to an hour between the last changeset and
> the the one that changes the version tag anyway. I would
> hope/assume(dangerous) this is when it's beeing built and tested. One
> more script to that mix that runs a subset of ltp might add an
> additional 5 min. Alternatively, a note of intent to lkml might add a
> few seconds to that delay.
>
> If I counted timezones etc. right, here's a quick picture of the number
> of minutes between the last changeset and the changeset that tagged it
> with the version number:
> 2.5.60 52 min.
> 2.5.59 42 min.
> 2.5.58 31 min.
> 2.5.57 16 min.
> *** 2.5.58 was release something like 12 hours later
>
> Is it less work to do a few minutes of extra testing, or go through
> another release in the same day?
Probably less work for Linus to go through another release, plus it
means that people who are not testing -bk snapshots for whatever
reason are more involved in the development process.
John.
On Thu, 2003-02-13 at 12:23, John Bradford wrote:
> > > > How about a quick note out to lkml that says "The current bk is
> > > > what I'm going to release at <NN Time> today unless someone
> > > > gives me a good reason not to."?
> > > Why? That would just delay releases, and make more work for Linus.
> > What I just suggested would be a short 1 line note to lkml. I know he's
> > very busy, but what's that, like 10 seconds?
>
> 10 seconds, plus the time waiting around for replies, and the time
> spent reading the replies.
Ideally, there should be no waiting around for replies. The message is
sent, he starts whatever build/boot test cycle, checks for replies when
he's done and ready to release. If nothing looks urgent enough to hold
it up, then he pushes the release. I still don't see how this adds any
kind of terrible delay.
-Paul Larson
On Thu, Feb 13, 2003 at 03:16:29PM -0600, Paul Larson wrote:
> Ideally, there should be no waiting around for replies. The message is
> sent, he starts whatever build/boot test cycle, checks for replies when
> he's done and ready to release. If nothing looks urgent enough to hold
> it up, then he pushes the release. I still don't see how this adds any
> kind of terrible delay.
Outside suggestions to "improve" Linus's workflow usually fall upon deaf
ears...
IMO to accomplish your goals, set up a test box with BitKeeper,
constantly pulling and testing the latest 2.5.x BK trees. If they
crash, send full info to lkml.
Enough crash messages, and people will know automatically whether or not
the kernel is good... and Linus didn't have to be bothered at all.
Jeff
> > Ideally, there should be no waiting around for replies. The message is
> > sent, he starts whatever build/boot test cycle, checks for replies when
> > he's done and ready to release. If nothing looks urgent enough to hold
> > it up, then he pushes the release. I still don't see how this adds any
> > kind of terrible delay.
>
> Outside suggestions to "improve" Linus's workflow usually fall upon deaf
> ears...
The only suggestions really worth making, in my opinion, are whether
it's easier to work with more frequent, smaller releases, or less
frequent larger releases.
Infact, it's more or less directly analogous to packet size in a file
transfer protocol - fewer larger packets are more efficient, unless
there is a problem, when you have to re-transmit a whole, large,
packet.
Likewise with kernel releases - fewer, larger releases work fine and
mean less effort for developers, unless something breaks, in which
case there is a lot to go through to locate the problem, and people
who can't boot the broken kernel have to wait longer to test other
things that were newly merged in that release.
John.
On Thu, 2003-02-13 at 15:54, John Bradford wrote:
> Likewise with kernel releases - fewer, larger releases work fine and
> mean less effort for developers, unless something breaks, in which
> case there is a lot to go through to locate the problem, and people
> who can't boot the broken kernel have to wait longer to test other
> things that were newly merged in that release.
This was exactly what I was getting at. I suspect that there are a good
number of people that try to boot a 2.5 kernel for testing, run into
immediate problems, and shelve the idea of 2.5 testing for a couple of
months because of an immediate appearance that 2.5 is too unstable to
test. I've seen frequent griping that not enough testing happens, the
idea is to get it to a point where more people can test it _without_
adding a huge delay or making a huge gap between releases.
On Thu, 2003-02-13 at 15:38, Jeff Garzik wrote:
> Outside suggestions to "improve" Linus's workflow usually fall upon deaf
> ears...
Since Linus hasn't chimed in yet, I'm guessing that's exactly what
happened. I'm not trying to improve his workflow, but rather the
workflow of anyone who might be interested in getting more involved in
2.5 testing.
-Paul Larson
> > Likewise with kernel releases - fewer, larger releases work fine and
> > mean less effort for developers, unless something breaks, in which
> > case there is a lot to go through to locate the problem, and people
> > who can't boot the broken kernel have to wait longer to test other
> > things that were newly merged in that release.
> This was exactly what I was getting at. I suspect that there are a good
> number of people that try to boot a 2.5 kernel for testing, run into
> immediate problems, and shelve the idea of 2.5 testing for a couple of
> months because of an immediate appearance that 2.5 is too unstable to
> test. I've seen frequent griping that not enough testing happens, the
> idea is to get it to a point where more people can test it _without_
> adding a huge delay or making a huge gap between releases.
I can see what you mean, but realistically, I don't see how it's
practical.
You can always use 2.5.X-BK1 to get the fixes that we would probably
have been in 2.5.X if Linus had done more extensive testing on it
before releasing it.
John.
On Thu, 13 Feb 2003 15:57:56 CST, Paul Larson said:
> Since Linus hasn't chimed in yet, I'm guessing that's exactly what
> happened. I'm not trying to improve his workflow, but rather the
> workflow of anyone who might be interested in getting more involved in
> 2.5 testing.
What would help a lot of people (certainly me, at least), would be if
somebody kept a well-publicized "already known errata" list along with
(possibly unofficial) work-around patches. Something along the line of:
compile fails in drivers/widget/fooby.c with error:
undefined structure member 'blat' in line 1149.
To fix: apply <this patch>
On Thu, 13 Feb 2003 22:11:17 +0000 (GMT), John Bradford said:
> You can always use 2.5.X-BK1 to get the fixes that we would probably
> have been in 2.5.X if Linus had done more extensive testing on it
> before releasing it.
Almost but not quite what I meant - unless -BK1 is reserved for after-release
whoops and doesn't contain "new stuff for release N+1". If -BK1 is only
bugfixes, that would be good.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
On Thu, 13 Feb 2003 17:20:55 -0500
[email protected] wrote:
| On Thu, 13 Feb 2003 15:57:56 CST, Paul Larson said:
|
| > Since Linus hasn't chimed in yet, I'm guessing that's exactly what
| > happened. I'm not trying to improve his workflow, but rather the
| > workflow of anyone who might be interested in getting more involved in
| > 2.5 testing.
|
| What would help a lot of people (certainly me, at least), would be if
| somebody kept a well-publicized "already known errata" list along with
| (possibly unofficial) work-around patches. Something along the line of:
|
| compile fails in drivers/widget/fooby.c with error:
| undefined structure member 'blat' in line 1149.
| To fix: apply <this patch>
Yes, I agree, that would be helpful.
I try to keep current lkml/etc patches for fixes/cleanups to the
latest kernel, and I've thought about a way to post them, but it's
too time-consuming a task, especially when it's not one's job
to do that.
| On Thu, 13 Feb 2003 22:11:17 +0000 (GMT), John Bradford said:
|
| > You can always use 2.5.X-BK1 to get the fixes that we would probably
| > have been in 2.5.X if Linus had done more extensive testing on it
| > before releasing it.
|
| Almost but not quite what I meant - unless -BK1 is reserved for after-release
| whoops and doesn't contain "new stuff for release N+1". If -BK1 is only
| bugfixes, that would be good.
--
~Randy
On Thu, 2003-02-13 at 16:20, [email protected] wrote:
> What would help a lot of people (certainly me, at least), would be if
> somebody kept a well-publicized "already known errata" list along with
> (possibly unofficial) work-around patches. Something along the line of:
>
> compile fails in drivers/widget/fooby.c with error:
> undefined structure member 'blat' in line 1149.
> To fix: apply <this patch>
Good idea, I'd bet that might cut down on some of the duplicate bug
reports too (at least the annoying ones that occur days or even weeks
after the initial report).
I certainly wouldn't mind throwing something like this up on the LTP
website if people are interested. If anyone wants to spam me with some
initial data for 2.5.60 feel free.
-Paul Larson
> > Since Linus hasn't chimed in yet, I'm guessing that's exactly what
> > happened. I'm not trying to improve his workflow, but rather the
> > workflow of anyone who might be interested in getting more involved in
> > 2.5 testing.
>
> What would help a lot of people (certainly me, at least), would be if
> somebody kept a well-publicized "already known errata" list along with
> (possibly unofficial) work-around patches. Something along the line of:
>
> compile fails in drivers/widget/fooby.c with error:
> undefined structure member 'blat' in line 1149.
> To fix: apply <this patch>
Well, you can do that with my bug database - just open a new bug
report for each compile failiure, upload a patch to the database, and
link the patch with the new bug. You can then collect together all
the relevant bug reports in to a confirmed bug for each kernel
version. You don't even have to duplicate bug reports if they occur in
multiple kernel versions.
John.
On Thu, 2003-02-13 at 16:43, Randy.Dunlap wrote:
> Yes, I agree, that would be helpful.
>
> I try to keep current lkml/etc patches for fixes/cleanups to the
> latest kernel, and I've thought about a way to post them, but it's
> too time-consuming a task, especially when it's not one's job
> to do that.
We'll see how time-consuming it is, I'll try my best to keep up!
Could you send me what you have collected for 2.5.60? I've set up a
placeholder on the ltp website, you can either go to ltp.sf.net and
click on "Kernel Errata" or the direct URL is
http://ltp.sourceforge.net/errata but there's nothing there yet. I'll
try to put some data out there tonight.
Thanks,
Paul Larson
>> Why? That would just delay releases, and make more work for Linus.
> What I just suggested would be a short 1 line note to lkml. I know he's
> very busy, but what's that, like 10 seconds?
>
>> If a release is badly broken, another one is usually quick to follow
>> it, anyway.
> There's usually a lag of 30min to an hour between the last changeset and
> the the one that changes the version tag anyway. I would
> hope/assume(dangerous) this is when it's beeing built and tested. One
> more script to that mix that runs a subset of ltp might add an
> additional 5 min. Alternatively, a note of intent to lkml might add a
> few seconds to that delay.
>
> If I counted timezones etc. right, here's a quick picture of the number
> of minutes between the last changeset and the changeset that tagged it
> with the version number:
> 2.5.60 52 min.
> 2.5.59 42 min.
> 2.5.58 31 min.
> 2.5.57 16 min.
> *** 2.5.58 was release something like 12 hours later
>
> Is it less work to do a few minutes of extra testing, or go through
> another release in the same day?
Or you just persaude Linus to release kernels first thing in the morning,
not last thing at night. Then the automatic nightly tests would cover it
...(assuming you wake up before he does, and email him the results ... but
you're 2hrs earlier than him, so ... ;-))
M.
On Thu, 13 Feb 2003, Martin J. Bligh wrote:
>
> Or you just persaude Linus to release kernels first thing in the morning,
> not last thing at night.
Ok, now the thread has moved from the strange to the surreal.
"First thing in the morning" indeed.
Trust me, you don't want me doing _anything_ first thing in the morning.
Linus
On Thu, 13 Feb 2003, Linus Torvalds wrote:
> Trust me, you don't want me doing _anything_ first thing in the morning.
>
> Linus
Doesn't Alan Cox go to bed at first thing in the morning?
Mike
John Bradford wrote:
> If a release is badly broken, another one is usually quick to follow
> it, anyway.
It is my impression that this is frequently not the case.
I'd love Linus to release x.y.z before he goes to bed, go through
the bug reports that have trickled in while he's in a foul mood in
the morning, and then make a x.y.z+1 release with the most glaring
bugs fixed.
Of course, there are probably good reasons why Linus doesn't do
this already.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
For anyone interested, I have a few items put up at:
http://ltp.sourceforge.net/errata
It's nothing fancy yet, but I'll work on it some more tomorrow. Please
let me know if you have any suggestions.
Thanks,
Paul Larson
> > Or you just persaude Linus to release kernels first thing in the morning,
> > not last thing at night.
>
> Ok, now the thread has moved from the strange to the surreal.
Fed up with all these people trying to tell you when to release new
kernels? Now you can just use this simple script to do it
automatically!
#!/bin/sh
echo "Release a new kernel now!!!" > /tmp/kernel_reminder
echo "30 6 * * * /usr/bin/cat /tmp/kernel_reminder | mail root" >> /var/spool/cron/crontabs/root
John.
Sorry about getting back on the thread late was off doing boring
management stuff.
But this is what PLM/STP does but right now it doesn't bother
to send the results to any list.
http://www.osdl.org/projects/26lnxstblztn/results/
Tim
On Thu, 2003-02-13 at 13:38, Jeff Garzik wrote:
> On Thu, Feb 13, 2003 at 03:16:29PM -0600, Paul Larson wrote:
> > Ideally, there should be no waiting around for replies. The message is
> > sent, he starts whatever build/boot test cycle, checks for replies when
> > he's done and ready to release. If nothing looks urgent enough to hold
> > it up, then he pushes the release. I still don't see how this adds any
> > kind of terrible delay.
>
> Outside suggestions to "improve" Linus's workflow usually fall upon deaf
> ears...
>
> IMO to accomplish your goals, set up a test box with BitKeeper,
> constantly pulling and testing the latest 2.5.x BK trees. If they
> crash, send full info to lkml.
>
> Enough crash messages, and people will know automatically whether or not
> the kernel is good... and Linus didn't have to be bothered at all.
>
> 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/
--
Timothy D. Witham - Lab Director - [email protected]
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office) (503)-702-2871 (cell)
(503)-626-2436 (fax)
On Thu, Feb 20, 2003 at 02:29:49PM -0800, Timothy D. Witham wrote:
> Sorry about getting back on the thread late was off doing boring
> management stuff.
>
> But this is what PLM/STP does but right now it doesn't bother
> to send the results to any list.
>
> http://www.osdl.org/projects/26lnxstblztn/results/
Neat, thanks for posting the link.
IMO, it would be nice to send results to linux-kernel,
but with a few restrictions:
* just a small email, with only key bits of info.
URLs would point to more detailed information.
* a constant URL, which describes what the heck the email is all about
(such as your above URL)
* for now, only bother with "ia32 Default"
* never email more than once a day... even if the bot gets stuck in a
spamming loop, you need to have something in place to throttle emails.
* only email when state changes: i.e. PASS->FAIL or FAIL->PASS,
never PASS->PASS or FAIL->FAIL. [debateable... some may disagree with
me on this one]
Comments?
Jeff
P.S. The column headers in your report are broken, for example "ia32
Default" goes to bad link
http://www.osdl.org/projects/plm/def_ia32_default.html
On Thu, 2003-02-20 at 14:42, Jeff Garzik wrote:
> On Thu, Feb 20, 2003 at 02:29:49PM -0800, Timothy D. Witham wrote:
> > Sorry about getting back on the thread late was off doing boring
> > management stuff.
> >
> > But this is what PLM/STP does but right now it doesn't bother
> > to send the results to any list.
> >
> > http://www.osdl.org/projects/26lnxstblztn/results/
>
> Neat, thanks for posting the link.
>
> IMO, it would be nice to send results to linux-kernel,
> but with a few restrictions:
>
> * just a small email, with only key bits of info.
> URLs would point to more detailed information.
> * a constant URL, which describes what the heck the email is all about
> (such as your above URL)
> * for now, only bother with "ia32 Default"
> * never email more than once a day... even if the bot gets stuck in a
> spamming loop, you need to have something in place to throttle emails.
> * only email when state changes: i.e. PASS->FAIL or FAIL->PASS,
> never PASS->PASS or FAIL->FAIL. [debateable... some may disagree with
> me on this one]
>
I'm not a big fan of only on transition as sometimes things
get broken but nothing ever gets reported. But your suggestions
will be taken and implemented.
> Comments?
>
> Jeff
>
>
> P.S. The column headers in your report are broken, for example "ia32
> Default" goes to bad link
> http://www.osdl.org/projects/plm/def_ia32_default.html
--
Timothy D. Witham - Lab Director - [email protected]
Open Source Development Lab Inc - A non-profit corporation
15275 SW Koll Parkway - Suite H - Beaverton OR, 97006
(503)-626-2455 x11 (office) (503)-702-2871 (cell)
(503)-626-2436 (fax)