Re: Broken uploads to mentors.debian.net
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.
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.
Thanks, Kel.
Reply to: