Am Thu, Apr 04, 2024 at 02:41:00PM +0100 schrieb Luca Boccassi: > > 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.
Well, do you think well-respected members of our community who disagree with a change of structure are "nothing"? In preparation of my platform I started kind of a test ballon inside DPT where I spotted something I considered wrong inside the team policy and suggested a change[1]. There were a lot of positive responses and finally the change was accepted. But even before this happened we've lost two major contributors[2] (leaving more or less silently) and [3]. I confirm I made mistakes in this process and hopefully learned from it. So we have to deal with people and changing a structure that has evolved over >30 years might be harder than in the case of other distributions with a different history. IMHO changing a structure is harder than creating one from scratch. > 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'm kindly inviting everybody to join me in drafting a GR about this (no matter whether I might get elected or not). > > 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. I share this opinion 100%. > 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. I fail to see the logic in this "especially because they don't want it" but I agree that I see the potential decision making body in the CTTE. To say it clearly: It should by no means be DPL (and I hope your logic does not apply to this statement as well. ;-P ) > 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_. To stick to one example I gave in an other thread on this list: Assuming we decided to move all packages on Salsa, I could start importing packages that are not on Salsa and upload these starting from the day after this decision without asking the maintainer? > 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. Interesting detail which is probably not feasible for every decision (since its hard to imagine how to roll back a "move all packages on Salsa" decision). > 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). ACK > 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. Sounds sensible. > I'm getting ahead of myself, but hopefully you get the idea. I perfectly get the idea since I basically subscribe this for years. Kind regards Andreas. [1] https://lists.debian.org/debian-python/2024/02/msg00052.html [2] https://lists.debian.org/debian-python/2024/03/msg00043.html [3] https://lists.debian.org/debian-python/2024/03/msg00118.html -- https://fam-tille.de