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