From: Jeff Garzik <jgarzik@pobox.com>
To: Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: Release of 2.4.21
Date: Thu, 20 Mar 2003 15:53:38 -0500 [thread overview]
Message-ID: <20030320205338.GG8256@gtf.org> (raw)
In-Reply-To: <20030320204218.A18517@infradead.org>
On Thu, Mar 20, 2003 at 08:42:18PM +0000, Christoph Hellwig wrote:
> On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc. Don't disrupt
> > the 2.4.21-pre cycle, that would be less productive than just patching
> > 2.4.20 and rolling a separate release off of that.
>
> I think the naming is illogical. If there's a bugfix-only release
Many, many companies seem to find it logical. If you want to squeeze
a version in between "1" and "2".
Further, other kernel hackers suggested the 2.4.20.N sequence,
I simply agreed with it. So it's not only me who thinks this way :)
> it whould have normal incremental numbers. So if marcelo want's
> it he should clone a tree of at 2.4.20, apply the essential patches
> and bump the version number in the normal 2.4 tree to 2.4.22-pre1
Human nature says that will drag out the -pre tree ad infinitum.
Suppose a 2.4.21 is released today, with 2.4.20 + bug fixes. Now,
tomorrow, another "critical bug" comes out, and then the -pre tree
becomes 2.4.23-pre. Add another critical bug, and I hope you see
the continual delay of -pre happens here...
The basic logic is "do not disrupt current plans. Do something
_in addition to_ current plans."
Jeff
next prev parent reply other threads:[~2003-03-20 20:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-20 19:56 Release of 2.4.21 Adrian Knoth
2003-03-20 20:21 ` Sebastian D.B. Krause
2003-03-20 20:34 ` Jeff Garzik
2003-03-20 20:42 ` Christoph Hellwig
2003-03-20 20:53 ` Jeff Garzik [this message]
2003-03-20 21:05 ` David Lang
2003-03-21 1:55 ` Andrew Morton
2003-03-21 0:13 ` John Bradford
2003-03-21 1:30 ` Samuel Flory
2003-03-21 9:33 ` John Bradford
2003-03-21 8:40 ` Bernd Petrovitsch
2003-03-21 9:23 ` John Bradford
2003-03-21 21:53 ` Daniel Egger
2003-03-22 8:27 ` John Bradford
2003-03-22 14:54 ` Daniel Egger
2003-03-21 1:01 ` Alan Cox
2003-03-21 0:04 ` David Lang
[not found] <20030320200019$6ddc@gated-at.bofh.it>
[not found] ` <20030320203015$4839@gated-at.bofh.it>
2003-03-20 20:43 ` Florian Weimer
2003-03-20 21:03 ` Jeff Garzik
2003-03-20 21:33 ` H. Peter Anvin
2003-03-20 22:08 ` Sebastian D.B. Krause
2003-03-21 11:06 ` Oliver Feiler
2003-03-20 22:18 ` Arador
2003-03-21 1:20 ` Chris Wright
-- strict thread matches above, loose matches on Subject: below --
2003-03-20 21:17 Dow, Benjamin
2003-03-21 0:57 ` Alan Cox
[not found] <20030320205011$1378@gated-at.bofh.it>
[not found] ` <20030320205011$0acb@gated-at.bofh.it>
[not found] ` <20030320205011$2c88@gated-at.bofh.it>
[not found] ` <20030320211011$5967@gated-at.bofh.it>
2003-03-20 21:48 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030320205338.GG8256@gtf.org \
--to=jgarzik@pobox.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox