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

Re: Add support for XMLRPC v31 in Pianobar



[not sure if you're subscribed, so explicitly CCed]

On Tue, 2011-08-16 at 16:10 -0400, Luke Faraone wrote:
> On Tue, Aug 16, 2011 at 15:59, Adam D. Barratt <adam@adam-barratt.org.uk> wrote:
> > Apologies if I'm missing something but you say "only API keys needed to
> > be updated", but the diff doesn't appear to include any such changes.
> >
> > (Aside from which, an enforced API bump for a field which currently has
> > no purpose seems somewhat silly)
> 
> No, you're not. I was thinking of the previous API bump, v30. My mind
> must be going.

Okay. :-)

> >> A patch is attached
> >> which includes all changes which would need to be made.
> >
> > Out of interest, why does the changelog only mention the Launchpad bug,
> > not the corresponding entry in the Debian BTS - particularly given that
> > the upload to unstable included both?
> 
> I added the BTS reference after making the diff, but then did not
> remake the diff.

Okay.  The rest of the diff looks okay, so I've marked the package for
acceptance at the next dinstall; thanks.

> Out of curiosity, is it generally preferred to ask before uploading?

Yes.  I'm fairly sure all of the documentation regarding stable updates
indicates this; if it doesn't, it should.

> If an upload is made in error or needs additional work, it can always
> be removed from the queue, no?

It can, but only by waiting for a dinstall cycle and then clearing out
various internal state used by the tools which generate
http://release.debian.org/proposed-updates/stable.html , for example.
(Otherwise the debdiff will be for the previous upload, as will the
installability check logs).

Particularly for packages which take a while for the maintainer to build
and/or test, the time difference between a proposal->comment->rework
cycle and an upload->reject->upload cycle can be quite significant.

Regards,

Adam


Reply to: