Messages in this thread | | | Date | Sun, 26 Dec 1999 12:54:09 -0600 (CST) | From | Jeff Garzik <> | Subject | kernel change logs (was Re: (reiserfs) Re: RFC: Re: journal ports for 2.3?) |
| |
(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/
| |