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

Re: [Backports-queue] Processing of qemu-kvm_0.11.1+dfsg-1~bpo50+1_amd64.changes



* Andres Salomon <dilinger@queued.net> [2010-03-18 18:52:17 CET]:
> > > Contacting the former uploader is on bpo's best practices but it's
> > > on a strict rule of bpo, is it? Not that it's a bad idea, it's just
> > > not always very practical.
> 
> I'd love to see this formalized as a strict rule.  Say, a formal
> requirement would be to email the uploader (using the email address
> listed in the upload), and if there's no response within 30 days,
> permission is implicitly granted to maintain the backport.

 I still wonder why this would be needed. Do we have it as strict rule
for regular Debian uploads too? Actually I fail to see the big
difference in this respect and why people should see it differently. If
it is actually needed to get it strictly written out it should be in the
developer's reference - and the backports documentation might refer to
that.

 Having said that:
,------------------> quoting developer's reference <------------------
| It is not OK to simply take over a package that you feel is neglected —
| that would be package hijacking. You can, of course, contact the current
| maintainer and ask them if you may take over the package. If you have
| reason to believe a maintainer has gone AWOL (absent without leave), see
| Section 7.4, “Dealing with inactive and/or unreachable maintainers”. 
`------------------> quoting developer's reference <------------------
<http://www.debian.org/doc/manuals/developers-reference/pkgs.html#adopting>

 That paragraph is quite exactly the formalized strict rule you would
have hoped for, and it is the one that should be taken into account for
backports, too.

> I'm coming at this from the perspective of someone who'd be more than
> happy for someone to take over some my backports (especially the ones
> that were simply build dependencies, such as pulseaudio).

 On a side note, I am offering all my backports (and also regular
packaging) currently too (at least for co-maintenance) because of
upcoming time constraints. Thanks to Jan Wagner for already having
picked up pidgin.

 Have fun,
Rhonda

Reply to: