unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Nicolas Graves via <help-guix@gnu.org>
To: help-guix@gnu.org
Cc: ngraves@ngraves.fr
Subject: managing waiting patches
Date: Thu, 04 Aug 2022 00:59:19 +0200	[thread overview]
Message-ID: <87a68lorw8.fsf@ngraves.fr> (raw)


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


             reply	other threads:[~2022-08-04 14:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-03 22:59 Nicolas Graves via [this message]
2022-08-09 20:54 ` managing waiting patches Ludovic Courtès
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=87a68lorw8.fsf@ngraves.fr \
    --to=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).