Re: none

[Ludovic Courtès]

Hi Roel,

Roel Janssen <address@hidden> skribis:

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

Thanks for your feedback.

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

Do you think it would help to add this as a section in the manual?

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

(I think it’s OK if GParted’s documentation isn’t available; that’s
probably the case for some other GNOME apps.)

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

Recursive bundling?  Woow.  :-)

Bundling is definitely a difficulty.  I still think there are good
reasons to unbundle software, but there are also a few exceptions in the
packages we provide.

It might be that VCFLib or the things in bundles have practically no
other user, in which case bundling makes absolutely no difference.

So I’m guessing these might be acceptable as-is.

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

Sure.  Concrete suggestions like this often help more than rants!  :-)

Thank you,
Ludo’.