Bug 99522 – A Standard For More Detail In EBuild Changelogs

• Product: Portage Development
• Status: RESOLVED WORKSFORME

[Description Tim Redman 2005-07-19 06:51:38 UTC]

Is there any kind of standard for changelogs on ebuilds?  More times than not, I
see a new package that has simply incremented the -r# on the ebuild, which tends
to imply that there was a change in the ebuild itself (or maybe the addition of
new Gentoo or other community patches/enhancements) rather than the package. 
These changelogs tend to be very, very terse much of the time.

What I'm proposing is a discussion and implementation of "best practices" on
changelog entries.  One of the things I'm talking about can be seen in the log
for mozilla-firefox-bin:

 18 Jul 2005; Aron Griffis <[e-mail]>
mozilla-firefox-bin-1.0.5-r1.ebuild:
Update dependency to mozilla-launcher-1.35 to help with #99084

This is what I would consider at the very least a minimum standard to adhere to,
since there is a bug report referenced that gives a full reason why the upgrade
was made.  Many other packages just update the -r# by saying that it was moved
to stable on some architecture.  What would be nice would be a reference to a
bug report or forum article that discussed what had been done to bring it to
that point.

This could also be useful for packages that have been soft or hard masked as
unstable.  It could include contact information for the maintainer and
references to a current discussion on the testing of the product, so that the
typical beta-tester would know exactly who to submit problems to, and would also
know any outstanding issues that need to be corrected and focused on.  I realize
that the "changes" function of equery is not implemented in the current stable
version of equery, and more detail in the changelogs would make that future
functionality very useful for stable users and testers alike.

This boils down to being one of those tedious "janitor"-style modifications. 
It's not sexy, but for accountability and reliability purposes, I feel it is
probably lacking from the current process.

Reproducible: Sometimes
Steps to Reproduce:
1.
2.
3.

[Comment 1 SpanKY 2005-07-19 06:59:40 UTC]

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2#doc_chap3

[Comment 2 Tim Redman 2005-07-19 10:47:03 UTC]

(In reply to comment #1)
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2#doc_chap3

Thanks, SpanKY.  In a true example of brilliance in motion, it never occurred to
me to look there.  Monday must be flowing over into Tuesday.