[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: managing waiting patches

From: zimoun
Subject: Re: managing waiting patches
Date: Fri, 09 Sep 2022 19:08:09 +0200


I am very late to the party. :-)

On Thu, 04 Aug 2022 at 00:59, Nicolas Graves via <> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]