kernel change logs (was Re: (reiserfs) Re: RFC: Re: journal ports for 2.3?)

Jeff Garzik (jgarzik@mandrakesoft.mandrakesoft.com)
Sun, 26 Dec 1999 12:54:09 -0600 (CST)


(copied to linux-kernel)

On Sun, 26 Dec 1999, Erez Zadok wrote:
> In message <Pine.LNX.3.96.991223135110.3407B-100000@mandrakesoft.mandrakesoft.com>, Jeff Garzik writes:
> > On Thu, 23 Dec 1999, Hans Reiser wrote:
> > > All I'm going to ask is that if mark_buffer_dirty gets changed again,
> > > whoever changes it please let us know this time..... The last two times
> > > it was changed we weren't informed, and the first time it happened it
> > > took a long time to figure it out.

> > Can't you figure this sort of thing out on your own? Generally if you
> > want to stay updated on something, you are the one who needs to do the
> > legwork. And grep'ing patches ain't that hard....

> Jeff, Hans is absolutely right.

So, you are accepting the job of notifying Hans each time
mark_buffer_dirty changes? ;-)

Hans is not right, because the request does not scale. I would love to
be notified whenever drivers/video changes, for example, but I'm sure
Geert and Linus have better things to do with their time.

A small Perl script usings ctags and grep (or other means) can get
you a list of functions changed in each release.

> In my case (stackable f/s), every time there's a change to
> anything under linux/fs, linux/mm, or headers, I've got to find out what
> changed and how it affected my code.

Any change of the kernel core requires analysis and testing in order
to determine the effects on other code. E-mail notification doesn't
change that.

> There is no ChangeLog[...]

> Hans and linux-fsdevel folks: I have a proposal. How would you all feel
> forming an informal group that would report changes relevant to f/s
> developers on this list. (Maybe even a different mailing list?) I'm
[...]
> Comments?

In the past, I have publicly and privately argued for maintained
ChangeLogs in the kernel. There are so many advantages, especially
when hacking up old unmaintained code. There have been several cases
of hackers duplicating old (but buggy) submissions, which could have
been avoided had they read a well-maintained ChangeLog. Those who
ignore (or are ignorant of, in this case) history are doomed to
repeat it. :)

Linux is getting enough attention and eyes that I think ChangeLogs
would be of immense value. Many people read and learn from the
kernel code -- and even more knowledge can be gleaned from reading
ChangeLogs sometimes. But none of the people who write most of the
code indicated any interest. gcc project requires a ChangeLog entry
with each submission, something I would _love_ to see. But that
requires Linus intervention. And that requires convincing Linus,
Alan, DaveM, Al Viro, and other submitters of large patches to agree
to write ChangeLog entries.

Without such a requirement, partially maintained ChangeLogs have
even less advantage over no ChangeLogs at all -- in this case, no
docs would be better than wrong docs IMNSHO.

As to your suggestion, a group of people posting VFS changelogs -- more
power to you! It's better than nothing. Just make sure such ChangeLogs
are actively maintained, if they ever make it off the mailing list and
into the kernel sources.

To sum, documenting changes is a very good idea, notifying specific
hackers of specific kernel changes is a waste of time [unless they
are the maintainers of the code being changed, of course].

Jeff

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