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

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

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

> > > For cases where the maintainer is unresponsive for an extended period, I'd
> > > recommend requesting a new version via a 'wishlist' bug, then releasing a
> > > new version as a -0.1 NMU.  Others (myself included) have done this
> > > successfully.
> >
> > I opened the wishlist bug entry for that (#723781) in September and
> > agree, that uploading a -0.1 NMU would solve the issue of the new
> > upstream version.
> When I last did this in #728545 for mumble, the situation was rather serious 
> because it had been removed from jessie due to package dependency issues and 
> needed to get fixed ASAP.  So I opened a wishlist bug, then waited about a 
> week, then uploaded a package for review to mentors.debian.net and started 
> hunting for a DD sponsor.
> I contacted the prior maintainer, who examined the package and decided it was 
> good enough and uploaded it to the DELAYED/5 queue.  Then I wrote to the bug 
> to notify the maintainer in case he needed more time to respond and review the 
> package if needed.
>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728545
> I didn't change the packaging style in doing this, but just about everything 
> else did.  ;-)  Obviously I was willing to support the package if there were 
> problems brought by my sponsored upload, and as long as you keep this in mind 
> as well then I think this practice should work.

I think its okay for stunnel to simply follow the steps described in
the MIA section of the developers reference [0].

> > 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.

> So NMUs can solve things in the short-term, but between NMUs and "where to go 
> from there" is still a limbo I haven't yet gotten good answers for.  There's 
> been a lot of debate on [debian-devel] about this and NMUs are generally one 
> of the answers, but there are situations that don't quite fit any standard 
> situation.  Like for instance a maintainer might be MIA but ignoring one 
> particular package for a long period of time, thus the MIA team can't say that 
> the maintainer is really MIA, yet the package isn't getting maintenance, and 
> thus no next logical step to take.  That's why I'm suggesting that adding 
> one's self to Uploaders after some number of NMUs seems to make sense.  :-/  
> Again not necessarily right, just "the least worst" next step I can think of.

If the maintainer is still working on some packages he should be
contactable. Thus one can simply ask the maintainer if he/she wants
to give the package to another maintainer or get a co-maintainer.

[0] https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

-- Sebastian

Attachment: signature.asc
Description: Digital signature

Reply to: