On Sunday 15 July 2007, Kel Modderman wrote: > On Sun, 15 Jul 2007 09:00:44 am Neil Williams wrote: > > On Sun, 15 Jul 2007 00:31:29 +0200 > > > > Christoph Haas <[EMAIL PROTECTED]> wrote: > > > On Sat, Jul 14, 2007 at 10:42:52PM +0100, Neil Williams wrote: > > > > Is this a result of the need to allow repeated uploads of packages at > > > > the same version? > > > > > > Actually I don't like the idea of uploading a different file with the > > > same revision number. But a lot of sponsors seem to expect a > > > ~mentors001 revision suffix or just always a "-1" revision until the > > > package is sponsored. When I sponsor packages I always make my > > > sponsorees use proper revision numbers. Who cares if it takes 10 > > > revisions until the package is ready for upload? Let it be revision > > > "-10" then. At least I don't need to know that the sponsoree meant "the > > > version from yesterday evening 7 p.m. CET-4" but rather use revision > > > "-4". I found it educationally better to handle mentors.debian.net just > > > like the usual ftp-master: > > > - once uploaded the orig tarball can't be altered any more > > > - new uploads are only valid with higher version/revision numbers > > > > I'm coming around to that way of doing things, I must say. > > > > :-) > > > > Aligning m.d.n with ftp-master can't really be a bad thing - the fewer > > surprises I get, the easier it is to sponsor. > > > > AFAICT the habit of keeping the same version during sponsorship comes > > down to "the package hasn't been uploaded to Debian / is not available > > to users so why change the version". Personally, I'm beginning to think > > that this is spurious. Lots of upstream packages move from 0.1 to 0.6 > > and there is no particular reason why all debian versions must be > > sequential - gaps are perfectly acceptable. If sponsors choose to > > create gaps during sponsoring and then use -sa as necessary, is there > > really a problem with that? > > IMHO, that shows that the potential sponsoree is competent at updating the > changelog to deal with reported bugs and the (s)he becomes familiar with > tools like debchange(1). Possibly the most important skill a maintainer > could possess, second to having the ability to actually fix reported bugs. > > If a potential sponsor refuses any package because the changelog has been > updated for _every_ change (even for developmental changes, even for first > upload to debian) then i would say that is poor form, because those are bad > developmental habits to teach. > > "the package hasn't been uploaded to Debian / is not available to users so > why change the version" is purely aesthetic sentiment. Please don't let > that compromise the historical and technical merits of any package.
True. The sad part is that such aesthetic sentiments fly directly in the face of the technical correctness. Why should a potential package user/reviewer/whatever check/review once again the "-1" version of the source package when its changelog keep reading "Initial release (closes: #number)". Also there is no information what has been changed (or corrected) and why certain decisions have been made in the past. Having multiple "-1" versions floating around doesn't help communication, nor upgrading from previous "-1". I believe in the simple, but efficient rule => if your package has already gone public, never kill its changelog history. > I would hope that bumping changelog revisions with detailed descriptions of > each and every change be actively encouraged. This assists the maintainer > in his/her learning of skills, and allows them to keep history of what > problems they have encountered before and how they solved the problem. Correct, this is how uploading to official archive works. -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
