On Wednesday, April 18, 2012 04:57:14, Thomas Goirand wrote: > On 04/18/2012 08:27 AM, Steve McIntyre wrote: > > If a maintainer isn't (capable of) doing the necessary work on a > > package themselves, then after a while the best thing they can do is > > admit that and cede control to others. It's not an easy thing to admit > > "failure" like this, but it's better to do it for the good of our > > users and other developers than to continue blocking people. It's also > > better for the developer involved to get away from the feelings of > > guilt they may be having about not keeping up. There's no shame in > > admitting a lack of time on a big volunteer project, we all understand > > how this works... > > This isn't aimed at the WINE maintainers (I didn't read the bug report, > and I don't really care about this package) but... > > what can we do if the maintainer doesn't admit his lack of time or his > lack of skills/knowledge? My understanding is that in Debian, we are > stuck, right? I believe that was the message of Chris: we don't really > have procedures to take over a package, others than convincing the > maintainer. Debian has NMUs (Non-Maintainer Uploads) -- however this is mainly meant for uploading critical bug fixes without having to resort to hijacking the package, and AFAIK not to be used to upload new versions of the software. Hijacking the package is meant for when the maintainer is completely MIA. Referring to the Technical Committee is meant for when there is some kind of irreconcilable dispute, AFAIK. But what I'm seeing is that there are "in-between" states, where there doesn't seem to be any correct action to take. If a maintainer is not completely MIA but is going to not have any time for maintainership for 6 months, and several people are asking for the package to contain a newer version of the software rather than something 3 years old before the upcoming freeze -- what can one do? I think the current answer unentiontially ends up being some version of "get used to dissappointment"... so I'm asking the question in the hope of figuring out a better answer. -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Description: This is a digitally signed message part.