Re: Adopt a patch!

[Ludovic Courtès]

Hi Arun,

Apologies for taking almost a month to reply!

Arun Isaac <address@hidden> skribis:

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

Here there are:

  https://lwn.net/Articles/708163/
  https://lwn.net/Articles/704088/

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

I agree we need more people with commit access.  I very much encourage
every committer to offer commit access to contributors who they deem
ready for that.  I think we’re often too shy, and that’s sad, because
that means the project doesn’t scale up as well as it could.

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

‘guix lint’ and ‘etc/indent-code.el’ provide some automation, but I
agree we could do better.

For license detection though, a tool could give a good guess, which
would already be an improvement, but people would still have to review a
bit more closely.  Some tools exist, such as Fossology, but I think
they’re pretty much designed to run as a Web service and are rather hard
to install and run directly on one’s machine.

If someone would like to investigate things that could be done here,
that could be very fruitful!

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

It’s hard to detect.  Maybe ‘gnu-build-system’ could print something
when a phase returns the unspecified value, for instance?

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

‘guix package/build/environment’ support loading definitions from a
‘guix.scm’ file, which goes in that direction.  However we could
certainly make it easier to use and advertise it more.

Happy Friday!  :-)

Ludo’.