Simon Huggins wrote:
> On Thu, Sep 07, 2000 at 08:46:56AM +1100, Keith Owens wrote:
> ... and a few more times recent weeks ...
> 
> > <rant>
> > Why don't you look in linux/Documentation/Changes?  That file exist
> > precisely to stop repeated questions like this on the linux kernel
> > developers list.
> > </rant>
> 
> Because the file just lists versions you need.  It doesn't say "since
> version x.y.z you need a newer version".
> 
> Why not make it easy on people and have a log something like:
> 
> 2.4.0-testX-preY
>         Requires modutils-x.y.z otherwise you get error messages like
>         "blah blah blah"
>         Note you should no longer frobnicate the thingummie or bad
>         things will happen.
> 2.3.whatever_it_was
>         You need to mount shm on blah.
> 
> Now when you tell them to read this file it sticks and *next time* they
> look there too.
> Why?
> Because it's a hell of a lot easier to work out what has changed from
> one version to the next.
> 
> It also means that people who ran earlier pre versions of 2.4 but didn't
> upgrade in the mean time for one reason or another can find out what has
> changed between the few versions of this file.
> 
> Stuff like the shm stuff and the modutils stuff has generated a fair bit
> of traffic.  Having a step by step Changelog style file would help
> people get it right the first time.
> 
> Comments?

I'd like to see a directory in the root of the kernel tree having the
name of the kernel version.  Any patch that breaks things writes a one
or two line file into that directory.  When it's time to release a
kernel version you do the following:

  cat 2.4.0-testX/* >>Documentation/Changes
  rm -rf 2.4.0-testX

Forgetting to do this rollup is ok, it doesn't hurt anything. 
Forgetting to include the change log entry in the patch is ok too -
it's not any worse than the current situation.

This approach gives us a way of annotating the important effects of
patches that are actually applied.

I can think of various arguments for not doing this or something like
it, but the only substantive one I can think of is 'no, it would make
it easier to work with the kernel', and I guess this is the argument
that will be applied in this case.  Disclaimer: I don't mind, in fact
being an elitist is kind of fun.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to