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

[Arun Isaac <arunisaac@systemreboot.net>]

Hi,

>  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 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.

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 don't have strong opinions on these questions. I would love to hear
what others think.

Cheers,
Arun