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

Re: Best practices for changelogs

On Nov 18, 2007 2:46 PM, Gerfried Fuchs <rhonda@deb.at> wrote:
> * Andres Mejia <mcitadel@gmail.com> [2007-11-14 23:27:39 CET]:
> > 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.
>  If something gets changed it should be uploaded/offered again anyway? I
> can't follow you. And besides the pain for large packages - it does
> require only a reupload of the diff.gz, not the .orig.tar.gz, or would
> it? If mentors.d.n doesn't work without uploading the .orig.tar.gz it is
> seriously b0rked IMHO and people should just upload to some other
> website they have access too.

Last I checked, mentors.d.n doesn't allow you to upload without the
orig.tar.gz, even if you have uploaded the tarball already.

> > 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.
>  Erm, it isn't. The changelog contains informations about closed bugs,
> for a start, which is immensly useful informations for users. Calling
> the changelog irrelevant to a user is pretty blindfolded.

When I said this, I was thinking about the end user of a program that
doesn't particularly care about how it's packaged, they only care if
it works. I'm sure these kind of users exist. The changelog is of
course useful for a lot of things and for a lot of users.

In any case, this debate will probably need nowhere just like it did
at debian-mentors (I take back my earlier comment about a general
consensus). I'll continue to increment the changelog after each upload
cycle to mentors.d.n and I'll inform anyone who's sponsoring
accordingly. For one, because it's easy to use the proper
dpkg-buildpackage options, both for maintainers and for sponsors, and
two, because I think it's easier to find changes after each upload
this way (sponsors can diff the diff for instance).

Of course now I'll also try to upload an acceptable package the first time.

Andres Mejia

Reply to: