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. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
