Russ Allbery <r...@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.
