Re: Guix package incubator (later a channel)

[ng0]

On 17-02-07 20:38:58, Ricardo Wurmus wrote:
> 
> 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
> 
> 

The here mentioned debbugs solution would work now and it would have
an immediate 
effect. I really welcome this solution as a first step to try out
alternatives and I would make use of it.

Regarding the approach Pjotr suggested: would it be like
https://wiki.gentoo.org/wiki/Gentoo_Github ( See also:
https://wiki.gentoo.org/wiki/Gentoo_Github#See_also ) ?

I do share the voiced concerns - there are little reviewers, and while the
situation with reviews is bad it is really a people problem. Tools can
improve access for newcomers, but they won't fix the reviewers > patches
ratio.

Here are further ideas to motivate newcomers:
We regulary get questions on HOW to start and WHAT to use (for
contributing) etc. Okay,
improving upstream documentation would be ideal, but until then we can
have a better "get started contributing to Guix" section, and maybe a
link on the website to this (we already kind of have), Encourage to read
the open bugs (point to a "low hanging fruits" list of bugs and things
to do around Guix), and even more get people to review through
encouragment and ...stuff... (kind words, etc etc).

Goodnight!


-- 
ng0 -- https://www.inventati.org/patternsinthechaos/