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. ...
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.
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
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.
On Fri, 2022-04-15 at 14:24 +0200, Luca Boccassi wrote:The only extra request from my side would be for salsa-maintained
A simpler solution sounds good to me, except that change would beI think this will also improve newcomer's contributing experience.What about doing something even simpler - rather than having additional
This proposal is also filed at
https://salsa.debian.org/debian/grow-your-ideas/-/issues/34
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.
somewhat "permanent" in stating the original maintainer's preference.
I forgot to mention in my original post that the tags can optionally
expire.
So, things like, `tag all my packages as "feel free to nmu" within
the next two weeks` would be trackable.
The only extra request from my side would be for salsa-maintained
packages to havet the NMU not bypassing the version management.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:31:07 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,510 |