Sam Hartman <hartm...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>