re: Linux 2.4.17

re: Linux 2.4.17

[Marcelo Tosatti]

On Fri, 21 Dec 2001, Dan Kegel wrote:

> Marcelo wrote:
> 
> > Well, 
> > 
> > Here it is... 
> > 
> > 
> > final:
> > 
> > - Fix more loopback deadlocks                   (Andrea Arcangeli)
> > - Make Alpha with Nautilus chipset and
> >   Irongate chipset configuration compile
> >   correctly                                     (Michal Jaegermann)
> > 
> > rc2: 
> > 
> > - Fix potential oops with via-rhine             (Andrew Morton)
> > - sysvfs: mark inodes as bad in case of read 
> > ...
> 
> Um, what happened to the idea of 'no changes between the last
> release candidate and final'?

I haven't said that, did I? 

I said I would make -rc kernels which would not add any new _feature_.

re: Linux 2.4.17

[Dan Kegel]

Marcelo wrote:

> Well, 
> 
> Here it is... 
> 
> 
> final:
> 
> - Fix more loopback deadlocks                   (Andrea Arcangeli)
> - Make Alpha with Nautilus chipset and
>   Irongate chipset configuration compile
>   correctly                                     (Michal Jaegermann)
> 
> rc2: 
> 
> - Fix potential oops with via-rhine             (Andrew Morton)
> - sysvfs: mark inodes as bad in case of read 
> ...

Um, what happened to the idea of 'no changes between the last
release candidate and final'?

I'm disappointed; I thought we were entering a new era of
release discipline in the stable kernel. 

- Dan

re: Linux 2.4.17

[David Gomez]

> > final:
> >
> > - Fix more loopback deadlocks                   (Andrea Arcangeli)
> > - Make Alpha with Nautilus chipset and
> >   Irongate chipset configuration compile
> >   correctly                                     (Michal Jaegermann)
> >
> > rc2:
> >
> > - Fix potential oops with via-rhine             (Andrew Morton)
> > - sysvfs: mark inodes as bad in case of read
> > ...
>
> Um, what happened to the idea of 'no changes between the last
> release candidate and final'?

I think the policy is 'not to add unnecessary changes' , not 'no changes'.

> I'm disappointed; I thought we were entering a new era of
> release discipline in the stable kernel.

I'd be dissapointed if Marcelo had released and stable kernel still
with the loopback deadlocks. And i don't think the alpha compile fix is
going to break anything.



David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Linux 2.4.17

[Dan Kegel]

Marcelo Tosatti wrote:
> 
Marcelo wrote:
> > Um, what happened to the idea of 'no changes between the last
> > release candidate and final'?
> 
> I haven't said that, did I?
> 
> I said I would make -rc kernels which would not add any new _feature_.

Sorry; I must have misunderstood.  But I think lwn.net 
misunderstood, too; http://lwn.net/2001/1213/kernel.php3
says "Marcelo's stated plan is to have the final release be the same 
as the last release candidate; the hope is to be done with surprises 
caused by last-minute patches."

I guess I and lwn.net were projecting our desires onto Marcello's statements?

- Dan

Re: Linux 2.4.17

[Rik van Riel]

On Fri, 21 Dec 2001, Dan Kegel wrote:
> Marcelo Tosatti wrote:
> Marcelo wrote:
       ^

> I guess I and lwn.net were projecting our desires onto Marcello's statements?
                                                              ^^
I wouldn't be surprised. If you don't even read his
name, I bet you wouldn't have seen the subtleties
in his announcement either ;)

*runs like hell*

cheers,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

re: Linux 2.4.17

[Oliver Xymoron]

On Fri, 21 Dec 2001, Marcelo Tosatti wrote:

> > > Here it is...
> > >
> > >
> > > final:
> > >
> > > - Fix more loopback deadlocks                   (Andrea Arcangeli)
> > > - Make Alpha with Nautilus chipset and
> > >   Irongate chipset configuration compile
> > >   correctly                                     (Michal Jaegermann)
> >
> > Um, what happened to the idea of 'no changes between the last
> > release candidate and final'?
>
> I haven't said that, did I?

No, but it's a good idea. There's always the risk of breaking something
and you don't want to introduce a disk-eating bug between -rc and -final.
It's better to ship one more -rc and wait a day before -final. If you
don't, people will just get in the habit of waiting a day after -final to
be safe.

> I said I would make -rc kernels which would not add any new _feature_.

That's less important.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

re: Linux 2.4.17

[David Relson]

At 06:10 PM 12/21/01, Oliver Oxymoron wrote:
>On Fri, 21 Dec 2001, Marcelo Tosatti wrote:
>
>... There's always the risk of breaking something
>and you don't want to introduce a disk-eating bug between -rc and -final.
>It's better to ship one more -rc and wait a day before -final. If you
>don't, people will just get in the habit of waiting a day after -final to
>be safe.
>
> > I said I would make -rc kernels which would not add any new _feature_.
>
>That's less important.

I agree with releasing an extra -rc and waiting the extra day for -final.

My thought is that the _only_ difference between the last -rc and -final is 
correctly setting "EXTRAVERSION=" in Makefile.

David

Re: Linux 2.4.17

[Mike Castle]

On Fri, Dec 21, 2001 at 07:34:29PM -0500, David Relson wrote:
> My thought is that the _only_ difference between the last -rc and -final is 
> correctly setting "EXTRAVERSION=" in Makefile.

Perhaps Documentation/* changes.

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Linux 2.4.17

[John Alvord]

On Fri, 21 Dec 2001 22:09:09 +0100 (CET), "David Gomez"
<davidge@viadomus.com> wrote:

>
>> > final:
>> >
>> > - Fix more loopback deadlocks                   (Andrea Arcangeli)
>> > - Make Alpha with Nautilus chipset and
>> >   Irongate chipset configuration compile
>> >   correctly                                     (Michal Jaegermann)
>> >
>> > rc2:
>> >
>> > - Fix potential oops with via-rhine             (Andrew Morton)
>> > - sysvfs: mark inodes as bad in case of read
>> > ...
>>
>> Um, what happened to the idea of 'no changes between the last
>> release candidate and final'?
>
>I think the policy is 'not to add unnecessary changes' , not 'no changes'.
>
>> I'm disappointed; I thought we were entering a new era of
>> release discipline in the stable kernel.
>
>I'd be dissapointed if Marcelo had released and stable kernel still
>with the loopback deadlocks. And i don't think the alpha compile fix is
>going to break anything.

One possibility would be to release 2.4.17 and 2.4.18-pre1
simultaneously, with the otherwise last minute changes. There have
been so many brown-bag bugs introduced by the last changes, there
everyone is or should be nervous. Immediately launching the next -pre
series will help keep the momentum moving while preserving the more
certain knowledge of the quality of the last -rc level.

john alvord

re: Linux 2.4.17

[Craig I. Hagan]

> 
> I agree with releasing an extra -rc and waiting the extra day for -final.
> 
> My thought is that the _only_ difference between the last -rc and -final is 
> correctly setting "EXTRAVERSION=" in Makefile.

I've lots of thoughts as well as things i would have liked to have seen in
2.4.17. However, This is Marcelo's show. It is his call to make, and I support
what he did. It has got to be a tough job to know that *you* are the one who
says "This is good (enough)."

-- craig



-------------------------------------------------------------------------------
Craig I. Hagan     "It's a small world, but I wouldn't want to back it up"
hagan(at)cih.com        "True hackers don't die, their ttl expires"
  	"It takes a village to raise an idiot, but an idiot can raze a village"

	Stop the spread of spam, use a sendmail condom!
	     http://www.cih.com/~hagan/smtpd-hacks

                       In Bandwidth we trust

Re: re: Linux 2.4.17

[Bernd Eckenfels]

In article <Pine.LNX.4.33.0112212203460.1184-100000@fargo> you wrote:
> I'd be dissapointed if Marcelo had released and stable kernel still
> with the loopback deadlocks. And i don't think the alpha compile fix is
> going to break anything.

Well, of course having another RC wont be too much of a problem.

greetings
Bernd

Re: Linux 2.4.17

[Daniel Phillips]

On December 21, 2001 08:44 pm, Marcelo Tosatti wrote:
> On Fri, 21 Dec 2001, Dan Kegel wrote:
> 
> > Marcelo wrote:
> > 
> > > Well, 
> > > 
> > > Here it is... 
> > > 
> > > 
> > > final:
> > > 
> > > - Fix more loopback deadlocks                   (Andrea Arcangeli)
> > > - Make Alpha with Nautilus chipset and
> > >   Irongate chipset configuration compile
> > >   correctly                                     (Michal Jaegermann)
> > > 
> > > rc2: 
> > > 
> > > - Fix potential oops with via-rhine             (Andrew Morton)
> > > - sysvfs: mark inodes as bad in case of read 
> > > ...
> > 
> > Um, what happened to the idea of 'no changes between the last
> > release candidate and final'?
> 
> I haven't said that, did I? 
> 
> I said I would make -rc kernels which would not add any new _feature_.

I'll weigh in on this one, basically a "me too".  The only changelog entry I 
find unsettling is "Fix more loopback deadlocks" and all I have to say about 
it is: remember what happened when Al fixed the iput bug.  I'm not suggesting 
that there was no basic idiot testing - I'm practically certain you did some 
yourself, but it would have been oh-so-nice to have an rc3 that lived for at 
least a short time on the kernel list before going to final.

By the way, great job managing this first major point release (2.4.16 doesn't 
really count ;-).

--
Daniel

Re: Linux 2.4.17

[David A. Frantz]

Hello Everyone;

At this point I'm not a kernel developer, most likely never will be, but I do
use linux exclusively.    So from that perspective here are my comments for
consideration.

At some point in the development of a new kernel there must be an emphasis on
quality and reliability.   I personally do not see how it is even possible to
release a "final" kernel revision with only one or two days testing.
Granted everyone expects a new kernel series to have a few issues upon
release, but once the ** in a 2.4.** kernel move past 10 it really is time to
think quality.

Realizing that excessive time spent on quality issues would lead to many
delays, I'd like to suggest that the third dot number use an odd even
numbering system to seperate the heavly tested kernels from the heavily
modified kernels.    In other words all pre-kernels leading up to a 2.4.18
kernel would be aimed at stabilizing the code and quality.    When this is
done the pre-kernels for the 2.4.19 series would aim to oimplement the more
major changes that everyone wants or needs.

I'd to be able to pick up a kernel from www.kernel.org and have some
confidence that it will work correctly without extensive patching.    The idea
that vendors can supply us with a heavily tested kernel is, to me anyways,
against the spirit of the whole community.    After all there are many fly by
night Linux distributions, a stable kernel available from www.kernel.org would
go a long way to maintaining these sort of systems.

Now this may seem a bit demanding but consider this.    If the users of this
list did not have prior knowledge of the kernels available on www.kernel.org
how would they know which ones to avoid totally, which ones are OK, and which
ones seem to be well done?    Its really a shame that we need to talk about a
stable kernel this way, on the other hand due to reading this list I
understand how the various revisions came about.   The problem, as I see it,
is that there were to many kernels released before everything stabilized.
If your implementing or testing new technology them by all means release a
pre-kernel, a patch against a stable kernel, or a technology specific
pre-kernel (such as the -aa releases) but lets not go on with throwing out
grossly buggy release kernels.   Even if it takes months, release a kernel
that for most people will work.

I hope these comments are helpful.    Like I say Linux is the only thing that
I use at home, I really want it to succeed.   So for the 2.4.** kernel lets
concentrate on quality, it would be nice to know that from now on each new
kernel release is beter than the one before it.

Thanks
dave


John Alvord wrote:

> On Fri, 21 Dec 2001 22:09:09 +0100 (CET), "David Gomez"
> <davidge@viadomus.com> wrote:
>
> >
> >> > final:
> >> >
> >> > - Fix more loopback deadlocks                   (Andrea Arcangeli)
> >> > - Make Alpha with Nautilus chipset and
> >> >   Irongate chipset configuration compile
> >> >   correctly                                     (Michal Jaegermann)
> >> >
> >> > rc2:
> >> >
> >> > - Fix potential oops with via-rhine             (Andrew Morton)
> >> > - sysvfs: mark inodes as bad in case of read
> >> > ...
> >>
> >> Um, what happened to the idea of 'no changes between the last
> >> release candidate and final'?
> >
> >I think the policy is 'not to add unnecessary changes' , not 'no changes'.
> >
> >> I'm disappointed; I thought we were entering a new era of
> >> release discipline in the stable kernel.
> >
> >I'd be dissapointed if Marcelo had released and stable kernel still
> >with the loopback deadlocks. And i don't think the alpha compile fix is
> >going to break anything.
>
> One possibility would be to release 2.4.17 and 2.4.18-pre1
> simultaneously, with the otherwise last minute changes. There have
> been so many brown-bag bugs introduced by the last changes, there
> everyone is or should be nervous. Immediately launching the next -pre
> series will help keep the momentum moving while preserving the more
> certain knowledge of the quality of the last -rc level.
>
> john alvord
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.17

[Alan Cox]

> Now this may seem a bit demanding but consider this.    If the users of this
> list did not have prior knowledge of the kernels available on www.kernel.org
> how would they know which ones to avoid totally, which ones are OK, and which
> ones seem to be well done?    Its really a shame that we need to talk about a

They would go to a vendor who is prepared to say "We tested this, we put
our logo on the package saying we have faith in it"



Alan