lkml.org 
[lkml]   [2000]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] Changes file [was Re: modules directory]
Date
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.073 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site