Hi,
There is no doubt any development model has some problems, and ours
can't be an exception. I'd like to share with you an idea which
recently found a way to my mind.
There is a problem that a development cycle (time between stable
= non-pre/rc versions) is long. Imagine a situation when we are at
some pre-3 stage, the kernel tree is full of problems which must be
resolved before the final release, and some serious security-class
bug has been found. We would be unable to have a secured stable
version shortly unless the maintainer checks through all changes to
last stable kernel, identify fixes which are both safe and necessary
(hopefully there are no necessary unsafe ones at that time), and
back-out everything else. Such a scenario is real and that way we might
end up with official kernel being unusable for any Internet-connected
tasks for weeks.
Here is what I propose:
As all of you know, the development cycle can be shortened by using
two separate trees for a stable kernel line.
Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
both kernels, and other patches (which can't go to "rc" kernel) would
be applied to 2.4.24-pre1 only.
After 2.4.23-rcX becomes final 2.4.23, the 2.4.24-preX would become
2.4.24-rc1 and would be a base for 2.4.25-pre1.
This way:
- there would be no time when patches aren't accepted
- the development cycle would be shorter. In fact it would be much
less important as there would always be an up-to-date stable version.
- we would avoid a mess of having two separate trees, with different
fixes going in and out.
- the amount of added maintainer's work is minimal, especially if patch
authors specify which tree they want it to go in (i.e. even a small
trivial patch would be applied to "pre" only if requested by the
author).
- the 2.X.Y-pre* patch would always be based on latest 2.X.Y-1-rc or
final kernel.
- as an option, we could go from absolute to incremental -pre and -rc
patches: i.e. rc2 would be based on rc1 and pre2 on pre1. It would be
easier for both disks and people (no need to patch -R).
Of course, I know 2.4-ac patches maintained by Alan Cox fulfilled
some (most?) of these points, even if it wasn't their primary function.
This mail isn't about criticizing anyone nor anything, and is not only
related to 2.4 kernel - I just try to make the development process of
stable kernel lines a little better.
Comments?
--
Krzysztof Halasa, B*FH
Hi Krysztof.
> As all of you know, the development cycle can be shortened by using
> two separate trees for a stable kernel line.
>
> Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
> known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
> both kernels, and other patches (which can't go to "rc" kernel) would
> be applied to 2.4.24-pre1 only.
>
> After 2.4.23-rcX becomes final 2.4.23, the 2.4.24-preX would become
> 2.4.24-rc1 and would be a base for 2.4.25-pre1.
And then someone comes along and says that feature X isn't working in
some version. He then reports that "it worked in a.b.c but then someone
broke it for a.b.c+1 pre 1. Then you have to tell that person that
a.b.c+1 pre 1 isn't newer than a.b.c. Messy. Very messy.
The list gets too many mails that are answered by "RTFM" already.
// Stefan
On Sun, 09 Nov 2003 19:41:02 +0100, Krzysztof Halasa said:
> Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
> known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
> both kernels, and other patches (which can't go to "rc" kernel) would
> be applied to 2.4.24-pre1 only.
Two kernels getting different patches... (consider the case of a security
patch that hits code that was already hit by a previous -preN-ony patch,
so two different diffs are needed for the two trees)
> - we would avoid a mess of having two separate trees, with different
> fixes going in and out.
So I don't see how this follows?
Krzysztof Halasa <[email protected]> wrote:
>
> There is a problem that a development cycle (time between stable
> = non-pre/rc versions) is long. Imagine a situation when we are at
> some pre-3 stage, the kernel tree is full of problems which must be
> resolved before the final release, and some serious security-class
> bug has been found.
Well yes. Two days after 2.4.20 was released we discovered a
data-corrupting bug in ext3. I had no means of delivering a fix for that
apart from sticking a bunch of patches on my web page and making a lot of
noise about it.
So there is a case for a "2.4.20-post1" release to address such things.
Hi Krzysztof,
Something like this has already been proposed a few times in the past (even
recent past), and I'm also all for a real permanently stable release which
only fixes bugs and vulnerabilities of the previous release. But there were
some massive objections, amongst others (IIRC) :
- maintaining two trees is always more work than only one tree for the
same person, whatever the changes. This is obviously true, otherwise
none of us would ask for someone else to maintain the stable tree :-)
I believe this reason was given by both Alan and Marcelo at different
times.
- I think it was Linus who said that clueless people will only use distro's
kernels, therefore are not affected by how the kernel is developped. And
for other people like us, the "stable" kernel will never contain enough
features and we will have to patch anyway.
- someone else (alan ?) said that even most obvious fixes can break some
setups, so there are not many "obviously riskless" patches around, and
if there's a really critical one which needs to go mainstream very quickly,
then the maintainer can always release a new version in a hurry and delay
-preX pending features for the next release.
I too would love to see frequent releases of bug fixes only, but I can admit
that it would not be fair to ask a handful of people to do more work just to
serve a few hundreds of lazy or busy people around. And BTW, there are now
people trying to maintain parallel bugfixes-only branches. Take a look at
James Bourne's site : http://www.hardrock.org/kernel/current-updates/
As long as individual patches are easily available, it's not too hard for
us to integrate them into our kernels.
Regards,
Willy
Hi Linus,
[Off-list]
Quote from Krzysztof Halasa <[email protected]>:
> Such a scenario is real and that way we might
> end up with official kernel being unusable for any Internet-connected
> tasks for weeks.
This does highlight a real issue - I am concerned by the number of
posts on sites like lwn.net saying things like, "Oh, I'm using 2.6 as
my standard kernel now", when it is clear that a lot of those users
simply do not understand the issues.
>
> Here is what I propose:
> As all of you know, the development cycle can be shortened by using
> two separate trees for a stable kernel line.
>
> Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
> known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
> both kernels, and other patches (which can't go to "rc" kernel) would
> be applied to 2.4.24-pre1 only.
>
> After 2.4.23-rcX becomes final 2.4.23, the 2.4.24-preX would become
> 2.4.24-rc1 and would be a base for 2.4.25-pre1.
>
> This way:
> - there would be no time when patches aren't accepted
> - the development cycle would be shorter. In fact it would be much
> less important as there would always be an up-to-date stable version.
> - we would avoid a mess of having two separate trees, with different
> fixes going in and out.
> - the amount of added maintainer's work is minimal, especially if patch
> authors specify which tree they want it to go in (i.e. even a small
> trivial patch would be applied to "pre" only if requested by the
> author).
> - the 2.X.Y-pre* patch would always be based on latest 2.X.Y-1-rc or
> final kernel.
> - as an option, we could go from absolute to incremental -pre and -rc
> patches: i.e. rc2 would be based on rc1 and pre2 on pre1. It would be
> easier for both disks and people (no need to patch -R).
>
> Of course, I know 2.4-ac patches maintained by Alan Cox fulfilled
> some (most?) of these points, even if it wasn't their primary function.
>
> This mail isn't about criticizing anyone nor anything, and is not only
> related to 2.4 kernel - I just try to make the development process of
> stable kernel lines a little better.
>
> Comments?
> --
> Krzysztof Halasa, B*FH
> -
> 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/
> Well yes. Two days after 2.4.20 was released we discovered a
> data-corrupting bug in ext3. I had no means of delivering a fix for that
> apart from sticking a bunch of patches on my web page and making a lot of
> noise about it.
>
> So there is a case for a "2.4.20-post1" release to address such things.
This sort of points to a (possible?) simple solution. Continue everything
as it is now, however if we ever (or rather when...) discover a serious
security or data corruption bug in _the_ _last_ stable 2.4/6.y kernel then
the patch for it should be posted in the same directory as the kernel as
incremental 2.x.y-pots/bugfix/errata1 (2 etc) patch. Obviously this would
only need to be maintained for the last stable 2.4 or 2.6 kernel (either you
use a distro kernel or you are presumably using the latest one from a 2.x
branch). The important part here is that these bugfixes would be
available straight from the same source as the kernel and thus would be
hard to miss and easy to check for.
Obviously this could also be extended to include other non-threatening
bugs, however this would probably be too bothersome to maintain - that's
why I'd only post security and data corruption bugfixes this way.
Cheers,
MaZe.
Probably the sanest suggestion yet.. patch names could match BK csets
with a <foo>.diff as well as a <foo>.desc file. easy implementation, and
a later date im sure someone will write up some scripts for this, aka
for export from BK as well as import from kernel.org..
matt
On Sun, 09 Nov 2003 19:50:00 GMT, John Bradford said:
> This does highlight a real issue - I am concerned by the number of
> posts on sites like lwn.net saying things like, "Oh, I'm using 2.6 as
> my standard kernel now", when it is clear that a lot of those users
> simply do not understand the issues.
On the other hand, Linux is about freedom, even if it's the freedom
to shoot yourself in the foot.
I really don't see that we need to do much of anything to change our
development scheme. I think that James Bourne's -uv patch series
is all that's needed, and that the only thing we need to do is make
sure there's resources available to keep it going (find it a home
on the http://www.kernel.org server, provide a link for it so people can
actually *find* it, and somehow provide for continuity in case James
gets hit by a bus or something equally unfortunate.
On Sunday 09 November 2003 13:50, John Bradford wrote:
> Hi Linus,
>
> [Off-list]
>
> Quote from Krzysztof Halasa <[email protected]>:
> > Such a scenario is real and that way we might
> > end up with official kernel being unusable for any Internet-connected
> > tasks for weeks.
>
> This does highlight a real issue - I am concerned by the number of
> posts on sites like lwn.net saying things like, "Oh, I'm using 2.6 as
> my standard kernel now", when it is clear that a lot of those users
> simply do not understand the issues.
At the same time, you _want_ as many testers as you can get finding the
strange bugs where burning cd's on an ACPI-powered laptop interacts strangely
with 3D acceleration. And now that we're in the -test series, we want _more_
of them.
We know it's not safe. There's a very real risk of a data-eating bug that
could take out our filesystem (especially if we're using things like software
suspend). Of course those of us dragging laptops around have a very real
risk of getting the suckers rained on, dropped, stolen, etc. Very few
non-laptop computers get run over by one's own car. There's a larger than
average chance of unintentional beverage interaction too, since the vital
components are right under the keyboard in the beverage equivalent of ground
zero. (And don't tell me the hard drive enjoys being right under the
keyboard, either. Thump, thump, thump...)
So we have to back up a lot anyway. :)
99% of computer users don't understand the "issues" of connecting Windows XP
to the internet, yet they do it anyway. (Well, about 20% of them do. More
than that use W2k, and more than _that_ still use 98!) I'd say there are a
lot more issues with XP than 2.6. (For one thing, 2.6 doesn't dial home to
Linus and tell him what software packages you've installed. :)
I don't see what point is served by warning people away from a beta, pre-.0
release. I think we know. Security considerations are just one more element
of the party mix, and most of these are local (they've got to have broken
into the box ANYWAY, it just potentially lets 'em crack root once they're
in).
I'm still a lot more worried about what the kernel's doing to my filesystem
than what some malicious twit on the internet is likely to do. That's the
main reason it's still -test...
Rob
Quote from Rob Landley <[email protected]>:
> On Sunday 09 November 2003 13:50, John Bradford wrote:
> > Hi Linus,
> >
> > [Off-list]
> >
> > Quote from Krzysztof Halasa <[email protected]>:
> > > Such a scenario is real and that way we might
> > > end up with official kernel being unusable for any Internet-connected
> > > tasks for weeks.
> >
> > This does highlight a real issue - I am concerned by the number of
> > posts on sites like lwn.net saying things like, "Oh, I'm using 2.6 as
> > my standard kernel now", when it is clear that a lot of those users
> > simply do not understand the issues.
>
> At the same time, you _want_ as many testers as you can get finding the
> strange bugs where burning cd's on an ACPI-powered laptop interacts strangely
> with 3D acceleration. And now that we're in the -test series, we want _more_
> of them.
Note - this was post incomplete and badly thought out - I never
intended this to go to the list, as evidenced by the [Off-list]
comment, and the only reason it was sent at all is because I hit send
instead of delete, (and hadn't trimmed the CC list yet).
What I originally intended to say in a private comment to Linus, is
that it might be worth trying to make people more aware that security
patches that went in to 2.4 never went in to 2.6, nothing more, and
nothing less. I am NOT trying to put people off of testing, and never
have been, (which is the impression I got from your response).
> Security considerations are just one more element
> of the party mix, and most of these are local (they've got to have broken
> into the box ANYWAY, it just potentially lets 'em crack root once they're
> in).
>
> I'm still a lot more worried about what the kernel's doing to my filesystem
> than what some malicious twit on the internet is likely to do. That's the
> main reason it's still -test...
No, I disagree. If somebody's filesystem gets eaten, and they didn't
back up, well, they should have done. That's common sense.
On the other hand, many users out there are _obviously_ under the
illusion that 2.6.0-test has no known security issues, and that is
false. If their machine is internet-connected and compromised, it can
cause annoyance to third parties. Given that, I think a file in the
root of the kernel tree, saying something like, "Don't use me on an
internet connected machine unless you know what you're doing" would be
worth considering.
John.
Quote from [email protected]:
> --==_Exmh_-1945224656P
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, 09 Nov 2003 19:50:00 GMT, John Bradford said:
> > This does highlight a real issue - I am concerned by the number of
> > posts on sites like lwn.net saying things like, "Oh, I'm using 2.6 as
> > my standard kernel now", when it is clear that a lot of those users
> > simply do not understand the issues.
>
> On the other hand, Linux is about freedom, even if it's the freedom
> to shoot yourself in the foot.
>
> I really don't see that we need to do much of anything to change our
> development scheme. I think that James Bourne's -uv patch series
> is all that's needed, and that the only thing we need to do is make
> sure there's resources available to keep it going (find it a home
> on the http://www.kernel.org server, provide a link for it so people can
> actually *find* it, and somehow provide for continuity in case James
> gets hit by a bus or something equally unfortunate.
See my other post in this thread - I never intended to post that
comment. I am not in favour of any change in development, just a big
notice that says, "Be careful". That doesn't take away any freedom,
and I think that there are obviously users who would benefit from it.
John.
On 9 Nov 2003, Krzysztof Halasa wrote:
> Hi,
>
> There is no doubt any development model has some problems, and ours
> can't be an exception. I'd like to share with you an idea which
> recently found a way to my mind.
>
> There is a problem that a development cycle (time between stable
> = non-pre/rc versions) is long. Imagine a situation when we are at
> some pre-3 stage, the kernel tree is full of problems which must be
> resolved before the final release, and some serious security-class
> bug has been found. We would be unable to have a secured stable
> version shortly unless the maintainer checks through all changes to
> last stable kernel, identify fixes which are both safe and necessary
> (hopefully there are no necessary unsafe ones at that time), and
> back-out everything else. Such a scenario is real and that way we might
> end up with official kernel being unusable for any Internet-connected
> tasks for weeks.
>
> Here is what I propose:
> As all of you know, the development cycle can be shortened by using
> two separate trees for a stable kernel line.
>
> Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
> known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
> both kernels, and other patches (which can't go to "rc" kernel) would
> be applied to 2.4.24-pre1 only.
>
> After 2.4.23-rcX becomes final 2.4.23, the 2.4.24-preX would become
> 2.4.24-rc1 and would be a base for 2.4.25-pre1.
I really dont understand this "be a base for 2.4.25-pre1".
I guess what you mean is you want a separate 2.4.24-pre tree accepting
"-pre" patches while 2.4.23-rc is "in stage" accepting critical bugfixes
only.
That would be useful yes. Maybe Andrew should do it in 2.6 ?
> There is a problem that a development cycle (time between stable
> = non-pre/rc versions) is long.
This sentiment is expressed fairly often, and I have never seen it challenged.
However, I am not convinced that it is true. I do not believe that people
who care about stability want to upgrade to a new kernel with major changes
in it every 9 months. It also takes a fairly long time for our "stable"
kernels to actually get stable enough that vendors are comfortable shipping
them. I think if our develpment cycle gets significantly shorter, you will
end up with vendors skipping entire stable series (ie. moving from 2.2 to 2.6
without ever doing 2.4). I think that would create more pain for us than our
current release cycle length does.
Thanks,
Jim
On Sun, Nov 09, 2003 at 07:41:02PM +0100, Krzysztof Halasa wrote:
> Hi,
Hi Krzysztof,
>...
> Here is what I propose:
> As all of you know, the development cycle can be shortened by using
> two separate trees for a stable kernel line.
>
> Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
> known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
> both kernels, and other patches (which can't go to "rc" kernel) would
> be applied to 2.4.24-pre1 only.
>...
> Comments?
I don't like this idea for the following reason:
A -rc kernel of a stable series needs maximum testing to avoid any
regressions compared to the previous stable kernel.
If you start a new -pre series at the time of an -rc series many people
will use the new -pre instead of the latest -rc decreasing the number of
people testing this -rc and therefore increasing the risk of problems in
the final kernel.
> Krzysztof Halasa, B*FH
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Nov 10, 2003 at 08:50:44AM +0000, John Bradford wrote:
> On the other hand, many users out there are _obviously_ under the
> illusion that 2.6.0-test has no known security issues, and that is
> false. If their machine is internet-connected and compromised, it can
> cause annoyance to third parties. Given that, I think a file in the
> root of the kernel tree, saying something like, "Don't use me on an
> internet connected machine unless you know what you're doing" would be
> worth considering.
Something vaguely like this might help the issue (with the obvious file
created having the appropriate note in it)
Untested, and I'm sure there are style problems, but the idea should be
obvious:
--- Makefile 2003-10-26 19:04:21.000000000 -0500
+++ Makefile.ryan 2003-11-11 02:45:01.000000000 -0500
@@ -81,7 +81,7 @@
# That's our default target when none is given on the command line
.PHONY: all
-all:
+all: check-beta
ifneq ($(KBUILD_OUTPUT),)
# Invoke a second make in the output directory, passing relevant variables
@@ -1027,3 +1027,12 @@
endif # skip-makefile
FORCE:
+
+.PHONY: check-beta
+
+check-beta:
+ if [ -f README.Security && ! -f README.Security.IknowwhatImdoing ] ; then \
+ cat README.Security ; \
+ read ; \
+ fi
+
--
Ryan Anderson
sometimes Pug Majere
On Mon, 10 Nov 2003 08:50:44 GMT, John Bradford <[email protected]> said:
> cause annoyance to third parties. Given that, I think a file in the
> root of the kernel tree, saying something like, "Don't use me on an
> internet connected machine unless you know what you're doing" would be
> worth considering.
OK.. I'll bite.. :)
What *additional* level of "know what you're doing" is called for, over and
above the usual "best practices" we wish all net-connected machines implemented?
Or phrased differently - yes, there's several local-user-gets-root attacks that
aren't patched. However, I'm sure that even a tightened down and fully-patched
system has several ways to do that without leveraging a kernel bug, so the
question becomes "balance the chances that the attacker has an exploit for the
kernel bug" against "chance attacker has exploit for set-UID program XYZ".
Or is the assumption that if you understand how "remote execution of
arbitrary code as local user" combines with "local user gets root" to
form the product "you're screwed", sufficient clue is available?
Quote from [email protected]:
> --==_Exmh_1622051872P
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, 10 Nov 2003 08:50:44 GMT, John Bradford <[email protected]> said:
>
> > cause annoyance to third parties. Given that, I think a file in the
> > root of the kernel tree, saying something like, "Don't use me on an
> > internet connected machine unless you know what you're doing" would be
> > worth considering.
>
> OK.. I'll bite.. :)
>
> What *additional* level of "know what you're doing" is called for, over and
> above the usual "best practices" we wish all net-connected machines implemented?
>
> Or phrased differently - yes, there's several local-user-gets-root attacks that
> aren't patched. However, I'm sure that even a tightened down and fully-patched
> system has several ways to do that without leveraging a kernel bug, so the
> question becomes "balance the chances that the attacker has an exploit for the
> kernel bug" against "chance attacker has exploit for set-UID program XYZ".
>
> Or is the assumption that if you understand how "remote execution of
> arbitrary code as local user" combines with "local user gets root" to
> form the product "you're screwed", sufficient clue is available?
I don't even know why this thread is continuing - I have already
pointed out that I intended to cancel my original post, but hit the
wrong key. I.E. I had changed my mind about the importance of the
issue. If you don't belive me, note the face that I hadn't trimmed
the quotes on the original post, and the fact that it was addressed as
a private comment to Linus, anyway, (I hadn't yet removed the CC
list).
Nevertheless, I the point I just brought up is much simpler than you
are making it seem.
My experience, at least, has been that during the development of most
userspace applications, security fixes which apply to both stable and
unstable branches are applied at the same time. I think users have
come to expect that, even though that is bad practice.
In any case - we work differently, and don't make that fact at all
obvious. Rather than suggesting we change the way we work, (not
practical), I am suggesting that we educate people, (not easy, but we
can do our bit - provide the information).
The upshot of all this is that an admin who is _generally responsible
and knows what he is doing_, may well be under the impression that
running a development kernel on a network connected box may eat his
filesystem, but that it would not contain _known_ security
vulnerabilities. Be aware that a compromised box could be used as a
vector for attack on other boxes, including those of innocent third
parties, (E.G. on a datacentre LAN).
A typical admin may decide to run, E.G. a news server or web proxy
server with a development kernel, on the basis that even if the
machine is trashed, it doesn't matter, not being aware of the security
issues.
John.
On Sul, 2003-11-09 at 19:26, Andrew Morton wrote:
> Well yes. Two days after 2.4.20 was released we discovered a
> data-corrupting bug in ext3. I had no means of delivering a fix for that
> apart from sticking a bunch of patches on my web page and making a lot of
> noise about it.
>
> So there is a case for a "2.4.20-post1" release to address such things.
For 2.2 I kept changelogs and errata patches for any big problem. For
-ac its always been a bit simpler because -ac1 is in part 2.4.20-post1
so I had an unfair advantage over people. The other thing -ac did was a
new patch every 2-3 days. The more you get out the more feedback you get
back and the faster you take fixes (even small ones) the more
committment you get from other people in my experience.
[email protected] writes:
> However, I am not convinced that it is true. I do not believe that people
> who care about stability want to upgrade to a new kernel with major changes
> in it every 9 months.
Not sure what do you mean, but I was writing about time between _minor_
versions - for example, between 2.4.22 and 2.4.23.
--
Krzysztof Halasa, B*FH
Adrian Bunk <[email protected]> writes:
> A -rc kernel of a stable series needs maximum testing to avoid any
> regressions compared to the previous stable kernel.
>
> If you start a new -pre series at the time of an -rc series many people
> will use the new -pre instead of the latest -rc decreasing the number of
> people testing this -rc and therefore increasing the risk of problems in
> the final kernel.
Not exactly - the X-pre kernel would contain all patches contained in
X-1-rc available at the time. While there is a (relatively small) chance
that a subset of independent patches breaks things while the complete set
does not, all patches contained in -rc would be tested by both rc and pre
users.
Of course, many people would stick to -rc patches only, and others would
use just final kernels.
--
Krzysztof Halasa, B*FH
[email protected] writes:
> Two kernels getting different patches... (consider the case of a security
> patch that hits code that was already hit by a previous -preN-ony patch,
> so two different diffs are needed for the two trees)
Yes, this is theoretically possible. Do you think it would be a frequent
case?
--
Krzysztof Halasa, B*FH
Stefan Smietanowski <[email protected]> writes:
> And then someone comes along and says that feature X isn't working in
> some version. He then reports that "it worked in a.b.c but then someone
> broke it for a.b.c+1 pre 1. Then you have to tell that person that
> a.b.c+1 pre 1 isn't newer than a.b.c. Messy. Very messy.
I think people using testing/ kernels are able to learn such things.
--
Krzysztof Halasa, B*FH
Marcelo Tosatti <[email protected]> writes:
> > After 2.4.23-rcX becomes final 2.4.23, the 2.4.24-preX would become
> > 2.4.24-rc1 and would be a base for 2.4.25-pre1.
>
> I really dont understand this "be a base for 2.4.25-pre1".
Is the same way as 2.4.24 will be - i.e. from a -pre kernel point of
view, last -rc = final.
> I guess what you mean is you want a separate 2.4.24-pre tree accepting
> "-pre" patches while 2.4.23-rc is "in stage" accepting critical bugfixes
> only.
Yes.
The advantage is simple - the maintainer has to evaluate the same set
of patches once (no increase in work here) and the only additional thing
(s)he must do is deciding which (-pre and -rc or only -rc) kernels does
it go in.
--
Krzysztof Halasa, B*FH
Willy Tarreau <[email protected]> writes:
> - maintaining two trees is always more work than only one tree for the
> same person, whatever the changes. This is obviously true, otherwise
> none of us would ask for someone else to maintain the stable tree :-)
> I believe this reason was given by both Alan and Marcelo at different
> times.
Sure. However, with this scenario, the amount of additional work would be
low, as the time-consuming things are done once for both trees.
> - I think it was Linus who said that clueless people will only use distro's
> kernels, therefore are not affected by how the kernel is developped. And
> for other people like us, the "stable" kernel will never contain enough
> features and we will have to patch anyway.
Not sure about it - while I'm using 2.6.0test on my notebook (my personal
news/mail server + less important things), I also use official kernels
on some machines and patched trees on other ones.
What I _don't_ use is distribution kernel - not because it's bad, but
rather because i don't know it good enough.
> - someone else (alan ?) said that even most obvious fixes can break some
> setups, so there are not many "obviously riskless" patches around, and
> if there's a really critical one which needs to go mainstream very
> quickly,
> then the maintainer can always release a new version in a hurry and delay
> -preX pending features for the next release.
-post, yes. But it only solves this one problem.
--
Krzysztof Halasa, B*FH
Krzysztof Halasa wrote:
> Stefan Smietanowski <[email protected]> writes:
>
>
>>And then someone comes along and says that feature X isn't working in
>>some version. He then reports that "it worked in a.b.c but then someone
>>broke it for a.b.c+1 pre 1. Then you have to tell that person that
>>a.b.c+1 pre 1 isn't newer than a.b.c. Messy. Very messy.
>
>
> I think people using testing/ kernels are able to learn such things.
The amount of mail coming to the list with FAQ like that shows that
no, people aren't. Many are, some aren't. Some of those end up asking
things that have been asked a thousand times.
// Stefan
Stefan Smietanowski <[email protected]> writes:
> The amount of mail coming to the list with FAQ like that shows that
> no, people aren't. Many are, some aren't. Some of those end up asking
> things that have been asked a thousand times.
I've never considered asking a question, even a FAQ, bad. If many people
ask the same question - what does it mean? For me, it just means the
question is an important one and that the problem is not yet solved.
--
Krzysztof Halasa, B*FH
Krzysztof Halasa wrote:
> Stefan Smietanowski <[email protected]> writes:
>
>
>>The amount of mail coming to the list with FAQ like that shows that
>>no, people aren't. Many are, some aren't. Some of those end up asking
>>things that have been asked a thousand times.
>
>
> I've never considered asking a question, even a FAQ, bad. If many people
> ask the same question - what does it mean? For me, it just means the
> question is an important one and that the problem is not yet solved.
Asking a question is not bad, but if we can avoid making a situation
that will generate questions I would say that's a worthwhile goal.
x.y.z - if y is odd it's development, if y is even it's stable.
Easy.
z+1 is always newer than z and hence z+1 should contain a bugfix that
z might not. Also pretty simple. x.y.z+1 pre/rc q does not contain
something that x.y.z pre/rc r has is NOT easy. We both know that
me and you will have no problem whatsoever with this scheme. So it's
not about me and you. I just think it will confuse some people that's
all.
// Stefan
Stefan Smietanowski <[email protected]> writes:
> x.y.z+1 pre/rc q does not contain
> something that x.y.z pre/rc r has is NOT easy. We both know that
> me and you will have no problem whatsoever with this scheme. So it's
> not about me and you. I just think it will confuse some people that's
> all.
That's correct. It seems I have misunderstood your previous email.
This scheme aims for less workload on the maintainers (compared to
different test + stable trees, as with many popular projects) -
the added bit of complexity at least seems to scale well.
Users already have to live with 2.5.1 being a little older than 2.4.22.
testing/* patches are IMHO not for people who may have problems (bigger
than just a moment of confusion) with such things - they will have much
more problems reporting a bug should they found one.
I know this isn't an ideal solution, that's the best I'm currently aware
of: we'd gain much shorter devel cycle at a really small cost.
I agree entirely with Alan and his opinion expressed in this thread.
--
Krzysztof Halasa, B*FH