Re: Git Packaging Round 2: When to Salsa
Sam Hartman <hartmans@debian.org> writes:
> There are a number of ways forward:
> 1) Add a recommendation for people who don't want to give push access to
> all developers. Personal namespaces is the only option I've seen so
> far.
> 2) Only recommend personal namespaces and never debian
> 3) Note both options but not make a recommendation between them
> 4) Something along the lines of the current text; Jonas has explicitly
> disagreed with this approach
> 5) Make no recommendations in this space
> While I've been monitoring a lot of discussions, this issue is one where
> we'd need significantly more feedback than we've received so far for me
> to call a consensus.
I think using the debian namespace is the right default, particularly when
we view it through the lens of what's best for the project.
Think of it this way: we have a new Debian package maintained by someone
who's maybe new to the project. What kind of experience do we want them
to have by default, and how do we want to store their work to reduce the
risk of various failure modes with new maintainers?
My arguments in favor of the debian namespace:
1. This has the lowest bar of entry: you don't have to set up a namespace
or think about access control.
2. This has the lowest friction for collaborative work and onboarding new
contributors.
3. Anyone who comes from a tech company / Silicon Valley development
environment is probably going to already be used to this style of
collective ownership (along with politeness conventions about not
messing with other people's stuff unless you have talked to them or
know what you're doing), since this is an extremely common development
model there, and this will feel natural.
4. This has the least risk for the project if the person doing the work
disappears. We don't have to move the Git repository, change ACLs,
recover history from somewhere else, etc. Anyone else can pick up work
as needed in the same place.
5. We can easily make mass changes to these packages, which is something
we've not done much of historically but which would be a powerful new
tool. It would be even more powerful if we could do that for all
packages, of course, but that has more social tradeoffs, and it's still
useful to be able to do mass changes to a class of packages that may be
the ones with the least "attached" maintainers to the project who may
not be following project-wide discussions.
Obviously, we cannot and should not *require* using the debian namespace,
and anyone who wants to can certainly create their own namespaces. But I
think it's important to note here that folks like Jonas are not the target
audience for these recommendations. Anyone who, like him, already is
doing Debian packaging and already knows how Debian works can continue to
manage their packages however they want. They already know the onboarding
costs and are comfortable with them, the project has a track record with
them and knows they're not likely to disappear, etc.
I'm also a little bit uncomfortable with putting some of my packages
(particularly the ones for which I'm also upstream) into the debian
namespace because I want more control. (This may be an unproductive
emotional reaction; I may decide later that this is wrong. But it was my
first reaction.) But I don't think we should look at this through whether
it matches what I, or Jonas, or David, or someone else already deeply
enmeshed in Debian would do. We should be choosing a default
recommendation anticipating the mindset of a new developer instead.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: