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

Re: Is there room for improvement in our collaboration model?




On April 15, 2022 2:24:33 PM GMT+02:00, Luca Boccassi <bluca@debian.org> wrote:
>On Fri, 2022-04-15 at 00:17 -0400, M. Zhou wrote:
>> Hi,
>> 
>> I just noted this problem recently. Our model for team collaboration (specifically for
>> package maintenance) is somewhat primitive.
>> 
>> We are volunteers. Nobody can continuously maintain a package for decades like a machine.
>> Currently our practice for accepting other people's help involves:
>> (1) low-threshold NMU. This is not quite easy to lookup (only shows on tracker.d.o, etc)
>> (2) VAC note in debian-private channel. Who remembers you said the others can help you
>> upload a package? And when does that temporary permission expire? What tracks that?
>> (3) salsa permission. Yes, after joining the salsa team, others can commit code as they like.
>> However, when it needs to be uploaded, the others still have to write mail to the maintainer
>> for an ack. Whether multiple peoples should commit at the same time is coordinated through
>> emails in order to avoid duplicated work.
>> (4) last-minute NMU/delayed. When the others cannot bear an RC bug anymore, they may
>> want to nmu upload to the delayed queue.
>> (5) intend to salvage. When the others cannot hear from me for very long time, this
>> is the only formal way to take over maintanence (afaik).
>> 
>> The problems are:
>> (1) whether multiple people should work on the same package at the same time is
>> based on human communication. Namely, acquiring lock and releasing lock on a package
>> is done through human communication. This is clearly something could be improved.
>> It should be some program to acquire and release the lock.
>> (2) different packages are clearly regarded differently by people.
>> I'm actually very open to the other people hijacking some of my selected packages
>> and fix these packages as they like. Namely, I think there should be a system where
>> we can optionally tag our packages as:
>> 
>>  A. The other DDs can do whatever they like to this package and upload directly
>>     without asking me in a hijacking way.
>>  B. May git commit but should ask before upload.
>>  C. Must ask before any action.
>>  D. ...
>> 
>> You know that in parallel programming, optimizing IPC (in this context it would be
>> inter-DD communication) and optimizing the locking mechanism could help.
>> 
>> My motivation for pointing these stems from some uncomfortable feelings when
>> it's hard to get response from busy maintainers. If I understand correctly,
>> technically DDs have enough permission to hijack any package and do the upload.
>> People are polite and conservative to not abuse that power. But ... in order to
>> improve contributor experience in terms of collaboration ... maybe we can
>> use that tagging mechanism to formally allow a little bit of upload permission abuse.
>> 
>> I think this will also improve newcomer's contributing experience.
>> This proposal is also filed at
>> https://salsa.debian.org/debian/grow-your-ideas/-/issues/34
>
>What about doing something even simpler - rather than having additional
>generic/core tags/teams/groups, for packages where one wants to say
>"please help yourself/ourselves", simply set the Maintainer field to
>debian-devel@lists.debian.org, have the Salsa repository in the debian/
>namespace, and that's it? From thereon, anyone can do team-uploads by
>pushing to salsa and uploading directly, no need for
>acks/delays/permissions/requests.
>

This is something I have been thinking about for a while, but didn't took the time to propose. But rather using a specific mailing list (e.g. debian-cooperative@somewhere).

I'd be happy to put grep and bzip2 under such Maintainer:, if other co maintainers do not object.

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.


Reply to: