From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
To: Adrian Bunk <bunk@fs.tum.de>
Cc: Linus Torvalds <torvalds@osdl.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.8-rc1
Date: Mon, 12 Jul 2004 22:22:59 +0200 [thread overview]
Message-ID: <4d8e3fd30407121322615a8a50@mail.gmail.com> (raw)
In-Reply-To: <20040712163417.GT4701@fs.tum.de>
On Mon, 12 Jul 2004 18:34:17 +0200, Adrian Bunk <bunk@fs.tum.de> wrote:
> On Mon, Jul 12, 2004 at 05:56:14PM +0200, Paolo Ciarrocchi wrote:
> >...
> > > OSDL does some tests for any -rc and many other people like me do other
> > > testing. Besides this, most patches already got similar treatment in
> > > -mm. This might not be a base for an ISO 9000 certificate, but it seems
> > > to be sufficietely working for finding most problems before the acttual
> > > release.
> >
> > OSDL does some test for any -rc but the results of these tests don't affect
> > the release process. At least not in an official way.
>
> The Linux kernel development process isn't that much formalized. But if
> someone finds a serious new problem in a -rc kernel a fix will usually
> go into the next -rc.
I agree.
> Compared to some other open source projects like e.g. Debian the Linux
> kernel has a pretty well-working release process (and the 2.6
> development avoided several mistakes of the 2.4 development).
I agree, again.
> > > It would be more important if Linus would release one last -rc that will
> > > be released unchanged (except for EXTRAVERSION a few days later to catch
> > > bugs in last minute changes. This might catch more problems like the JFS
> > > compile problem in 2.6.7.
> >
> > Right,
> > and in those days may be OSDL could run the testsuite we are discussing about.
>
> The way kernel releases currently work IMHO works well with the
> exception that there should be a last -rc that should be released as
> -final a few days later if no problems show up.
>
> What other actual problems do you currently observe?
I really don't want to say that the process is now not working,
I'm just saying that it could be improved.
I totally agree with you when you say that there should be a last -rc
that should be released as final if no problem show up.
What I'd like to add is that in the few days between the last -rc and the final
there is enough time automatically run a few tests like the ltp suite,
the compile
stats and a few regression test.
If nothing strange show up, both from the comunity and the automatically tests,
the new version is released.
I don't want to reinvent the wheel, I see that all the tools are
already here, most of them are maintained by OSDL, so *may be* we
should formalized a bit more
the release process.
I don't see any disadvantage in doing this.
ciao,
Paolo
--
paoloc.doesntexist.org
next prev parent reply other threads:[~2004-07-12 20:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-11 18:29 Linux 2.6.8-rc1 Linus Torvalds
2004-07-11 23:00 ` [PATCH] edd (Re: Linux 2.6.8-rc1) Randy.Dunlap
2004-07-12 3:02 ` Adrian Bunk
2004-07-12 4:49 ` Matt Domsch
2004-07-12 5:21 ` Randy.Dunlap
2004-07-12 9:26 ` Linux 2.6.8-rc1 Matthias Andree
2004-07-12 18:54 ` Martin Schlemmer
2004-07-12 9:34 ` Paolo Ciarrocchi
2004-07-12 15:42 ` Adrian Bunk
2004-07-12 15:56 ` Paolo Ciarrocchi
2004-07-12 16:34 ` Adrian Bunk
2004-07-12 16:43 ` Linus Torvalds
2004-07-12 20:28 ` Paolo Ciarrocchi
2004-07-12 20:22 ` Paolo Ciarrocchi [this message]
2004-07-13 20:54 ` cliff white
2004-07-12 21:08 ` Horst von Brand
2004-07-12 11:30 ` is_highmem() and WANT_PAGE_VIRTUAL (was: Re: Linux 2.6.8-rc1) Geert Uytterhoeven
2004-07-12 13:51 ` Andy Whitcroft
2004-07-12 14:23 ` Geert Uytterhoeven
2004-07-12 12:01 ` Linux 2.6.8-rc1 Geert Uytterhoeven
2004-07-12 13:18 ` OGAWA Hirofumi
2004-07-12 13:25 ` Geert Uytterhoeven
2004-07-12 14:02 ` OGAWA Hirofumi
2004-07-12 13:23 ` struct_cpy() and kAFS (was: Re: Linux 2.6.8-rc1) Geert Uytterhoeven
2004-07-12 18:11 ` Andrew Morton
2004-07-12 18:23 ` Christoph Hellwig
2004-07-12 18:40 ` Andrew Morton
2004-07-13 10:14 ` David Howells
2004-07-12 23:49 ` Linux 2.6.8-rc1 (compile stats) John Cherry
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=4d8e3fd30407121322615a8a50@mail.gmail.com \
--to=paolo.ciarrocchi@gmail.com \
--cc=bunk@fs.tum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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