On May 16, 2013, at 1:30 PM, Christian Stimming <christ...@cstimming.de> wrote:
> Am Donnerstag, 16. Mai 2013, 12:53:16 schrieb John Ralls: >> On May 16, 2013, at 12:35 PM, Mike Alexander <m...@umich.edu> wrote: >>> --On May 16, 2013 11:42:39 AM -0700 John Ralls <jra...@ceridwen.us> wrote: >>>>> These questions are not criticisms, but really intended to stimulate >>>>> us to review or current ChangeLog process. Is it still ok or time >>>>> to improve ? >>>> >>>> I'll go further: It makes far more sense for release tarballs to just >>>> have a digest of important changes in NEWS. We might have to fiddle >>>> autogen.sh to not whine about ChangeLog if we delete it, but let's do >>>> it. The whole ChangeLog thing comes from a time long ago when version >>>> control systems didn't have good logging. ChangeLog was where commit >>>> messages went. It's totally redundant nowadays. >>> >>> I like something between these two extremes. My personal model for the >>> best way to handle changelogs is BBEdit [1] from Barebones, although >>> doing it the way they do will take someone some time. They manually >>> list all significant changes in a release with a very short summary >>> (sometimes humorous) of each change. I don't know, but I suspect that >>> these are entered when someone checks in a change or closes a bug >>> report rather than all at once at release time. I like this because it >>> quickly tells me what's new and whether the bug that has been annoying >>> me is fixed.> >>> Mike >>> >>> [1] <http://www.barebones.com/support/bbedit/arch_bbedit1053.html> >> >> That looks like a digest: It's missing all of the "oops" commits that show >> up in a raw log. I usually do something similar in NEWS when I do a >> release, except that I separate design changes and bug fixes into separate >> sections. That follows a pattern of NEWS files I found when I started doing >> releases last year. > > When we set up the ChangeLog generation a few years ago, we noticed that the > NEWS entries took quite some amount of work to be written together. The basic > problem is always that it takes manual work to summarize the bunch of commits > that belong together into single summary entries. At the time we said we'd > give up on this work and simply list all commits from the SVN log. > Unfortunately I still don't see a better solution at hand that doesn't > require > a lot of manual work. Either we list everything, or someone needs to write a > list manually... If anyone (John?) volunteers to do the manual writing for > some time to come, that's fine and we should do that. But if there's nobody > volunteering for the manual list, I'd just stick to the automatic ChangeLog > for the releases and that's it. > > Oh, and yes, it's purely meant for the release tarballs. There's no point for > those logs in anything except the released source tarballs. (And I don't care > if we change the format - any format is just fine.) Less work is better, particularly when it comes to releases, but we need to write a release summary for the "news" item on the website anyway. The NEWS file is usually that plus a list of fixed bugs and a list of new or updated translations. A VCS log dump is pretty noisy in comparison, and will be more so as we get into the git way of making lots of small changes. On the other hand, if we also get in the git habit of doing nothing directly in trunk/master and merging instead of rebasing, then merge commit messages can have a nice summary that can go directly into news. Add a common notation for bug fixes and translations to a perl script and the amount of manual work at release time can bet pretty small. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
