On Fri, 5 Apr 2024 at 11:18, Andreas Tille <andr...@an3as.eu> wrote: > > 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.
That is answered in the bit you quoted below: > _plus_ precise and explicit choices about project governance Project governance is a choice, there's no law of physics that says it has to be done one way or the other, even outside of a commercial setting. Yes, it is harder to change than to start from scratch, there's no doubt about it. > > 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). Happy to help > > > 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 ) There's an old maxim about the people best suited to hold power being those who want it the least or not at all, it was a quip made in that general direction, no special meaning. > > 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? Being empowered to execute a decision doesn't discount common courtesy, so maintainers would be kept in the loop, but essentially yes, that would be one example > > 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 that case it would probably be something along the lines of "it is no longer mandatory"
