Re: On commit access, patch review, and remaining healthy

[Ludovic Courtès]

Hi,

Arun Isaac <arunisaac@systemreboot.net> skribis:

>>  That’s why, I think the project should:
>>
>>  1. change the default branch of “git push” vs the default branch of
>>  “guix pull”.
>>
>>  2. add a bit more of checkers on patch submission easing patch
>>  review.
>
> I like and support both these ideas. Maybe, they are even long overdue!
> ;-)

I like them too!

#1 is more involved than it sounds though: there would need some tooling
and/or human intervention to merge things from the push branch to the
pull branch.  I don’t have a clear idea of how to do this.

> I would also like to raise a couple of more controversial suggestions:
>
> Should we restrict the set of packages that will be accepted into Guix?
> Currently, we accept practically any free software package into
> Guix. Should we limit the number of packages we will accept in order to
> ease maintenance? "Minimal" distros like Arch Linux do this, for
> example.
>
> The cons are that, say if we reject packages involving difficult
> languages (think javascript), we may alienate a section of our users
> (and potential users) and thus inhibit further growth. If we go down
> this route, Guix may never grow into an "universal distribution" like
> Debian is.

I’ve been wondering about that too.  Clearly there’s a tension here.
The main difficulty as I see it is how do we draw a line?

For example, assume we came up two years ago with a policy to not
include Rust packages and instead have them in a guix-rust channel.  Two
years later, Rust has become a dependency of a number of core packages,
so we have to have Rust, or at least a large subset thereof, in the main
channel.

Then there’s the question of leaf packages (applications): how do you
assess the usefulness of an application?  How do you determine that an
application is no longer used?

> Also, should we remove old/broken/unused/rarely-used packages from Guix?
> In the past, I have packaged and contributed very niche packages which
> probably no one else uses, and sometimes even I don't use anymore. But,
> these packages continue to stay in Guix and add to the maintenance
> burden. Should we have some policy to phase out such packages,
> especially if such packages break often? I mean, that there is no need
> to phase out an elisp package that builds trivially all the time, but
> what about more complex packages that take many many hours to maintain?

I think we do that from time to time, but it’s an entirely manual
process.  Sometimes a patch to remove a package triggers a reply with a
patch to fix that package’s build process too (I’ve done that a couple
of times :-)).

What could help though is a dashboard, in Cuirass or in the Data
Service, that would display packages that have been failing to build
“for some time”.

Thoughts,
Ludo’.