Re: managing waiting patches

[zimoun <zimon.toutoune@gmail.com>]

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