Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: [RFC] Changes file [was Re: modules directory] | Date | Sat, 09 Sep 2000 17:18:51 +0200 |
| |
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/
|  |