Re: debian group on salsa allowing any DD to upload packages hosted there (Was: Bits from the DPL)
On 20/08/25 at 10:35 +0200, Andreas Tille wrote:
> Hi Jörg,
>
> Am Tue, Aug 19, 2025 at 11:15:36PM +0200 schrieb Joerg Jaspert:
> > On 17691 March 1977, Lucas Nussbaum wrote:
> >
> > > Maybe, instead than retrofitting a policy on the debian salsa group, a
> > > good way to both clarify the situation and allow an opt-in mechanism
> > > would be to create another group on salsa, with rules clearly defined
> > > from the start, and let maintainers decide of the maintenance model they
> > > want for the package they currently maintain. After all it's very simple
> > > to move projects between groups in salsa, and just requires an upload to
> > > update the VCS fields.
> >
> > Other way round makes more sense IMO. Instead of yet another huge group that
> > needs to be maintained in some way, keep the existing one the only such
> > large monster. And anyone who put things there and now has a different
> > opinion can move their package out of that into a different small group just
> > for that package (or a set of packages). That will be a way smaller
> > overhead.
>
> I fully support this.
>
> @Lucas, one practical drawback is that moving a repository out of
> Debian/ requires opening an issue for the Salsa admins, since only they
> can remove repositories there. I would prefer to minimize the number of
> such tickets. Since my impression is that the majority of people I spoke
> with share the understanding that Debian/ implies collaborative
> maintenance, it seems easier to move out the (likely small) number of
> repositories where maintainers want stricter control. Of course, my
> sample might be biased.
>
> Can you give some practical examples of packages that you would not want
> to see covered by such a policy? That would help me better understand
> your concerns.
My problem here is a "such a policy" and "collaborative maintenance" are
not well defined. And opposing it to "strict control" is not helpful.
We have a policy for what is acceptable for NMUs (which sounds fine to
me) and we have LowThresholdNmu that relaxes this even further (which
sounds fine to me as well). I understand that you want to go further
than that, but I don't understand how far.
Also, it sounds like the problem you are trying to solve is not properly
defined (or at least that I don't understand it), or that you are
conflating two different issues (git access rights and upload policy)
for no real reason.
My background is that I think that some level of ownership is useful,
because it usually translates to (1) people feeling responsible about
the stuff that they "own"; (2) people who accumulate expertise about
this stuff, and sometimes relationships (for example with upstream).
Of course ownership also has disadvantages, but it's all about a subtle
balance.
Three concrete questions:
1/
Assuming there's a package (hosted in the Debian group) with something
not very important that could be fixed (severity: minor or severity:
wishlist). There's consensus in Debian that it's something that should
be fixed. The maintainer is active.
The NMU policy says that I can upload it to DELAYED/15. Since it's in the
Debian group, I could also push a branch with the changes, and merge it
after the package has been accepted.
If the maintainer is listed in LowThresholdNmu, I could upload without
delay, but it would be impolite to do so without coordinating with the
maintainer.
Under the policy you envision for the Debian group, is it OK to upload
without delay and push changes to debian/latest without coordinating
with the maintainer? If not, where would you draw the line?
2/
What will debian/changelog look like? It's not a "Non-maintainer
upload", but it's also not a "Team upload". Or is it?
3/
What will the Maintainer and Uploaders fields look like?
I would fully support a proposal to create a team for team maintenance
of random packages, with its own salsa group, discussion inside the team
about e.g. moving to newer packaging standards and push of changes
to all packages. I would be interested in contributing to such an effort.
What I oppose is the retrofitting of a new, not well defined policy on
the Debian group, to turn it into a "Debian Collaborative Maintenance
Team".
Lucas
Reply to: