Hey, On Fri, 2006-01-06 at 09:34 -0500, James Carlson wrote: > I still think it looks rather cheesy. First of all, there's the plain > old clutter problem. I wasn't thrilled with the excess of the CDDL > language (the original two-line copyright notice, though slightly > annoying, was comparatively short and sweet), but a long list of > "brought to you by" attributions would just be downright obnoxious.
Hrm, I don't think it's hugely obnoxious seeing one or two people in some sort of Authors section - in fact I think it's pretty helpful to see where the original motivation came from. I'm certainly not suggesting having 100's and 100's of people. But then this is probably not 95% of the contributions will be. > When I read the code, I want to see descriptions of how it works and > the assumptions it makes, not someone's CB handle, favorite pet, or > obscure quasi-political manifesto. There are times and places for all > those things, but the source to an operating system isn't one of them. > (Suggestion: write a book instead. ;-}) No disagreement there. However, interestingly, it does create some sense of the fact that there are real people actually writing this code. May not be useful to the code, or desireable, but it does have certain merits in a different light. > I think of this as being similar to littering the code with "#ifdef > notyet", "/* XXX broken */", "/* bugid 1234 */", or "/* [EMAIL PROTECTED] > changed this to 7 */" trash. If it's not known to be right and isn't > actually used in the running system, yank it out. It doesn't belong. Hrm, again I probably disagree with some of that - where things are known to be broken, it's a useful reminder. And goodness knows we all commit code that we know breaks for certain edge cases due to time constraints, laziness or other conditions. I believe having those reminders in the code is definitely better than lost in some putback logs, IMHO. > I'd much rather have putback logs (which show bugs fixed and files > changed in a given build), SCCS history (which shows who touched which > line in a given file for a given change), and a bug database (which > contains all the sordid history for a given bug, including how it was > evaluated, what problems might be related, and so on). The big > failing of that ChangeLog mechanism is that it's both too wordy to be > digested easily when hunting down a problem *and* too terse to explain > what happened. Within GNOME, usually the ChangeLog is a copy of the commit message. ChangeLog may be a result of an inefficiency of CVS though - in that it's not easy to track an individual commit over a number of files. With the ChangeLog you can see what files have been changed, and consequently go off to check the logs of those files if necessary. It may also be in the inefficiency of CVS of not being able to look up logs off line. > > Also remember that not everyone will initially have an account to commit > > their work. > > That (and open access to the SCCS delta information) is the part that > really needs to be fixed. I don't think we should try to hack around > the missing parts. Yeah, agreed - that may be more desireable. Glynn _______________________________________________ opensolaris-discuss mailing list [email protected]
