Marcelo,
Thank you for stepping forward to be the maintainer of the 2.4 tree. This
is a very valuable and important service for use Linux users.
Also, thank you for releasing 2.4.16. I have it building on my linux box
as I write this message :-)
Over the last few days, there have been lots of messages regarding "Kernel
Release" and "-preX vs. -rcX". You, as the official maintainer of kernel
2.4 are the person who actually creates the release policy and makes it happen.
Would you care to share your thoughts on this matter?
David
At 07:30 AM 11/26/01, Marcelo Tosatti wrote:
>Hi,
>
>Due to the corruption problems on 2.4.15, I'm releasing 2.4.16.
On Mon, 26 Nov 2001, David Relson wrote:
> Marcelo,
>
> Thank you for stepping forward to be the maintainer of the 2.4 tree. This
> is a very valuable and important service for use Linux users.
>
> Also, thank you for releasing 2.4.16. I have it building on my linux box
> as I write this message :-)
>
> Over the last few days, there have been lots of messages regarding "Kernel
> Release" and "-preX vs. -rcX". You, as the official maintainer of kernel
> 2.4 are the person who actually creates the release policy and makes it happen.
>
> Would you care to share your thoughts on this matter?
Sorry for not being able to discuss this issues... Its just that I'm too
busy doing the maintenance and other stuff at Conectiva at the same time
(people are flooding me with patches, btw, please stop for a while).
Daniel Quinlan suggested me to release a "pre-final" release before the
real final one (which would catch most "stupid" bugs), and I think thats a
nice way of solving the problem.
I'll _probably_ do that --- not sure yet, though.
On Mon, 26 Nov 2001, Marcelo Tosatti wrote:
> Sorry for not being able to discuss this issues... Its just that I'm too
> busy doing the maintenance and other stuff at Conectiva at the same time
> (people are flooding me with patches, btw, please stop for a while).
>
> Daniel Quinlan suggested me to release a "pre-final" release before the
> real final one (which would catch most "stupid" bugs), and I think thats a
> nice way of solving the problem.
>
> I'll _probably_ do that --- not sure yet, though.
Aren't all the -pre's pre-finals? And what if there is a big bug found in
the -final, it will obviously be followed up with a -final-final?
I like the ISC's release methods. The do -rc's (-pre's would be fine for
the kernel as it is already established), each -rc fixes problems found
with the previous. When an -rc has been out long enough with no more bug
reports they release that code, WITHOUT changes.
-Chris
--
Two penguins were walking on an iceberg. The first penguin said to the
second, "you look like you are wearing a tuxedo." The second penguin
said, "I might be..." --David Lynch, Twin Peaks
On Mon, 26 Nov 2001, Chris Meadors wrote:
> On Mon, 26 Nov 2001, Marcelo Tosatti wrote:
>
> > Sorry for not being able to discuss this issues... Its just that I'm too
> > busy doing the maintenance and other stuff at Conectiva at the same time
> > (people are flooding me with patches, btw, please stop for a while).
> >
> > Daniel Quinlan suggested me to release a "pre-final" release before the
> > real final one (which would catch most "stupid" bugs), and I think thats a
> > nice way of solving the problem.
> >
> > I'll _probably_ do that --- not sure yet, though.
>
> Aren't all the -pre's pre-finals?
No. Just the -pre-final is a -pre-final. :)
-pre-final basically means that this is the "candidate" release for the
final.
I could call it "candidate" or whatever (I don't really care about the
name).
> And what if there is a big bug found in the -final, it will obviously
> be followed up with a -final-final?
If people don't like the -pre-final name, I can call it "-candidate" as I
said previously.
> I like the ISC's release methods. The do -rc's (-pre's would be fine
> for the kernel as it is already established), each -rc fixes problems
> found with the previous. When an -rc has been out long enough with no
> more bug reports they release that code, WITHOUT changes.
Thats exactly the idea with the "pre-final" thingie.
At 12:22 PM 11/26/01, Chris Meadors wrote:
>Aren't all the -pre's pre-finals? And what if there is a big bug found in
>the -final, it will obviously be followed up with a -final-final?
>
>I like the ISC's release methods. The do -rc's (-pre's would be fine for
>the kernel as it is already established), each -rc fixes problems found
>with the previous. When an -rc has been out long enough with no more bug
>reports they release that code, WITHOUT changes.
>
>-Chris
Chris,
I think of -pre releases as beta code - testable and likely broken. An -rc
release would be "possibly broken". If problems are encountered, fix ONLY
those problems to generate the next -rc. If it's O.K., then make it "final".
David
On Mon, Nov 26, 2001 at 01:54:11PM -0200, Marcelo Tosatti wrote:
>
> > I like the ISC's release methods. The do -rc's (-pre's would be fine
> > for the kernel as it is already established), each -rc fixes problems
> > found with the previous. When an -rc has been out long enough with no
> > more bug reports they release that code, WITHOUT changes.
>
> Thats exactly the idea with the "pre-final" thingie.
Most groups use -rc release candidate releases, so using that instead of
-pre-final would lead to the least confusion.
A 2.4.17 release might look like this:
Release 2.4.17-preX until all the new stuff you want is in.
Release 2.4.17-rcX until no-one complains about the new stuff.
Release the last 2.4.17-rcX as 2.4.17 and hope no one finds anything
embarassing (which will probably happen anyway.
Seems to me though, that you can simply put a note in your Changelog which
-pre releases are bound to be to the next final revision, this will save us
from yet another numbering scheme.
-Dave
I think the problem is that there can't be any code
changes from the last -[pre[-final]|rc] release and
the actual release.
And Marcelo seems to think this way too.
So can we drop it? There will be no changes from the
last pre-release and the actual release, so this will
not be an issue :)
Dana Lacoste - Linux Developer
Peregrine Systems - Ottawa, Canada
On Mon, 26 Nov 2001, Dana Lacoste wrote:
> I think the problem is that there can't be any code
> changes from the last -[pre[-final]|rc] release and
> the actual release.
>
> And Marcelo seems to think this way too.
I think a better idea would be a feature freeze of some sort, where only
fixes to bugs discovered in -rcN series kernels can be added to -rcN+1
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
Followup to: <[email protected]>
By author: Marcelo Tosatti <[email protected]>
In newsgroup: linux.dev.kernel
>
> No. Just the -pre-final is a -pre-final. :)
>
> -pre-final basically means that this is the "candidate" release for the
> final.
>
> I could call it "candidate" or whatever (I don't really care about the
> name).
>
That's what a release candidate is. Expect the possibility that you
might have more than one release candidate.
The -rc scheme proposed seems very clean indeed.
Oh, and yes, if you settle on a naming scheme, *please* let me know
ahead of time so I can update the scripts to track it, rather than
finding out by having hundreds of complaints in my mailbox...
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Mon, Nov 26, 2001 at 10:12:50AM -0800, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Marcelo Tosatti <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > No. Just the -pre-final is a -pre-final. :)
> >
> > -pre-final basically means that this is the "candidate" release for the
> > final.
> >
> > I could call it "candidate" or whatever (I don't really care about the
> > name).
> >
>
> That's what a release candidate is. Expect the possibility that you
> might have more than one release candidate.
>
> The -rc scheme proposed seems very clean indeed.
>
> Oh, and yes, if you settle on a naming scheme, *please* let me know
> ahead of time so I can update the scripts to track it, rather than
> finding out by having hundreds of complaints in my mailbox...
I for one used the -pre and -pre-final naming for the v2.0.39-series,
and I'll probably use the same naming for the final pre-patch of
v2.0.40, _unless_ there's some sort of agreement on another naming
scheme. I'd be perfectly content with using the -rc naming for the
final instead. The important thing is not the naming itself, but
consistency between the different kernel-trees.
Regards: David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
David Weinehall wrote:
>>
>>Oh, and yes, if you settle on a naming scheme, *please* let me know
>>ahead of time so I can update the scripts to track it, rather than
>>finding out by having hundreds of complaints in my mailbox...
>>
>
> I for one used the -pre and -pre-final naming for the v2.0.39-series,
> and I'll probably use the same naming for the final pre-patch of
> v2.0.40, _unless_ there's some sort of agreement on another naming
> scheme. I'd be perfectly content with using the -rc naming for the
> final instead. The important thing is not the naming itself, but
> consistency between the different kernel-trees.
>
Consistency is a Very Good Thing[TM] (says the one who tries to teach
scripts to understand the naming.) The advantage with the -rc naming is
that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
-pre-final-really-i-mean-it-this-time phenomenon when the release
candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
shame in needing more than one release candidate.
-hpa
On Mon, 26 Nov 2001, H. Peter Anvin wrote:
> David Weinehall wrote:
>
> >>
> >>Oh, and yes, if you settle on a naming scheme, *please* let me know
> >>ahead of time so I can update the scripts to track it, rather than
> >>finding out by having hundreds of complaints in my mailbox...
> >>
> >
> > I for one used the -pre and -pre-final naming for the v2.0.39-series,
> > and I'll probably use the same naming for the final pre-patch of
> > v2.0.40, _unless_ there's some sort of agreement on another naming
> > scheme. I'd be perfectly content with using the -rc naming for the
> > final instead. The important thing is not the naming itself, but
> > consistency between the different kernel-trees.
> >
>
>
> Consistency is a Very Good Thing[TM] (says the one who tries to teach
> scripts to understand the naming.) The advantage with the -rc naming is
> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> -pre-final-really-i-mean-it-this-time phenomenon when the release
> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
> shame in needing more than one release candidate.
Agreed. I stick with the -rc naming convention for 2.4+...
On Mon, 26 Nov 2001, Chris Meadors wrote:
> I like the ISC's release methods. The do -rc's (-pre's would be fine for
> the kernel as it is already established), each -rc fixes problems found
> with the previous. When an -rc has been out long enough with no more bug
> reports they release that code, WITHOUT changes.
Hi,
I am neither a vendor nor maintainer nor a great kernel hacker but I
think you all miss at least one point (what I for sure do too):
The problem is that you kernel hackers out there fetch the pre stuff
and test it that others run test cycles on them ... . But the
lot of people out there will never fetch anything else than
a "release" ; no -pre no -rc no -ac no whatever prefix or suffix.
You will not get them just because somebody 's changing the name
to something else.
Make your test periods longer. If there are no real serious bug in the
pre let the pre live for a week or 2 or even longer. Who cares ? We are in
'stable' branch at the moment! At some (early) point of pre-releases
stop accepting any further features and if the -pre gets real close to being
fine announce that it'll be the last one, make a note to the changelog,
wait another week for seriuos bufixes and then release the tarballs
(or if any have one more pre).
There are for sure some points that there should be better no
more different naming conventions: hpa will surely have to hack up more
scripts, things might get inconsistent between different stable/dev.
versions, we already have the -<some letter> releases for other kernel
hacker's releases like -aa -ac, ... and so on...
But if you really decide on another suffix my vote would be -rc 'cause
it's the most common one (perhaps linus then will use it in the future
too ?)
And always keep in mind: another new 'release' is nothing else than
another 'release candidate' to the next version with hopefully less
bugs more stability (and sometimes more features ;)
just my 5 cents
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Marcelo Tosatti wrote:
> Agreed. I stick with the -rc naming convention for 2.4+...
Thanks a lot - much better that way.
Fran?ois
Marcelo Tosatti wrote:
>>
>>Consistency is a Very Good Thing[TM] (says the one who tries to teach
>>scripts to understand the naming.) The advantage with the -rc naming is
>>that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>>-pre-final-really-i-mean-it-this-time phenomenon when the release
>>candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
>>shame in needing more than one release candidate.
>>
>
> Agreed. I stick with the -rc naming convention for 2.4+...
>
I have updated the kernel.org scripts to recognize the -rc naming
convention. Any -rc patch found is assumed to be newer than any -pre
patch found.
I will try to add tracking of the v2.0 and v2.2 trees sometime later this
week.
-hpa
At 3:25 PM -0200 11/26/01, Marcelo Tosatti wrote:
> > Consistency is a Very Good Thing[TM] (says the one who tries to teach
>> scripts to understand the naming.) The advantage with the -rc naming is
>> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>> -pre-final-really-i-mean-it-this-time phenomenon when the release
>> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
>> shame in needing more than one release candidate.
>
>Agreed. I stick with the -rc naming convention for 2.4+...
A quibble: "release" seems an odd word to choose for a Linux kernel.
Since we're calling the target kernel "final", how about -fc1,
-fc2...?
--
/Jonathan Lundell.
On Monday 26 November 2001 20:06, Jonathan Lundell wrote:
> >Agreed. I stick with the -rc naming convention for 2.4+...
> A quibble: "release" seems an odd word to choose for a Linux kernel.
> Since we're calling the target kernel "final", how about -fc1,
> -fc2...?
Sounds a bit too much like the f-word.
"rc" is the universally recognized name for such things (heck, even
Microsoft) so I'd stick with it.
--
Ciao,
Flavio Stanchina
Trento - Italy
"The best defense against logic is ignorance."
http://spazioweb.inwind.it/fstanchina/
On Mon, Nov 26, 2001 at 03:25:24PM -0200, Marcelo Tosatti wrote:
>
>
> On Mon, 26 Nov 2001, H. Peter Anvin wrote:
>
> > David Weinehall wrote:
> >
> > >>
> > >>Oh, and yes, if you settle on a naming scheme, *please* let me know
> > >>ahead of time so I can update the scripts to track it, rather than
> > >>finding out by having hundreds of complaints in my mailbox...
> > >>
> > >
> > > I for one used the -pre and -pre-final naming for the v2.0.39-series,
> > > and I'll probably use the same naming for the final pre-patch of
> > > v2.0.40, _unless_ there's some sort of agreement on another naming
> > > scheme. I'd be perfectly content with using the -rc naming for the
> > > final instead. The important thing is not the naming itself, but
> > > consistency between the different kernel-trees.
> > >
> >
> >
> > Consistency is a Very Good Thing[TM] (says the one who tries to teach
> > scripts to understand the naming.) The advantage with the -rc naming is
> > that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> > -pre-final-really-i-mean-it-this-time phenomenon when the release
> > candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
> > shame in needing more than one release candidate.
>
> Agreed. I stick with the -rc naming convention for 2.4+...
Ok, then I'll do likewise.
Linus, Alan?
Regards: David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
At 8:28 PM +0100 11/26/01, Flavio Stanchina wrote:
>On Monday 26 November 2001 20:06, Jonathan Lundell wrote:
>
>> >Agreed. I stick with the -rc naming convention for 2.4+...
>> A quibble: "release" seems an odd word to choose for a Linux kernel.
>> Since we're calling the target kernel "final", how about -fc1,
>> -fc2...?
>
>Sounds a bit too much like the f-word.
>
>"rc" is the universally recognized name for such things (heck, even
>Microsoft) so I'd stick with it.
So in a choice between sex, love and Microsoft, we choose Microsoft?
I'm more used to -fc, myself; in fact I was unfamiliar with -rc. But
if Microsoft uses -rc, by all means, let's follow suit. ;-)
--
/Jonathan Lundell.
>>>>> "MT" == Marcelo Tosatti <[email protected]> writes:
MT> On Mon, 26 Nov 2001, H. Peter Anvin wrote:
>> Consistency is a Very Good Thing[TM] (says the one who tries to teach
>> scripts to understand the naming.) The advantage with the -rc naming is
>> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>> -pre-final-really-i-mean-it-this-time phenomenon when the release
>> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
>> shame in needing more than one release candidate.
MT> Agreed. I stick with the -rc naming convention for 2.4+...
(This is a request to maintainers of three stable trees).
While we are on the topic, could you also coordinate to keep the
EXTRAVERSION strings consistent? 2.4.X-preN uses "-preN" but
2.2.X-preN uses "preN" without leading "-".
On Mon, Nov 26, 2001 at 12:39:34PM -0800, [email protected] wrote:
> >>>>> "MT" == Marcelo Tosatti <[email protected]> writes:
>
> MT> On Mon, 26 Nov 2001, H. Peter Anvin wrote:
> >> Consistency is a Very Good Thing[TM] (says the one who tries to teach
> >> scripts to understand the naming.) The advantage with the -rc naming is
> >> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> >> -pre-final-really-i-mean-it-this-time phenomenon when the release
> >> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
> >> shame in needing more than one release candidate.
>
> MT> Agreed. I stick with the -rc naming convention for 2.4+...
>
> (This is a request to maintainers of three stable trees).
>
> While we are on the topic, could you also coordinate to keep the
> EXTRAVERSION strings consistent? 2.4.X-preN uses "-preN" but
> 2.2.X-preN uses "preN" without leading "-".
I'm using "-preN" with a leading "-", and will probably continue
doing so.
Regards: David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
David Weinehall wrote:
>>
>>While we are on the topic, could you also coordinate to keep the
>>EXTRAVERSION strings consistent? 2.4.X-preN uses "-preN" but
>>2.2.X-preN uses "preN" without leading "-".
>>
>
> I'm using "-preN" with a leading "-", and will probably continue
> doing so.
>
This matches the filename convention, and seems to be what most users expect.
-hpa
On Mon, 26 Nov 2001, David Relson wrote:
> At 12:22 PM 11/26/01, Chris Meadors wrote:
>
> >Aren't all the -pre's pre-finals? And what if there is a big bug found in
> >the -final, it will obviously be followed up with a -final-final?
All the -pre's are before the final, but not release candidates. I think
the rc until recently has been the one where someone said "we've put a
hell of a lot of new stuff in this..." and concentrated on reported bugs,
if any.
> >I like the ISC's release methods. The do -rc's (-pre's would be fine for
> >the kernel as it is already established), each -rc fixes problems found
> >with the previous. When an -rc has been out long enough with no more bug
> >reports they release that code, WITHOUT changes.
> I think of -pre releases as beta code - testable and likely broken. An -rc
> release would be "possibly broken". If problems are encountered, fix ONLY
> those problems to generate the next -rc. If it's O.K., then make it "final".
Other than some quibbling about nomenclature, that's how I see it. We
always had an alpha version for in-house testing only, then a beta for
selected users, which for Linux would be those who have the guts to run
the downloads, and then a release.
I did commenrcial software development for a few decades and that was
usually the practice, and that's what people like Microsoft were doing
when I did a few beta tests for them. I think it's a good model for Linux
stable kernel series.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On 20011126 Bjoern A. Zeeb wrote:
>
>The problem is that you kernel hackers out there fetch the pre stuff
>and test it that others run test cycles on them ... . But the
>lot of people out there will never fetch anything else than
>a "release" ; no -pre no -rc no -ac no whatever prefix or suffix.
>You will not get them just because somebody 's changing the name
>to something else.
>
The problem is the fear of people about -ac or -pre series. What should
be done is to teach people that what they think is kernel 2.4.8 from
RedHat or Mandrake is really 2.4.8-ac7 or the like. They are shipping
-ac versions (beacuse of preferences and driver update, usually are
-ac series and not -pre series). So your 'distro rock solid kernel'
is an -ac kernel (and I do not say that an -ac kernel is not rock
solid, I have run -ac's until 13-ac7).
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.16-pre1 #1 SMP Sun Nov 25 02:06:34 CET 2001 i686
Marcelo Tosatti wrote:
>
> (people are flooding me with patches, btw, please stop for a while).
>
That's funny. The rest of us haven't seen these patches.
Marcelo, if someone sends you a patch which has not been thoroughly
reviewed on the appropriate mailing list, I would urge you to
peremptorily shitcan it. There is no reason why you alone should
be responsible for reviewing kernel changes.
-
From: Andrew Morton <[email protected]>
Date: Mon, 26 Nov 2001 17:04:02 -0800
Marcelo, if someone sends you a patch which has not been thoroughly
reviewed on the appropriate mailing list, I would urge you to
peremptorily shitcan it. There is no reason why you alone should
be responsible for reviewing kernel changes.
Are you suggesting that, for example, I should send every Sparc change
to this list?
I bet a lot of what he is seeing are driver and arch updates.
Such updates really only need to go through his "stupid filter"
when it is coming from the maintainer, but it does add up and
take up time.
Followup to: <[email protected]>
By author: "David S. Miller" <[email protected]>
In newsgroup: linux.dev.kernel
>
> From: Andrew Morton <[email protected]>
> Date: Mon, 26 Nov 2001 17:04:02 -0800
>
> Marcelo, if someone sends you a patch which has not been thoroughly
> reviewed on the appropriate mailing list, I would urge you to
> peremptorily shitcan it. There is no reason why you alone should
> be responsible for reviewing kernel changes.
>
> Are you suggesting that, for example, I should send every Sparc change
> to this list?
>
appropriate != this.
> I bet a lot of what he is seeing are driver and arch updates.
>
> Such updates really only need to go through his "stupid filter"
> when it is coming from the maintainer, but it does add up and
> take up time.
Obviously. If it's for a maintained subsystem:
a) if it's from the subsystem maintainer, sanity-check it.
b) if it's not, dump it or reject with the appropriate notice.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Mon, Nov 26, 2001 at 10:31:41AM -0800, H. Peter Anvin wrote:
> Consistency is a Very Good Thing[TM] (says the one who tries to teach
> scripts to understand the naming.) The advantage with the -rc naming is
> that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
> -pre-final-really-i-mean-it-this-time phenomenon when the release
> candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
> shame in needing more than one release candidate.
Why not just disguard this sillyness of alphabetic characters in version
numbers... Just carry through the same structure used by major/minor:
I.e.
2.0.39 < released 2.0.39
2.0.39.1.1 < first development snapshot of the kernel which will eventually
be 2.0.40
2.0.39.1.2 < second
2.0.39.1.n < Nth
2.0.39.2.1 < first RC
2.0.39.2.2 < second RC
2.0.39.3.1 < opps! Development went too long and we had to break feature
freeze to add important features.
2.0.39.4.1 < Trying to stablize again
2.0.39.4.2 < a few more bugs fixxed
2.0.40 < Looks like 2.0.39.4.2 got it right!
On Mon, Nov 26, 2001 at 05:32:18PM -0800, H. Peter Anvin wrote:
> >
> > Such updates really only need to go through his "stupid filter"
> > when it is coming from the maintainer, but it does add up and
> > take up time.
>
> Obviously. If it's for a maintained subsystem:
>
> a) if it's from the subsystem maintainer, sanity-check it.
> b) if it's not, dump it or reject with the appropriate notice.
A minor issue...
How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
the subsystem aintainer himself? I mean anybody would have sent any crap, but
not too bad enough to suspect. But if it came with a CC to a list, there is a
much smaller chance of this happenning.
Yes. This would be very rare and the effects would be very short lived. But
still the _possibility_ exists.
Cheers,
Anuradha
--
Debian GNU/Linux (kernel 2.4.13)
When you make your mark in the world, watch out for guys with erasers.
-- The Wall Street Journal
Anuradha Ratnaweera wrote:
>
> A minor issue...
>
> How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
> the subsystem aintainer himself? I mean anybody would have sent any crap, but
> not too bad enough to suspect. But if it came with a CC to a list, there is a
> much smaller chance of this happenning.
>
> Yes. This would be very rare and the effects would be very short lived. But
> still the _possibility_ exists.
>
How about sending a quick reply "got your patch, applied it?" The
maintainer can then say "WHAT PATCH?"
-hpa
On Mon, Nov 26, 2001 at 09:52:57AM -0800, Dana Lacoste wrote:
>
> So can we drop it? There will be no changes from the
> last pre-release and the actual release, so this will
> not be an issue :)
If I understand correctly, -preX releases will be for adding features and bug
fixes and -rcX releases will be for only bug fixes.
Hopefully, there won't be _any_ change from last -rc release to the -final.
Anuradha
--
Debian GNU/Linux (kernel 2.4.13)
You are dishonest, but never to the point of hurting a friend.
On Mon, Nov 26, 2001 at 11:40:30PM -0800, H. Peter Anvin wrote:
> Anuradha Ratnaweera wrote:
> >
> > How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
> > the subsystem aintainer himself? I mean anybody would have sent any crap, but
> > not too bad enough to suspect. But if it came with a CC to a list, there is a
> > much smaller chance of this happenning.
> >
> > Yes. This would be very rare and the effects would be very short lived. But
> > still the _possibility_ exists.
>
> How about sending a quick reply "got your patch, applied it?" The
> maintainer can then say "WHAT PATCH?"
Don't we need a consistent indexing system for patches?
May be the subsystem maintainers can upload patches to some place over ssh/ssl
and the maintainer can _download_ them from there. The maintainer will simply
email the patch number and not the whole thing. And patches can be
numbered/named in some consistent manner. Once the system is in place, we can
even automate md5 checksums etc.
Cheers,
Anuradha
--
Debian GNU/Linux (kernel 2.4.13)
There's one consolation about matrimony. When you look around you can
always see somebody who did worse.
-- Warren H. Goldsmith
Gregory Maxwell wrote:
>On Mon, Nov 26, 2001 at 10:31:41AM -0800, H. Peter Anvin wrote:
>
>>Consistency is a Very Good Thing[TM] (says the one who tries to teach
>>scripts to understand the naming.) The advantage with the -rc naming is
>>that it avoids the -pre5, -pre6, -pre-final, -pre-final-really,
>>-pre-final-really-i-mean-it-this-time phenomenon when the release
>>candidate wasn't quite worthy, you just go -rc1, -rc2, -rc3. There is no
>>shame in needing more than one release candidate.
>>
>
>Why not just disguard this sillyness of alphabetic characters in version
>numbers... Just carry through the same structure used by major/minor:
>I.e.
>
>2.0.39 < released 2.0.39
>2.0.39.1.1 < first development snapshot of the kernel which will eventually
> be 2.0.40
>2.0.39.1.2 < second
>2.0.39.1.n < Nth
>2.0.39.2.1 < first RC
>2.0.39.2.2 < second RC
>2.0.39.3.1 < opps! Development went too long and we had to break feature
> freeze to add important features.
>2.0.39.4.1 < Trying to stablize again
>2.0.39.4.2 < a few more bugs fixxed
>2.0.40 < Looks like 2.0.39.4.2 got it right!
>-
>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/
>
What really scares me is not so much the way the kernels are numbered as
the way features gets added to
the kernels.
Internally in Oracle we do not add new features to a release number,
just bug-fixes.
Hence 2.4.0 is the base release of the 2.4.x kernel series. the minor
x-number should just indicate a bug-fix
release. Thus, no new features should get added to the 2.4 kernel with
this numbering schema.
If you really want to add features into the 2.4.x kernel, you also need
to extend the numbering schema.
I.e 2.4.0.x wil then be the bug-fix releases and 2.4.1.x will have new
features.
This makes it easier to maintain and to understand what is happening
between the various releases.
As far as I can understand, today, new features are added to a released
kernel without any sensible numbering scheme
identifying this fact. I don't know if a 2.4.10 kernel contains the same
features as 2.4.16 with the only difference beeing bug-fixes
or if there have been added new features. By using a numbering scheme
that is consistent across both development and
production kernels, it is easier to identify the features in a kernel.
I realize that this is a lot easier to do when you are using a source
code repository than by hand administration.
I think the time has come for the kernel to find it's way into a cvs
form. It has to be done, sooner or later, why not now when the 2.5
kernel has been forked?
And I do agree with people who has asked for a bug system to identify
the various bugs and their fixes.
I have been looking forward to the 2.5 kernel because I have wanted to
get involved in the kernel devlopment, but have not
wanted to jump in on an existing production/development kernel. The most
confusing part today is all the various patches
beeing sendt around on the lkml. A lot of people who wants to develop,
do not have the time to keep on top of the
mailing list. We do have other jobs too, that pays for our food and
clothes. This is done on our spare time and having
to spend a few hours every day, reading through the kernel list and
applying various patches seems like a waste
of time. Unless a different system is devised, I think I will stay away
from the kernel development and
concentrate on other things.
I'm sorry if this seems like a flame-bait, it was not intended to be and
I did not intend to offend anyone either. My apologies to
anyone who feels so.
--
Regards
Svein Erik
I've given up reading books; I find it takes my mind off myself.
_____________________________________________________________
Svein Erik Brostigen e-mail: [email protected]
Senior Technical Analyst Phone: 407.458.7168
EBC - Extended Business Critical
Oracle Support Services
5955 T.G. Lee Blvd
Orlando FL, 32822
Enabling the Information Age Through Internet Computing
_____________________________________________________________
The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation.
On Tuesday 27 November 2001 09:02, Svein Erik Brostigen wrote:
>
> What really scares me is not so much the way the kernels are numbered as
> the way features gets added to
> the kernels.
> Internally in Oracle we do not add new features to a release number,
> just bug-fixes.
> Hence 2.4.0 is the base release of the 2.4.x kernel series. the minor
> x-number should just indicate a bug-fix
> release. Thus, no new features should get added to the 2.4 kernel with
> this numbering schema.
> If you really want to add features into the 2.4.x kernel, you also need
> to extend the numbering schema.
> I.e 2.4.0.x wil then be the bug-fix releases and 2.4.1.x will have new
> features.
> This makes it easier to maintain and to understand what is happening
> between the various releases.
>
> As far as I can understand, today, new features are added to a released
> kernel without any sensible numbering scheme
> identifying this fact. I don't know if a 2.4.10 kernel contains the same
> features as 2.4.16 with the only difference beeing bug-fixes
> or if there have been added new features. By using a numbering scheme
> that is consistent across both development and
> production kernels, it is easier to identify the features in a kernel.
>
The problem is that for kernels new features _are_ bug-fixes. Like the new
vm, work-around for discovered bugs in hardware, etc., etc.
I an way what should't be done in a -rc release is new fixing features, but
only the fixing _of_ features. ;-)
Allan Sandfeld wrote:
>On Tuesday 27 November 2001 09:02, Svein Erik Brostigen wrote:
>
>>What really scares me is not so much the way the kernels are numbered as
>>the way features gets added to
>>the kernels.
>>
>The problem is that for kernels new features _are_ bug-fixes. Like the new
>vm, work-around for discovered bugs in hardware, etc., etc.
>I an way what should't be done in a -rc release is new fixing features, but
>only the fixing _of_ features. ;-)
>
Hmmm... workarounds are not new features, but bug-fixes ;-)
The new vm is not a *new* feature, it is just a different vm than the
old. Even if you treat it as a new
feature, it should then be incorporated into a new-feature release, i.e
not in a 2.4.10.4, but maybe in what
would have been a 2.4.11.0.
I'm not going to be anal about this, but a more structured way of
handling new features/bug-fixes and release
numbering would be nice. A lot easier to know what you are programming
against and what you are
installing/testing.
--
Regards
Svein Erik
I've given up reading books; I find it takes my mind off myself.
_____________________________________________________________
Svein Erik Brostigen e-mail: [email protected]
Senior Technical Analyst Phone: 407.458.7168
EBC - Extended Business Critical
Oracle Support Services
5955 T.G. Lee Blvd
Orlando FL, 32822
Enabling the Information Age Through Internet Computing
_____________________________________________________________
The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation.
Anuradha Ratnaweera <[email protected]> writes:
> How does Marcelo (or Linus or Alan, say) know that the patch
> _really_ came from the subsystem aintainer himself?
They could reject patches that came without the maintainers GPG or PGP
signature.
--
Hilsen Harald.
--On Monday, 26 November, 2001 4:18 PM -0500 Gregory Maxwell
<[email protected]> wrote:
> Why not just disguard this sillyness of alphabetic characters in version
> numbers
Express version numbers as a real number. Only the versions with
perfectly accurate binary representations of irrational numbers
will be bug-free release candidates :-p
--
Alex Bligh
On Tue, 27 Nov 2001 11:08:04 +0100,
Harald Arnesen <[email protected]> wrote:
>Anuradha Ratnaweera <[email protected]> writes:
>
>> How does Marcelo (or Linus or Alan, say) know that the patch
>> _really_ came from the subsystem aintainer himself?
>
>They could reject patches that came without the maintainers GPG or PGP
>signature.
Unfortunately the normal GPG/PGP signing changes '-' at start of line
to '- -', even with clear text signing, and destroys the patch. You
have to use --not-dash-escaped in GPG, where the man page says:
--not-dash-escaped
This option changes the behavior of cleartext signatures so that
they can be used for patch files. You should not send such an armored
file via email because all spaces and line endings are hashed too.
You can not use this option for data which has 5 dashes at the
beginning of a line, patch files don't have this. A special armor
header line tells GnuPG about this cleartext signature option.
I don't know if PGP accepts text signed by GPG with --not-dash-escaped
nor do I know if there really is a problem with mailing such patches.
But the warning above is nasty enough to rule it out. The only other
option for signed patches is uuencode or MIME (with or without
compression) and Linus does not like that format.
On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote:
> Why not just disguard this sillyness of alphabetic characters in version
> numbers... Just carry through the same structure used by major/minor:
> I.e.
>
> 2.0.39 < released 2.0.39
> 2.0.39.1.1 < first development snapshot of the kernel which will eventually
> be 2.0.40
> 2.0.39.1.2 < second
> 2.0.39.1.n < Nth
> 2.0.39.2.1 < first RC
> 2.0.39.2.2 < second RC
> 2.0.39.3.1 < opps! Development went too long and we had to break feature
> freeze to add important features.
> 2.0.39.4.1 < Trying to stablize again
> 2.0.39.4.2 < a few more bugs fixxed
> 2.0.40 < Looks like 2.0.39.4.2 got it right!
Some people may find this more "logical", but imho most will find it
confusing... It's already difficult to inform someone about the
(number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into
-pre: added some features, bugfixes etc...
-fc : feature-freeze, only bugfixes
and having some time (f.i. 48h) between the last -fc and the "real" release
(without having a single addendum to the ChangeLog).
Just my 2 cents,
Sven Vermeulen
--
Some people have told me they don't think a fat penguin really embodies
the grace of Linux, which just tells me they have never seen a angry
penguin charging at them in excess of 100mph. They'd be a lot more
careful about what they say if they had. ~(Linus Torvalds)
On a sunny Tue, 27 Nov 2001 15:43:23 +0100 Sven Vermeulen gathered a sheaf
of electrons and etched in their motions the following immortal words:
> -fc : feature-freeze, only bugfixes
Did it occur to anyone here that fc is an acronym for 'Feature Creep' ?
:-)
On Tue, 27 Nov 2001 15:43:23 +0100, Sven Vermeulen
<[email protected]> wrote:
>On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote:
>> Why not just disguard this sillyness of alphabetic characters in version
>> numbers... Just carry through the same structure used by major/minor:
>> I.e.
>>
>> 2.0.39 < released 2.0.39
>> 2.0.39.1.1 < first development snapshot of the kernel which will eventually
>> be 2.0.40
>> 2.0.39.1.2 < second
>> 2.0.39.1.n < Nth
>> 2.0.39.2.1 < first RC
>> 2.0.39.2.2 < second RC
>> 2.0.39.3.1 < opps! Development went too long and we had to break feature
>> freeze to add important features.
>> 2.0.39.4.1 < Trying to stablize again
>> 2.0.39.4.2 < a few more bugs fixxed
>> 2.0.40 < Looks like 2.0.39.4.2 got it right!
>
>Some people may find this more "logical", but imho most will find it
>confusing... It's already difficult to inform someone about the
>(number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into
> -pre: added some features, bugfixes etc...
> -fc : feature-freeze, only bugfixes
>and having some time (f.i. 48h) between the last -fc and the "real" release
>(without having a single addendum to the ChangeLog).
The bug-fixes only would have to be tightly defined. All of
2.4.0-2.4.15 were bug-fixes in some sense...
john
I agree with your opinion, it's so difficult to understand what is
happening with the linux kernel.
And the -rc (Release Candidate) it's not welcome, remember me another OS
in development status.
Bye
Sven Vermeulen wrote:
> On Mon, Nov 26, 2001 at 04:18:02PM -0500, Gregory Maxwell wrote:
>
>
> Some people may find this more "logical", but imho most will find it
> confusing... It's already difficult to inform someone about the
> (number).(even|odd).(release)-(patch|pre-final) scheme. I'm more into
> -pre: added some features, bugfixes etc...
> -fc : feature-freeze, only bugfixes
> and having some time (f.i. 48h) between the last -fc and the "real" release
> (without having a single addendum to the ChangeLog).
>
> Just my 2 cents,
> Sven Vermeulen
>
>
--
=================================================
Borges & Rinolfi Solu??es em Redes Corporativas
Security Officer
Profissional Certificado Conectiva Linux
http://www.techs.com.br/kidmumu - UIN 4553082 - LC 83522
... e querido papai do c?u, em vez de botar as vitaminas no ?leo de
bacalhau, bota nos merengues que seu Manoel tem l? na venda. Am?m.
=================================================
On Tue, Nov 27, 2001 at 09:29:36PM +1100, Keith Owens wrote:
> On Tue, 27 Nov 2001 11:08:04 +0100,
> Harald Arnesen <[email protected]> wrote:
> >Anuradha Ratnaweera <[email protected]> writes:
> >
> >> How does Marcelo (or Linus or Alan, say) know that the patch
> >> _really_ came from the subsystem aintainer himself?
> >
> >They could reject patches that came without the maintainers GPG or PGP
> >signature.
>
> Unfortunately the normal GPG/PGP signing changes '-' at start of line
> to '- -', even with clear text signing, and destroys the patch. You
> have to use --not-dash-escaped in GPG, where the man page says:
>
> --not-dash-escaped
> This option changes the behavior of cleartext signatures so that
> they can be used for patch files. You should not send such an armored
> file via email because all spaces and line endings are hashed too.
> You can not use this option for data which has 5 dashes at the
> beginning of a line, patch files don't have this. A special armor
> header line tells GnuPG about this cleartext signature option.
>
Interesting.
> I don't know if PGP accepts text signed by GPG with --not-dash-escaped
> nor do I know if there really is a problem with mailing such patches.
> But the warning above is nasty enough to rule it out. The only other
> option for signed patches is uuencode or MIME (with or without
> compression) and Linus does not like that format.
>
But we're not dealing with Linus with 2.4 anymore. Maybe Marcello will
accept signed compressed patches. With a few modifications, most MUAs that
support external processing could be setup to verify the sig, uncompress,
and view in the message area.
MF
On Tue, 27 Nov 2001, Anuradha Ratnaweera wrote:
> If I understand correctly, -preX releases will be for adding features and bug
> fixes and -rcX releases will be for only bug fixes.
>
> Hopefully, there won't be _any_ change from last -rc release to the -final.
That certainly seems to be the usual way to do release candidates. For
ongoing enhancement, there can either be a freeze while the -rcN process
is happening, or the next -pre fixes can go against -rc1.
Example:
2.4.20-pre5 -> 2.4.20-rc1 -> 2.4.20-rc2 -(becomes)-> 2.4.20
\
(also called)
\
\__ 2.4.21-pre0 -> 2.4.21-pre1 -> 2.4.21-pre2 -> ...
It all depends on the choice of the maintainer between holding off
addition of changes and slight increases in version numbering. Alan Cox
sort of "alternates," his releases are stable unless the ChangeLog says
otherwise. I've been using his release as "really stable" for some time,
although now I need patches which are never going to make it into the main
kernel AFAIK.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
"David S. Miller" <[email protected]> writes:
> Are you suggesting that, for example, I should send every Sparc change
> to this list?
>
> I bet a lot of what he is seeing are driver and arch updates.
>
> Such updates really only need to go through his "stupid filter"
> when it is coming from the maintainer, but it does add up and
> take up time.
A real problem is the large number of driver patches that come in
from non maintainers.
Jes