Re: 2.6.0test9 Reiserfs boot time "buffer layer error atfs/buffer.c:431"

[Stephan von Krawczynski]

On Mon, 3 Nov 2003 08:09:42 +1100
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/