unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* managing waiting patches
@ 2022-08-03 22:59 Nicolas Graves via
  2022-08-09 20:54 ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Graves via @ 2022-08-03 22:59 UTC (permalink / raw)
  To: help-guix; +Cc: ngraves


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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: managing waiting patches
  2022-08-03 22:59 managing waiting patches Nicolas Graves via
@ 2022-08-09 20:54 ` Ludovic Courtès
  2022-08-09 22:02   ` Nicolas Graves via
  0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2022-08-09 20:54 UTC (permalink / raw)
  To: Nicolas Graves via; +Cc: Nicolas Graves

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: managing waiting patches
  2022-08-09 20:54 ` Ludovic Courtès
@ 2022-08-09 22:02   ` Nicolas Graves via
  0 siblings, 0 replies; 3+ messages in thread
From: Nicolas Graves via @ 2022-08-09 22:02 UTC (permalink / raw)
  To: Ludovic Courtès, 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-08-09 22:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-03 22:59 managing waiting patches Nicolas Graves via
2022-08-09 20:54 ` Ludovic Courtès
2022-08-09 22:02   ` Nicolas Graves via

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