unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Nicolas Graves via <help-guix@gnu.org>
Cc: Nicolas Graves <ngraves@ngraves.fr>
Subject: Re: managing waiting patches
Date: Tue, 09 Aug 2022 22:54:15 +0200	[thread overview]
Message-ID: <87tu6l2l54.fsf@gnu.org> (raw)
In-Reply-To: <87a68lorw8.fsf@ngraves.fr> (Nicolas Graves via's message of "Thu, 04 Aug 2022 00:59:19 +0200")

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


  reply	other threads:[~2022-08-09 20:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-03 22:59 managing waiting patches Nicolas Graves via
2022-08-09 20:54 ` Ludovic Courtès [this message]
2022-08-09 22:02   ` Nicolas Graves via
2022-09-05 19:45     ` Ludovic Courtès
2022-09-09 17:08 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tu6l2l54.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=help-guix@gnu.org \
    --cc=ngraves@ngraves.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).