Re: Question to all candidates: What are your technical goals
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
Reply to: