Re: none

[Roel Janssen <roel@gnu.org>]

Pjotr Prins writes:

> On Thu, Jul 21, 2016 at 02:51:38PM +0200, Ludovic Courtès wrote:
>> In
>> <https://github.com/pjotrp/guix-notes/blob/master/ELIXIR.org#the-gnu-guix-dance-of-getting-packages-accepted>,
>> you already identified exactly what we were going to say.  :-)
>> 
>> Namely, why are patches applied in a build phase rather than in
>> ‘origin’, why is such and such test disabled (one sentence is usually
>> enough), what happens if we set ‘HOME’ like Ben suggests, etc.
>> 
>> What should we do?  :-)
>
> I think I have covered that both in my writeup and in my response to
> Ben. I think this work should be accepted as is.
>
> I think this is probably the last package I am contributing to main line.
> Never liked dancing that much ;)

For the last twenty weeks or so I have started contributing packages to
GNU Guix mainly because Pjotr gave me the opportunity to do so.  For me,
upstreaming was part of the deal, and I'd say it has taken me at least
two times the time it took me to write a proper package definition to
get it in the upstream distribution.

You've seen the mistakes I made, and the little syntactic things that
kept going wrong over time.  Near the end of my internship, however, I
saw a positive change: Reviewers actually make little changes, instead
of leaving it up to the submitter to ``fix the indendation''.  This
change makes the burden of reviewing smaller as well as the burden to
submit a package.  Great!

One thing that really helped me in reducing the time to contribute
changes to the upstream distribution, is to have a good workflow.  I
ended up doing the following:
1. Make the changes.
2. Commit the changes.
3 git format-patch -1 --no-attach
4. git reset --hard <latest commit on origin/master>
5. Submit the patch to the mailing list
6. Wait for response and probably go back to 1.

I made all of my changes on a GNU Guix git checkout.  So, not writing
package definitions on a separate repository.

> But seriously, we should find other ways to encourage people. I wonder
> how many packages are out there that never find their way into guix or
> much too late. I wonder how much duplicate work is going on because of
> our dance requirement. If it this hard *with* my experience in
> packaging, how hard do you think it is for people *without*
> experience. I know Dennis, for example, is sitting on a heap of opencl
> packages which are incredibly useful to many people.
>
> I believe we have to change our ways.

The problem is real.  I have taken contributing back to upstream _very_
serious, and I haven't been able to get everything back into GNU Guix
either.

Packages I work(ed) on that haven't made it upstream (yet) due to
``imperfect'' patches:
* MongoDB:    Bundled source code;
* GParted:    The help function does not work without external
              documentation database tool;
* FreeBayes:  At first, licensing issues, now just a plain ugly patch to
              deal with the unbundling of its dependencies in the
              Makefiles of this project;
* VCFLib:     Same situation as FreeBayes.  To be honest, this package
              would've not ended up as a separate package if I didn't
              have to split up FreeBayes.  I consider this a positive
              effect of the review process.

Lastly, I would like to say that I think the package reviews have always
been positive and fair.  We are trying to maintain a high-quality
distribution, and this is a natural effect of trying to do so.

Maybe we could create an online course to do packaging with GNU Guix and
make it rewarding with a grading system and giving achievement points..
That might make the incentive to make the upstreaming step of packaging
more fun and more like a learning process rather than a recurrent PITA.
(This is something I could spend time at..)

Kind regards,
Roel Janssen