[pkg-gnupg-maint] moving repos from alioth to salsa.debian.org
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Jan 5 01:04:45 UTC 2018
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.
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 ?
of course, i'd also like it if everyone used git-buildpackage, modern
debhelper, and followed my preferred packaging guidelines ;)  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.
> 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
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?
> 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 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:
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.
all the best,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the pkg-gnupg-maint