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

Re: Broken uploads to mentors.debian.net



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 <haas@debian.org> 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 



Reply to: