(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. Cheers, -- Cyril Brulebois
Attachment:
pgpVLFPgM8QoL.pgp
Description: PGP signature