Re: Adopt a patch!

[Arun Isaac]

> At the time, Andy (I think) suggested that collaborative maintainership
> the way we do it might actually “work better” and scale better.  In the
> meantime, there have been long discussions in Debian about whether
> package maintainers should be dropped.  Some rightfully argued that
> maintainership gives a sense of “ownership” to the maintainer(s), which,
> whether we want it or not, discourages others from contributing to the
> package.

Yes, makes sense. Sometimes, "ownership" also makes maintainers somewhat
less polite.

> I’m really summarizing here (there were a couple of articles on LWN),

Links to these articles would be nice. Do you have them?

> but to me that’s a very good argument.  I’d rather have a sense of
> shared responsibility that this.
>
> As for chaos, I don’t think it’s that bad.  :-)  As ng0 wrote, there are
> de facto people who are more familiar with specific packages.  They
> don’t have an official title, but they are the ones who’d review changes
> to these packages and provide advice.  It seems to work well so far.

Just thinking out loud: Maybe, we need more people with commit
access. Theoretically, anyone can review a patch, but ultimately it is
people with commit access who will have to finally apply and push the
patch. As the rate of submission of patches grows, this increases the
work load on those with commit access.

More automation with regard to reviewing patches might help. For
example, would it be possible to automatically or semi-automatically
detect the license of a package? Many packages have multiple licenses,
and it is quite tedious to grep through the source code and identify all
the licenses involved. Even partial automation could be useful
here. Github does some kind of license detection. I have no idea what
kind of algorithm they use, though.

Also, I keep forgetting to return #t at the end of phases. Could there
be some way to auto-detect this?

> What is more scary is massive imports from external repos (CPAN, etc.).
> I think we cannot handle all of it, not with our “quality” guidelines
> and not with the pace at which these repos change.

True. It is very difficult to keep up with those gigantic repos.

> At the GHM, we were discussing that, probably, we’ll have to accept for
> Guix to be a gateway to those repos (at least for the “non-core” subsets
> of the repos).  Concretely, one could do “guix package -i cpan!Foo::Bar”
> and have the package DAG imported and built live.  It’s either that or
> people will use CPAN’s own tools to achieve this.

It would be nice to have some kind of "upstream packaging" (like
AppImage), so that developers can package their software themselves. It
would be a quick way for new projects to get people to try out their
work. I believe there has been discussion and work on these lines in
Guix. I'm not very familiar with it. I'll read up.