Re: Volunteer-initiated team maintenance as a solution for packages with low activity
On Wed, Apr 18, 2012 at 2:12 PM, Moray Allan wrote:
> On Wed, 2012-04-18 at 13:10 -0400, Michael Gilbert wrote:
>> So anyway, enough explanation, on to my proposed solution. Seeing as
>> team spirit has been a quite effective antidote to stagnation, lets go
>> ahead and use that again.
> I agree with the general intention, but not with the details of the
> proposed process. Indeed, I'm unconvinced we need to formulate a
> process of any kind, especially not one that makes a specific group (in
> this case, the Alioth admins) responsible for policing it. I would
> rather simply see a stronger consensus on what is reasonable behaviour.
So I failed to state this, but implicit in the goals is that the new
volunteer's work should be readily available in a user-friendly form
to the existing maintainer for when/if they return from their low
I'm reluctant to do a 500 commit NMU because its just so unwieldy (and
seems wrong), but if I can become a team member and commit those
changes to the vcs, then its in a nice form for the maintainer when
they return. Plus I don't have to find hosting for my work elsewhere,
which is kind of a pain and unwanted.
So, currently the only way to add a new alioth project in cases where
the maintainer does not do it him or herself is via the alioth admins,
so that is why they have to be involved. In most cases it will be a
quick check on their part to see that the package needs help.
All-in-all these cases should be rather rare, and should not require
much work on their part. But if it does, more admins can be added to
distribute the workload.
Note that the collab-maint case requires no oversight (alioth or otherwise).
> If we need a process at all, I would initially suggest something like
> the following, which I think would be enough to solve many cases:
> - Where there are problems with a package that are not being dealt with
> by the maintainer, it is acceptable for others to NMU. This includes
> when a package is significantly out of date compared to upstream, though
> in this case it is recommended that the DELAYED queue be used.
This is already appropriately handled by the existing NMU process,
which helps fix on-off bugs. The new process is for those willing to
make a long term commitment of fixing continuing issues in the
> - Where several NMUs for a package enter the archive over an extended
> period without the maintainer acknowledging them in a new maintainer
> upload, it is acceptable for others to add themselves as maintainers for
> the package, even without the permission of the current maintainer.
This could certainly be another condition where a volunteer-initiated
team join would be allowed/encouraged.