Re: Git Packaging Round 2: When to Salsa

[David Bremner <david@tethera.net>]

Russ Allbery <rra@debian.org> writes:

> 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.

This specifically I have to disagree with. I think anyone with this
background will be used to doing merge requests. I think the idea of
needing direct push access to many repos is specific to Debian. Maybe
there are different subcultures out there, and we have exposure to
somewhat disjoint sets.

> 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.

In order mass changes to be possible, there needs to be a common
workflow for packages in the debian group. In order for automation to
work, we need not just a general recommendation but a rigid policy. I'm
not objecting to that, but I don't think it exists now. In fact I think
this is probably an interesting answer to Zigo's proposal to make a
uniform git workflow mandatory, which is to do that for the Debian salsa
team.

I'm also not sure if this is a completely rational reaction, but I'm not
currently very comfortable with any DD being able to make global changes
to thousands of git repos. I think we haven't yet developed any kind of
social conventions or rules about when that is appropriate, and we don't
have much project experience with it. That's possibly a seperate
discussion, but if mass changes are the justification for some other
policy/norm/standard/reccomendation, then maybe it should be discussed
first.