[pkg-gnupg-maint] moving repos from alioth to salsa.debian.org

Sun Jan 7 06:54:55 UTC 2018

* Daniel Kahn Gillmor (dkg at fifthhorseman.net) wrote:
> Hey Eric--
> 
> thanks for helping think this through.
> 
> On Thu 2018-01-04 19:01:18 -0500, Eric Dorland wrote:
> > This one doesn't really make sense to me. The Debian project group will
> > likely be huge and not very browse-able anyway. People will just put
> > gnupg in the search box and what group it's in won't make any
> > difference. Having it in a group project might in fact make it easier
> > to find related projects.
> 
> I'm imagining (maybe this is unrealistic) that as many debian packages
> get moved into the debian project group as possible.

Given that there are already 100+ groups on salsa I would say that
that's probably not totally realistic.

> wouldn't it be great to know that if you want the source for foo, you
> could just go to https://salsa.debian.org/debian/foo ?

But surely you could build a redirector to give you exactly that kind
of functionality, for any package in salsa, no matter whether it was
in a particular group or the Debian group?

> of course, i'd also like it if everyone used git-buildpackage, modern
> debhelper, and followed my preferred packaging guidelines ;) [0]  Maybe
> i'm letting my utopianism cloud my judgement.
>
> > I have no desire to discourage them either but this feels a bit too
> > much like a free-for-all. Having some amount of ownership, vision and
> > consistency isn't a bad thing. GitLab should really cut down on the
> > fiction of contributing but reviewing changes is still important.
> 
> i agree with these last two sentences entirely, but i'm not convinced
> that control over pushing to a git repo is the way to achieve that kind
> of ownership, vision, or consistency.
> 
> My perspective on modern distributed revision control is that, as long
> as no one is actively publishing misattributed/malicious commits, and
> there's a rough consensus around who is "responsible" for the project, i
> don't really care who can add commits to a repo.  after all, "all git
> repos are the same git repo" anyway, right?
> 
> So i guess the only reason that i'd want to have formal control over who
> is committing to a git repo is in the event that i thought there was
> active antagonism or malice, which i don't believe to be the case here.
> and if there were, it would warrant pretty severe re-thinking of the
> work of the team anyway.

I think there's something to be said for having the write permission
left to a more limited set of users because of the more sensitive
nature of gnupg.

But leaving that aside, I don't think it's necessarily malice you need
to worry about, just disagreements in direction could be
problematic. If a another developer decides to say, push some patches to
strip out systemd support and you want to keep that support in, is
your only recourse the TC? Would the person in question need to be
somehow blacklisted?

Also (and again I don't think I understand how gitlab permissions work
well enough), looking at the debian group it does look like you can
give the Debian permission to a project that isn't under the Debian
group (eg https://salsa.debian.org/pkg-voip-team/asterisk). So
creating the group wouldn't prevent having open permissions for some
of the packages (or all).

> > Why do they need to come talk to us at all? They should just file pull
> > requests and someone on the team would review and approve them? They
> > don't need any write permissions to contribute.
> 
> absolutely true.  and, even in situations where i have write access but
> i'm not "the responsible party", i prefer to do pull requests rather
> than pushing changes because i want to make sure that my contributions
> are understood and approved by the folks who are going to maintain them
> longer term.
> 
> That said, i don't see how maintaining an explicit team membership
> actually helps this situation -- it just creates a barrier for folks who
> want to contribute.  if we find people pushing changes that shouldn't
> be, we'd need to talk to them obviously, but if they're actually
> helping, why would we need the explicit permissions?

Mostly just to force a review step, but maybe there's a way to do that
in Gitlab without explicit permissions, I'm not sure.

> > This all being said I think the pkg-gnupg-maint@ team has mostly been
> > an army of one (that would be you), so I don't feel like I have a
> > strong position to object :) I'll still be happy to work on things
> > when I can no matter what you decide.
> 
> well, i definitely want to make these decisions in a way that don't
> discourage people from working on GnuPG in debian, so i'm happy you'll
> stay engaged either way :)
> 
> I'm still leaning away from having to have an explicitly-named and
> -maintained group on salsa.debian.org, but if other people feel strongly
> about this the way that Eric does, or would be more inclined to
> contribute if group membership were required, i could be convinced.
> please speak up!

I should say that personally, feeling like being part of the group is
a mild inducement to contribute compared with 

> > I find it surprising that we're not going to come up with a solution
> > for this problem within Debian. Should we wait a little bit longer to
> > see if one emerges rather than rush just to potentially move again?
> > When are the alioth lists meant to be turned down?
> 
> I think the alioth lists are supposed to stop accepting incoming mail on
> 2018-02-01, according to:
> 
>    https://wiki.debian.org/Alioth#News
> 
> Do you want to push on the lists.debian.org mailing list request?  I've
> got my hands pretty full right now, and am inclined to just go where
> people are willing to help (which currently means upstream, not
> listmaster at d.o), but if you think it should really be a debian list, i'm
> game to wait while we try to sort this out further.

Huh, that really is a shame that there's no real migration path. I
suppose the @gnupg.org list is the best option at the moment.

-- 
Eric Dorland <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20180107/d7815feb/attachment.sig>