Re: Guix package incubator (later a channel)

[Ricardo Wurmus]

Hi Pjotr,

during the panel on the Future of Guix we all agreed that there is a
need to lower the barrier to entry for package submissions to Guix, so
it is good to start a discussion about actionable steps we can take to
make this happen.

> After yesterday's FOSDEM discussion I propose to set up a 'Guix
> incubator' git tree using Gitlab. The master branch will track the
> main Guix master but project can run on forked trees and branches. The
> idea is to have patches prepared by new committers or by people who
> simply prefer to use a web-based git environment. Each of these trees
> can become a guix channel - once we have channels to support that.

During the panel we had a question from the audience about alternative
tools, e.g. to allow a workflow that is not email-based.  While I can
understand the desire to use a workflow that you may be used to from
other projects (this goes both ways) there is a danger in establishing
alternatives to the channels on which we accept contributions.

At this point in the evolution of Guix we have many more contributors
than people who can mentor the contributors, polish their patches for
inclusion upstream, or provide constructive comments.  Having so many
people contribute is great!  But it also means that we need to be
careful with our limited number of mentors.

I see two possible outcomes of establishing an additional “incubator”
repository: it might fragment our review community as some people will
try to upstream incubator patches and others handle mailing list
patches; another outcome is that the incubator never gets accepted by
reviewers and mentors because it is more work, leading to growing
parallel infrastructure and second-class code.  Neither of these
outcomes is desirable in my opinion.

> It won't hamper the normal process since ready patches still get
> compiled and submitted through the mailing list (ML). In fact it may
> help scale the review process by getting peer reviewers involved. The
> idea is that we have an incubator environment before the ML which
> allows for playful learning and tracking of patches that may (or may
> not) make it into main line. I think it is very important to have a
> low barrier to entry when it comes to submitting package recipes.

I appreciate your desire to reduce the work load of reviewers/mentors on
the mailing list.  I have some doubts about whether this approach would
be feasible, though.  There already *are* external repositories outside
of Guix, either implemented to be used with GUIX_PACKAGE_PATH (such as
your own “genenetwork/guix-bioinformatics” repo or the MDC’s
“guix-bimsb”) or as forks of Guix (e.g. public versions of what most
Guix developers do locally to add packages).  I have not seen any
concerted efforts to upstream package definitions from either of these
classes of repositories.

This makes me wonder if the presumed benefits of an incubator could
actually be realised.  I would like to advise against recommending an
“incubator” procedure like this as an official alternative to
submissions to the mailing list.

Our workflow involving the mailing list is far from perfect.  We had
further discussions over post-FOSDEM dinner and drinks and there seemed
to be consensus among the people present (including long time
contributors, reviewers, and successful mentors) that it would be a
great improvement to keep track of package contributions in a separate
Debbugs instance (e.g. one “bug” per package submission).  It gives us a
way to track the state of things more easily, it accomodates people who
prefer to use a web browser, it permits us to continue to use email, and
it doesn’t force yet another account onto submitters.

Admittedly, the web interface that Debbugs comes with is kinda bland and
hard to use, so a second step would be to develop a better UI frontend
to Debbugs that would be closer to what people expect from an issue
tracker.

This was discussed before at
<https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00140.html>
and we could request a separate Debbugs instance for
address@hidden *right now* if we wanted to.

What do other people think about this?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net