On 24 February 2016 at 20:29, Duncan <[email protected]> wrote: > I guess another way of putting it in the context of changelogs, would be > that if gentoo were using git merges correctly, a changelog summary > generator could simply take the high-level merge summary comments and > turn that into its changelog summary. Instead of ten dozen individual > "cat-egory/pkg-x.y.z arm-stable" entries, there'd be one or two "arm- > stable various packages in these categories: xxx, yyy, zzz, aaa" entries, > and people who don't care about arm could skip the further detail while > still getting an overall idea of arm activity, while those who do care > about arm and want further information could drill down further as > necessary, but would be able to skip the corresponding merge entries for > x86 and amd64. > > With proper git usage, the information would already be there in the git > log merge commit comments for people like me who like to read those, but > it would also be not only far simpler, but actually /possible/ to > automate a summarizer that generates summaries from only those merge > entries, that then could be stored in the rsync tree or published to > packages.gentoo.org or the gentoo front page, or wherever.
Indeed, we could probably establish better conventions for identifying certain kinds of commits such that a static log analyser would be able to give a good result. And you can probably trivially filter out ( or in your case, filter exclusively for ) changes that relate to a specific arch simply by examining the "DIFF" data. And we could probably to much better at formatting merge commits as well ( I've been encouraging such a thing already because "merged branch x/y/z" is not informative enough ) "Good" changelog automation pretty much relies on the quality of the underling data and the ability to identify commits that are to be included/excluded smartly, and pick the data out of those commits that are relevant. Though personally I feel for the goal of stabilization tracking, you aught to be analysing the git repo. Not only can you then see when a given package was stabilised, but you can see the other packages that were stabilized in its proximity, which is way too hard to do with the Changelogs. -- Kent KENTNL - https://metacpan.org/author/KENTNL
