At 04:29 PM 6/26/98 +0100, Kyle Jones wrote: Agree 100%. The beauty of CVS is completely trashed if you don't know what happened. I have tracked down many bugs as Kyle describes both in XEmacs and on commercial projects that I work on. As an example we were close to shipping a software release of something when dialog input boxes stopped working. By looking at the code you couldn't tell what was wrong but by finding the change (a one-liner on the face of it purely cosmetic) it became evident. I believe that sometimes its the small changes for which information is more important. Agree 100%. I don't think patches should be rejected for not having changelogs but I certainly don't think we should change policy from changelogs being requested for all patches. andy --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

mb> Scenario: J. Random Luser has been lurking on xemacs-beta and mb> comes up with his first patch to XEmacs. Here it is: mb> -# Define HAVE_MSW_C_DIRED to be non-zero if you want Xemacs to use C mb> +# Define HAVE_MSW_C_DIRED to be non-zero if you want XEmacs to use C mb> Now, this patch is not rocket science, but it IS a mb> contribution. JRL doesn't know or care about ChangeLogs, so mb> doesn't provide one. If s/he knows about xemacs-patches and so is presumably on xemacs-beta, this seems unlikely. If s/he's new to xemacs-beta and submits a patch there, or whatever, then it has to be handled by hand anyway and the maintainer should use his/her judgement. mb> Question 1: Does adding a ChangeLog for this change actually mb> make XEmacs better? mb> 1998-06-26 J. Random Luser <jrl(a)xemacs.org&gt; mb> * nt/xemacs.mak: Changed Xemacs -> XEmacs mb> I claim not. If you agree, vote NO. That's because the ChangeLog should read: * nt/xemacs.mak: Fixed typo(s) in comment(s). IMO, these really miniscule changes shouldn't be omitted from the ChangeLog, but they should have generic descriptions. If the generic descriptions are consistently used, they can be aggregated or eliminated automatically, according to maintainer preference. If that's the only ChangeLog for that version, then I don't bother to `cvs diff' against it to see if that's where the change that's bugging me was introduced. This is very weak, of course, but I personally do prefer to see even comment typo corrections in the ChangeLogs. I will submit such. If the relevant maintainer disagrees with me, of course s/he is free to not use my ChangeLog entry, and I won't complain. I agree that such entries are to a great extent noise, and would not be terribly upset to see them go. But mostly I grep ChangeLogs, not read them, so I don't see such noise. And when something as big as the package searching algorithm gets entries like "Search stuff reimplemented",[1] something is awry, and I think we should err on the side of strictness. mb> Question 2: mb> Maintainer to JRL: Could you add a ChangeLog for that change? It shouldn't be the maintainer, it should be the patchbot. Personally, I would appreciate being notified of missing ChangeLogs by the patchbot; I often forget them, and would prefer not to waste maintainer time on requests to do something I shoulda done myself. mb> Did we just lose an XEmacs contributor? Not if it was the patchbot, I don't think so. Especially if the patchbot provides a (short) list of generic ChangeLog entries, and suggests that using one if appropriate will speed the approval process. A sufficiently smart patchbot could pre-approve patches that only change comments and strings and the like. I'm not entirely joking, but it would take huge effort to write such a thing well. So it's probably not worth doing, given that a fair number of strings are executable (ie, they get passed to shells or whatever), and have to be checked anyway. mb> My feeling is that ChangeLogs are a good thing, for MOST BUT mb> NOT ALL changes, and that contributions should not be mb> categorically turned down due to lack of ChangeLogs. I think mb> this is just Common Sense. I don't think they should be categorically turned down. But a request for a ChangeLog, or getting stuffed into a `pending' queue, is not a categorical refusal. mb> I currently have submitted patches that have not been applied mb> due to lack of ChangeLog. These are the kind of changes that mb> don't deserve a ChangeLog, i.e. adding ChangeLog entriess mb> would make XEmacs LESS maintainable. If the yes votes win, Um, if they're so unimportant that the ChangeLog entry _should_ be omitted, what harm in sitting in the pending queue until 21.1? I see this as an argument _for_ entries for them, so that they can be approved essentially without thought by the maintainer. In fact, if the contributor is trusted (eg, another maintainer), it might not be impractical to preapprove patches based on a generic ChangeLog. mb> the likelihood that I will be contributing in the future will mb> drop significantly. The question is not whether ChangeLogs mb> are a Good Thing, but whether ALL changes must be accompanied mb> by ChangeLogs. Lars> What I've started doing lately with Gnus patches that I get Lars> is including a standard response at the end of the aqc of Lars> patches that are ChangeLog-less saying something like "In Lars> the future, could you include ChangeLog entries?", and then Lars> I write the ChangeLog entries myself. IMO this is very polite, but an unfair burden on pro-ChangeLog maintainers. The maintainers should not have to do the scutwork of requesting a ChangeLog if they don't want to. Furthermore, if it's done automatically by the patchbot, nobody's feelings are hurt. I guess I'm suggesting that the patchbot should file ChangeLog-less patches as pending ChangeLog, check for the contributor's membership in a "recalcitrant developer" (Steve's term, not mine) list, and if not request a ChangeLog from the contributor. Maintainers with free time would of course be free to check the pending queue if they like. Setting this up is a burden on the patchbot maintainer (coordinating `pending' patches with resubmitted ChangeLogs looks to be a hairy problem) but would only have to be done once. This should address Martin's preference, except that his patches would still end up in a `pending ChangeLog' queue. I guess those could be directed to the "to apply" queue if the appropriate maintainer agrees. Footnotes: [1] Especially since it is not documented elsewhere yet AFAIK. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091