Re: managing waiting patches

[Ludovic Courtès]

Hello Nicolas,

Thanks for your message.  Patch review is overall rather slow due to a
mixture of Guix being a victim of its success and (perhaps more
importantly) having too few people devoting time to patch review, and
too few committers committing.

This was discussed recently on guix-devel and I hope we can collectively
improve on that.  The new teams that we devised (see ‘etc/teams.scm’)
should help, though we have yet to document them and publicize them.

Nicolas Graves via <help-guix@gnu.org> skribis:

> 1) how to manage and track series of patches one makes in his local repo
> copy.
>
> For that, I will take a practical example.
>
> I made some rust patches a few days ago. The final goal of these first
> patches would have been to add the package swayr@0.20, which is huge
> when imported with recursive guix import (~2k lines). So I did split the
> task in a few subgoals, by trying to first update packages that are
> already present. By only doing that, I already had a stack of ~15
> commits. I couldn't contribute more at that moment, so I sent them in
> the hope that they would get merged before a next partial goal.

I don’t have any great suggestion here—you already seem to be doing
things rationally.  In general, short, to-the-point patch series are
more likely to be reviewed quickly, so that’s one strategy you can adopt
here.  And then you can locally keep branches for each part of the
broader patch series, possibly rebasing them until they’re applied.

> 2) how to get one's patches to pass.
>
> Another problematic I encounter is having to wait for a patch series to
> pass to send another one. Another example.
>
> I'm developing in my free time for an organisation using wagtail CMS for
> its website. I thought that it would be a great occasion to send some
> packages for guix, and get some experience with packaging. So I worked
> on that and send some patches (55476 55475 55474 55473). They are pretty
> clean (almost all tests enabled, tested as a user) (except maybe for
> descriptions, I'm not sure I remember for that).
>
> At some point, wagtail made an upgrade to version 3.0.1, and I started
> to update my packages locally, but don't want to make a totally new
> series of patches while the previous was not accepted. In the meantime,
> I send patches 56296 which would have been useful for later and actually
> fixes some failing packages. I'm now stuck on this contributing task
> because of this.

I can sympathize.  :-/

You could send an updated patch series with the new version as v2; that
would also serve as a reminder for reviewers.

Using ./etc/teams.scm you can also look for people working in this area
that you could ping.

Last, if you’re on IRC, you’re welcome to occasionally ping people
there.

[...]

> What should I do in this case? Should I try to become a committer
> myself? Have a "committer buddy" that can merge my sent packages? Keep
> working in a personal channel or a channel like guixrus and rely on that
> additionally to relying on guix? Other options?
>
> Thanks a lot for your answer, sorry if I don't have very acute developer
> workflows, I'm only doing this in my free time ;)

Understood!  You can always keep your work in a channel of yours until
it’s merged.  I do encourage you to work to get it in Guix proper
though, because in the end everyone benefits.  I hope we can all work to
reduce the bottleneck.

Thanks,
Ludo’.