Re: Question to all candidates: What are your technical goals
On Thu, 4 Apr 2024 at 11:39, Andreas Tille <andreas@an3as.eu> wrote:
>
> Hi Marc,
>
> Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
> > On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> > "we now use Wayland
> > instead of X11", "please don't create your system users with adduser and
> > more, use a declarative approach".
> >
> > At the moment, we simply dont take such decisions. I think that's a
> > problem.
>
> I think I get your point now. Thanks for these examples. You might
> have a point in these specific ones but I see Debian leading in other
> aspects.
>
> As far as I know other major distributions do not undertake the time_t
> 64bit transition (whether this marks leadership or not is questionable
> but it will make us the leading distribution on those architectures in
> future).
Of course they are, most of the important work lately has been done by
SUSE for example, to replace legacy components that will hopelessly
break in 2038. Of course they have an advantage in not having to carry
around dead architectures, so it's easier.
> I'm not well informed about other distributions but seeked the internet
> and for instance found some article about reproducible builds from
> 2019[2] where Debian and ArchLinux are mentioned frequently but Fedora
> is not. I've picked that older article since taking the lead means who
> started that effort and I think we are in this game.
>
> Apropos ArchLinux: I would love if Debian would manage to craft such a
> great documentation in Wiki. That's not a "technological" lead but
> we've lost the lead in documentation by far which is in my perception a
> weaker point than the time we adopt one or the other technical change.
>
> I think we are doing a good job regarding CI with adding autopkgtests
> (but we could do even better for sure). I'm not informed about the
> status of CI in other distributions and whether there exists something
> like Salsa CI. I'm positively convinced that Debian has reached a level
> of complexity which makes CI tests mandatory for every important package
> and I would love if we could do the lead here.
OpenQA is used by other distros, both Fedora and SUSE use it. Fedora's
source control system has a CI integrated with it that is similar to
the one we have. Packit is even starting to make its way in upstream
projects's CIs, we use it in systemd for example, so that upstream PRs
also build and test Fedora packages in Fedora images. We do the same
with Debian and autopkgtest btw.
> > > > Are our technical
> > > > decision-making processes up to today's challenges?
> > >
> > > Would you mind clarifying this question? We have the CTTE as
> > > decision-making instance but I'm not sure whether you are refering to
> > > this.
> >
> > The CTTE is a tie-breaker which is only invoked to resolve a fight. And
> > if invoked, the decision takes months. In other sitations, we keep
> > fighting in the open, probably doing a GR, which makes the news even
> > before we have decided anything.
> >
> > 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.
> > so
> > that we don't have a project leader who has the power to say "we're
> > going to do X", like the board or the managing director of a commercial
> > company has.
>
> I consider the DPL as a "Leader with no power". Convincing a huge
> number of volunteers to pull a string into the same direction is a way
> harder job than telling employees of a company what to do next. I'm
> aware of this challenge.
>
> > Seriously, I don't how Fedora takes their technical
> > decision, but there has to be a reason why they're so far ahead of us
> > technologically.
>
> 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.
Reply to: