managing waiting patches

managing waiting patches

[Nicolas Graves via]

Hi!

I've some patches waiting to be merged, and was thinking about how to
deal with that. (I understand that maintainers are few and probably
overworked, I'm not criticizing anyone.)

There are actually two problems in one :

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.

Eventually, I decided to contribute other packages meanwhile, some
patches were either merged in the master branch, another one in the
staging branch, and other were not. My local copy repo quickly starts to
be a mess. It's not too bad for now, but I'm starting to feel the need
to get more organized for that.

I've thought about a few solutions on a personnal level to tackle
that. There of course the option to put commits in a branch, which may
be sufficient, and may combine with the package emacs-git-email to
provide complete functionality. I've also seen the stacked-git program,
which seems more adapted to these workflows. There's a partially
functional (unmaintained) magit-stgit (which I liked on paper because of
the ability to send series of patches through a magit-popup) and an
emacs-stgit package, but is not in guix so I guess no one is using that.

Is there a place I can find some best practices about managing series of
patches (as a contributor), beyond implementing "The Perfect Setup"?

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've seldomly sent reminders, but with no answer for now. And don't feel
comfortable writing here for this (I'm not actually, I'm only taking
concrete examples and searching for better solutions).

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

-- 
Best regards,
Nicolas Graves

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

Re: managing waiting patches

[Nicolas Graves via]

On 2022-08-09 22:54, Ludovic Courtès wrote:

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

Thanks for your answer, I'll check that.

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

I finally went for the branching strategy, hence my patch frenzy trying
to sort everything I wrote in well-ordered branches in one repo. Takes
some time but I'll close to that.

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

Thanks for the advice. Not an IRC user for now, maybe I will come
someday.

Is there a requirement to help with patch reviewing? I feel I can tackle
python or rust packages unless they are weird, I need not to spend too
much time on that, but if it's just advising new beginners (I'm myself
a 9 month old Guix user but went cold turkey on my main machine, while
my first patches were a nightmare, now I hope/believe they are quite
clean) or trying to patch and build locally for <1h a day, with
proper guidelines I might be able to help here.

--
Best regards,
Nicolas Graves

Re: managing waiting patches

[Ludovic Courtès]

Hi,

Nicolas Graves <ngraves@ngraves.fr> skribis:

> Is there a requirement to help with patch reviewing? I feel I can tackle
> python or rust packages unless they are weird, I need not to spend too
> much time on that, but if it's just advising new beginners (I'm myself
> a 9 month old Guix user but went cold turkey on my main machine, while
> my first patches were a nightmare, now I hope/believe they are quite
> clean) or trying to patch and build locally for <1h a day, with
> proper guidelines I might be able to help here.

Your help reviewing would be much welcome.

Currently there’s no strict “requirement” to help with patch review, but
the manual reads this (info "(guix) Commit Access"):

  One last thing: the project keeps moving forward because committers not
  only push their own awesome changes, but also offer some of their time
  _reviewing_ and pushing other people’s changes.  As a committer, you’re
  welcome to use your expertise and commit rights to help other
  contributors, too!

That hasn’t had the desired effect though—still too few reviewers among
the ~40 committers.  I’m not opposed to discussing whether to turn it
into a “requirement”.  A hot topic for those of us who’ll be in Paris
soonish!

Ludo’.

Re: managing waiting patches

[zimoun]

Hi,

I am very late to the party. :-)

On Thu, 04 Aug 2022 at 00:59, Nicolas Graves via <help-guix@gnu.org> wrote:

> I've some patches waiting to be merged, and was thinking about how to
> deal with that. (I understand that maintainers are few and probably
> overworked, I'm not criticizing anyone.)

I sympathize.


> There are actually two problems in one :
>
> 1) how to manage and track series of patches one makes in his local repo
> copy.

[...]

> Is there a place I can find some best practices about managing series of
> patches (as a contributor), beyond implementing "The Perfect Setup"?

What I personally do.  Either,

 a) use “git worktree” and checkout a branch with my stuff
 b) move my stuff to another folder and use the option --load-path
 c) create a channel (I barely do that)

Usually, I do b) when I need to share the result when colleagues.  I
find it easier/faster and less error-prone than via c) a channel (turn
on/off the channel at pull-time depending on the status of the series).

About a), I usually create a worktree (and a branch) for each series.

Once I get a Debbugs number, I sometimes rename this worktree and branch
to something like: patch-12345-julia-csv where julia-csv is a package
and the worktree contains all the required dependencies.

When I start another package, say julia-foo, depending on julia-csv, I
create another worktree (and branch) starting at the branch
patch-12345-julia-csv.

Doing so, just running plain ’ls’ shows me the situation; or ’y’ from
Emacs Magit.


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

Well, if the review is slow, it is probably because committers are busy
elsewhere.  :-)

When I feel frustrated, I open the bug tracker and dive in old bugs or
patches.  Many are forgotten and triage can help to save some time to
others; which can be reallocated for merging new contributions. :-)

The aim of mentors is to have a better idea to whom could review and/or
commit.  For instance, about some Python patches from May, it appears
reasonable to send a friendly ping and CC Lars or Hartmut.

Just to mention that some patches are easier to review than others.

Last, roam on #guix or #guix-hpc is sometimes helpful.


Thank you for your contributions and I hope this is motivating you in
helping for reviewing. :-)


Cheers,
simon