Leaving off the MIA team on this reply, mainly because I don't think this is "news" to them per se and I'd rather not "spam" them.
On Friday, February 07, 2014 02:54:09 Sebastian Reichel wrote:
> On Thu, Feb 06, 2014 at 06:56:04PM -0500, Chris Knadle wrote:
> > I know; I agree with you and I think the text is a bit misleading -- by
> > stating that you shouldn't change the packaging style it seems to indicate
> > that NMUs are supposed to be minimalistic, but a situation in which the
> > maintainer of a package disappears for an extended period is exactly a
> > situation in which a minimalistic change approach won't work.
>
> Right. So just take over the package and do normal uploads? By
> uploading normal changes as NMU this is what you effectively do
> anyways.
Well, here's the typical scenario:
- maintainer stops maintaining a package, for whatever reason,
and doesn't respond to communication... for a long time.
- things change, the package you use that the maintainer had previously
maintains breaks, or gets very old compared to upstream that
compatibility issues arise.
What are your options? Without doing some kind of new upload, the package is
in trouble. By doing a new upload, like the maintainer would normally have
done, you're /helping the maintainer/ as much as you're helping yourself.
To do anything else would mean everyone using the package living with some
kind of brokenness in it, because you're perpetually "on hold" hoping the
maintainer returns, and he/she might not.
That, unfortunately, happens.
Waiting, say, six months for the MIA process to complete so that you can take
over a package really doesn't make sense if the next Stable release is going
to be frozen within that timeframe and the package may get dropped for being
ancient, if the package has fallen out of Testing because of dependency
issues, if there are security or other RC bugs... and so on. Whether or not
you can wait depends on the situation.
[...]
> I think its okay for stunnel to simply follow the steps described in
> the MIA section of the developers reference [0].
Sure -- there's nothing wrong with trying that. The idea is simply to find
some avenue that works, whatever it is, and for that avenue to be as
reasonable as possible for all parties.
> > > OTOH having an active maintainer is more helpful than lots of NMUs
> > > IMHO. Thus it makes more sense to take over packages or add at least
> > > add a Co-Maintianer for this.
> >
> > Right, exactly. But to start with you may not want to do that; the
> > maintainer normally gives approval for adding a co-maintainer. After
> > you've done several NMU uploads and tried to contact the maintainer via
> > the MIA team, then after that I think the next logical step I think is to
> > add one's self onto the list of Uploaders... basically only because I
> > know of no better option rather than that being "the right thing to do".
> > Because it's not reasonable to be expected to do minimalistic changes for
> > long periods of time.
>
> The MIA team can orphan packages if the maintainer is MIA, see [0].
> Having a ghost-maintainer doing NMUs while the maintainer is MIA
> feels wrong to me.
There are situations in which the maintainer is /not/ MIA overall, but seems
to be ignoring a particular package. Let me know what you think is reasonable
to do in that case.
The philosophy I've heard and am going by is the "Debian do-ocracy" --
(quoting one of Stefano Zacchiroli's talks [0]):
"An individual Developer may make any technical or nontechnical
decision with regard to their own work;
[ Debian Constitution, ยง3.3.1.1 ]"
The extension of this is that in lieu of the maintainer doing the work he/she
would normally do but now isn't, your work should not be impeded perpetually
as a result. It therefore seems reasonable to do the necessary work yourself,
trying to take the maintainer's wishes into account at the same time.
In these situations it is obviously best if the maintainer knew ahead of time
that they'd not be maintaining the package anymore and orphan it such that
another maintainer can do so, but that doesn't always happen.
[0] http://upsilon.cc/~zack/talks/2011/20110321-taipei.pdf
Also -- disclaimer -- this view I have is not without controversy, and I am
not a DD, nor a DM. I got into packaging work out of necessity because of
package breakage, and so NMUs are a central part of what I currently do.
With them I have a path to fix issues with Debian package via sponsored
uploads, without them I'm simply on hold waiting until the maintainer decides
to show up with a new package -- and I think waiting 17 months was enough.
What I'm doing here is offering suggestions -- avenues of possible choices --
/not/ trying to tell you what to do or "what you should do". How you decide
to proceed is up to you and depends on how desperate you are to have the
package you care about functional again, your relationship with the
maintainer, your experience in Debian, and everything in-between.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: This is a digitally signed message part.
