[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question to all candidates: What are your technical goals



On Thu, 4 Apr 2024 at 13:40, Andreas Tille <andreas@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.


Reply to: