On Thu, 4 Apr 2024 at 13:40, Andreas Tille <andr...@an3as.eu> wrote: > > Hi Luca, > > Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi: > > > > That's the price we currently pay for being not a commercial entity, > > > > > > I fully subscribe to this statement. > > > > I don't think commercial entities have anything to do with this. > > Fedora is not a commercial entity (please, no FUD about RH) and yet it > > can take decisions and implement them just fine. It's entirely a > > question of self-organization and what rules we decide for the > > project. > > Please don't get me wrong: I do not consider Fedora a commercial > entity. I simply subscribe the statement that we are facing some > problems in Debian since we are not a commercial entity.
I think the framing is slightly misleading: it's true that a commercial entity with a hierarchical structure would not have the same issue, but the point I am making is that there's nothing stopping a non-commercial entity from having a structure that allows the same decision-making and executing, as proved by Fedora. Hence, it's not just the fact that Debian is not a commercial entity that leads to the status quo, but the combination of not being a commercial entity _plus_ precise and explicit choices about project governance. > > > I need to admit that I (currently) don't know much about Fedora (but I > > > hope I could fix this in the near future). At Chemnitzer Linuxtage I > > > took the chance to talk to OpenSUSE and Nix about organisatorical > > > solutions. There was no booth by Fedora I could show up. > > > > In short, Fedora project members elect a technical committee, FESCO. > > Project members can submit proposals to this committee for > > project-wide changes, which votes on whether to approve them or reject > > them. If they are approved, the committee and the proposer are > > empowered to enact the changes distro-wide - whether individual > > package maintainers like them or not. An approved proposal can fail > > and be rolled back for technical reasons (e.g.: unexpected issues crop > > up at implementation time), but not because random package maintainers > > practice obstructionism because they don't like the decision. > > If you compare this to Debian what exactly is your proposal to change > for the better? For starters there needs to be a decision on whether the status quo is fine or change is needed. That is non-obvious, I have my opinion but others will have theirs. It would mean the end of "my package is my fiefdom", and a move towards collective maintenance. >From the organizational point of view, it would require a GR to change in the constitution to enshrine the power to take technical decisions and make them happen into a constitutional body - the CTTE will probably say "no no no not us, please, no", but I'm pretty sure that's exactly where such power should reside, especially because they don't want it. A procedure to submit proposals for discussion with the whole project should be established (we already have the DEP process for example), that ends with a vote of the decision makers body. And once the body makes a technical strategy decision, them or whoever they want to empower, can go and make it happen, without having to walk on eggshells and dance around sacred cows - the time to dissent and discuss is _before_ the decision is made, not _after_. In Fedora every proposal must include a criteria to allow declaring that the game's a bogey and plan to rollback, in case something goes wrong, but this is again decided by the decision makers body. In practical terms, it would probably be made easier if it was mandatory for all packages to be on Salsa, either in the 'debian' namespace or in a team namespace (but not under individual users). Then perhaps for each approved decision, until the project is completed the implementer(s) would automatically get write access to all teams namespaces to push the changes - as MRs because reviews are good, but with the powers to merge them too. I'm getting ahead of myself, but hopefully you get the idea.
