[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Best practices for changelogs

(I was wondering where in the thread I should reply, so as to limit the
number of answers, and it looks like this is here.)

Simon Ruggier <simon80@gmail.com> (14/11/2007):
> On 11/14/07, Andres Mejia <mcitadel@gmail.com> wrote:
> > The problem with this is that only the maintainer/uploaders is
> > suppose to change anything with the package. Doing this requires the
> > maintainer/uploaders uploading the package again. This would be a
> > pain for those maintaining large packages like alien-arena-data or
> > warsow-data.
> I don't think that it's a problem for the sponsor to modify the
> version in this way if it has been requested by the maintainer.  Also,
> as long as the upstream tarball hasn't been modified, the maintainer
> can choose to exclude the orig tarball by adding the -sd flag to
> dpkg-buildpackage.

Removing a “~rfsN” and uploading sounds very acceptable to me. Mentors
should (or could) provide with a way to deal with successive uploads
without requiring any version increment in the changelogs.

> > The changelog would contain only details about the packaging, so the
> > information in a debian/changelog would most likely be irrelevant to
> > a user anyway.
> I strongly disagree that it isn't relevant to users.  The changelog is
> exposed in various package management tools, and the policy requires
> that it is always installed along with the package.  I myself often
> read the changelog of updated packages to see what was changed between
> debian revisions.

I fully agree with Simon here too. I'd like to add that not having
additional not-uploaded changelog entries really help the job of people
doing version-tracking of RC bugs, tagging them accordingly, searching
for needed binNMUs and so on.

Really, changelogs aren't just about users.


Cyril Brulebois

Attachment: pgph1cgleNJGy.pgp
Description: PGP signature

Reply to: