| 1 |
On 24 February 2016 at 17:24, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> Particularly when the basic changelog information is there, it's simply |
| 3 |
> quibbling about chronological or reverse-chronological order we're doing |
| 4 |
> now, and people who /really/ care about it by rights should be going |
| 5 |
> straight to the git logs in the first place. |
| 6 |
|
| 7 |
|
| 8 |
Gentoo actually make this problem worse than it should be. |
| 9 |
|
| 10 |
Most of the suffering with having Changelogs in tree is due to the |
| 11 |
whole "Every commit must have a changelog entry" madness, and the |
| 12 |
natural consequences of having a lot of those leads to lots of merge |
| 13 |
collision. |
| 14 |
|
| 15 |
By comparison, in other places ( for example, CPAN ), having a dumb |
| 16 |
git -> changelog mapping tends to be right up there on the list of |
| 17 |
dumb ideas, and the natural response I have ( and most CPAN hackers |
| 18 |
have ) upon seeing a git output based changelog is typically "close |
| 19 |
page, assume there was no changes". |
| 20 |
|
| 21 |
Like from a changelog perspective, I don't think anyone cares about |
| 22 |
stabilization changes. |
| 23 |
|
| 24 |
Its either stabilized, or it isn't, change logs indicating you tweaked |
| 25 |
a flag tends to not be the sort of thing people go looking at |
| 26 |
Changelogs for. |
| 27 |
|
| 28 |
If you want granular, commit-by-commit details about what changed, |
| 29 |
yes, Git _is_ the right option for that. |
| 30 |
|
| 31 |
But having that level of detail in the changelog is itself the madness |
| 32 |
we should avoid. |
| 33 |
|
| 34 |
Changelogs are really supposed to be _for humans_ giving changes that |
| 35 |
_humans_ will care about. |
| 36 |
|
| 37 |
Like on Published Open Source software, things you tend to look at the |
| 38 |
changelog for is: |
| 39 |
- What are the new features in this new version |
| 40 |
- What bugs were fixed in this new version |
| 41 |
- What security concerns were resolved by this new version. |
| 42 |
|
| 43 |
The point being "If I just look at the diff directly I might not |
| 44 |
understand what is happening" |
| 45 |
|
| 46 |
And that's why there's the convention of being recent-first. |
| 47 |
|
| 48 |
Because you open the changelog at the top, and you read down consuming |
| 49 |
the aggregate changes of relevance to you mentally, and then you stop |
| 50 |
when you reach a version you've already seen. |
| 51 |
|
| 52 |
A big log of "Stabilized X" is just ... a waste of time IME. |
| 53 |
|
| 54 |
But I'm sure at least one person out there has probably gone looking |
| 55 |
for a changelog to see when something got stabilized/keyworded. |
| 56 |
|
| 57 |
If we released ourselves from this inanity of annotating every change |
| 58 |
at a level beyond which normal people could care about, we could |
| 59 |
probably get away with manually maintained Changelogs again. |
| 60 |
|
| 61 |
Because not *every* change warrants telling an end user "Hey, we changed this". |
| 62 |
|
| 63 |
-- |
| 64 |
Kent |
| 65 |
|
| 66 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives