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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.