It's not useful for users to see messages like "old" or "rm" or "remove old", so echangelog shouldn't log removals by default.
But there should be a special parameter to include removals in ChangeLog for cases when it's useful, for example, like when last stable version was removed.
i tend to disagree. if you dont want echangelog to include those things, then dont use echangelog when making that commit.
(In reply to comment #1)
> i tend to disagree. if you dont want echangelog to include those things, then
> dont use echangelog when making that commit.
well I agree with you. parameter to ignore removals works just as fine for me.
I don't think this feature is even needed as our policy requires to document all changes but typos and comments. Until policy Changes this bug is really wontfix.
But it's always possible to improve situation. I guess it's good idea to update ChangeLog format to be more terse. E.g.:
29 Apr 2011; Kacper Kowalik <email@example.com> transmission-2.13.ebuild:
ppc stable wrt #361305
Could be written in one line if we drop:
1. name - dev's uid is nickname so it's not necessary to repeat name every time
3. .ebuild suffix is redundant too
Then it's possible to have this message (and lot's of similar messages) in one line:
29 Apr 2011; xarthisius transmission-2.13: ppc stable wrt #361305
Also redundant empty lines could be dropped too.
devmanual requires all non-trivial changes to be documented in ChangeLog so as longs as that policy is in place this should not be done.
(In reply to comment #4)
> devmanual requires all non-trivial changes to be documented in ChangeLog so as
> longs as that policy is in place this should not be done.
Removing an unused ebuild is not the same as changing an ebuild. We have no policy for logging removals, and that's how it should be.
(In reply to comment #5)
> Removing an unused ebuild is not the same as changing an ebuild.
If ebuild was man, then removal means death, and really such change is quite drastic change for all who are still alive ;)
not really. echangelog options are independent of policy. if you want to talk policy, go to g-dev ml. plus, people can easily use echangelog on trees other than gentoo-x86 where gentoo-x86 policy obviously has no bearing.