From: Stephan von Krawczynski <skraw@ithnet.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: reiser@namesys.com, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
Date: Mon, 3 Nov 2003 11:20:08 +0100 [thread overview]
Message-ID: <20031103112008.5ac6a6cc.skraw@ithnet.com> (raw)
In-Reply-To: <20031102210942.GA9635@gondor.apana.org.au>
On Mon, 3 Nov 2003 08:09:42 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:
Forgive my comments unrelated to the primary topic, but I think additional
voices may do something good to your general idea of a distro.
> On Sun, Nov 02, 2003 at 02:54:45PM +0300, Hans Reiser wrote:
> >
> > Why in the world do you guys do this? Andrew and Marcelo do a good job,
> > and I haven't heard much complaint about patches being ignored by them,
> > so follow the leader. If you have patches you need, send them to them.
>
> Andrew and Marcelo do an excellent job. I have never said otherwise
> nor attempted to infer that.
>
> The reasons that we need patches are mostly the same as other distributions:
>
> 1. Our release schedule is different from the vanilla kernels.
>
> When we release a kernel based on a vanilla release there may be bug
> fixes that are going to be in the next vanilla release that we can
> apply straight away.
Release cycle of vanilla kernels has become short/acceptable again, so it
should be possible to pick one up inside your timeframe. And yes, there will
always be another bug, so if you go hunting for only the next bugfix, you will
probably be releasing never again.
> 2. Our goals are different from the vanilla kernel.
>
> Some issues are not critical to the vanilla kernel, e.g., IDE modules
> but are release-critical for us.
You are talking about an additional _feature_. Why don't you try to make it an
accepted and implemented feature in the vanilla kernels? Sure this may take a
bit more time, but the community wins as a whole. I cannot see the point in
_separation_ regarding GPL'ed software.
> 3. Licensing problems.
>
> This is specific to Debian. For anything to be included in our release,
> it has to pass the DFSG. The vanilla kernel does not have this
> restriction so we may need to remove bits before it's suitable for us.
Uh? Do you place licensing restrictions on a GPL'ed kernel??
I really send prayers for the day distros will stop building own kernels for
they only reduce the installed test base for kernels as a whole by splitting it
up in numerous kernel versions...
Regards,
Stephan
next prev parent reply other threads:[~2003-11-03 10:20 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-28 15:49 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431" lkml-031028
2003-10-28 18:36 ` Hans Reiser
2003-10-28 20:27 ` Oleg Drokin
2003-10-28 22:13 ` Andrew Morton
2003-10-28 22:15 ` Hans Reiser
2003-10-29 6:56 ` lkml-031028
2003-10-29 17:44 ` lkml-031028
2003-10-29 20:31 ` Andrew Morton
2003-10-29 21:49 ` Oleg Drokin
2003-10-29 22:19 ` Andrew Morton
2003-10-30 6:22 ` lkml-031028
2003-10-30 6:51 ` lkml-031028
2003-11-02 7:17 ` Herbert Xu
2003-11-02 7:33 ` Andrew Morton
2003-11-02 9:18 ` Oleg Drokin
2003-11-02 9:27 ` Herbert Xu
2003-11-02 9:40 ` Andrew Morton
2003-11-02 9:54 ` Herbert Xu
2003-11-02 11:54 ` Hans Reiser
2003-11-02 21:09 ` Herbert Xu
2003-11-03 10:20 ` Stephan von Krawczynski [this message]
2003-11-04 8:10 ` Hans Reiser
2003-11-04 21:03 ` Debian Kernels was: " Mike Fedyk
2003-11-04 9:54 ` Hans Reiser
2003-11-04 23:49 ` Stephan von Krawczynski
2003-11-05 0:05 ` Mike Fedyk
2003-11-16 13:05 ` Pavel Machek
2003-11-16 3:55 ` Hans Reiser
2003-11-16 14:15 ` Stephan von Krawczynski
2003-11-16 17:05 ` Pavel Machek
2003-11-16 17:27 ` Valdis.Kletnieks
2003-11-16 17:40 ` Stephan von Krawczynski
2003-11-16 18:38 ` Valdis.Kletnieks
2003-11-16 22:54 ` Stephan von Krawczynski
2003-11-16 17:30 ` Stephan von Krawczynski
2003-11-02 11:50 ` Hans Reiser
2003-11-02 20:33 ` Herbert Xu
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=20031103112008.5ac6a6cc.skraw@ithnet.com \
--to=skraw@ithnet.com \
--cc=akpm@osdl.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=reiser@namesys.com \
/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