From: Vagrant Cascadian <vagrant@debian.org>
To: Christopher Baines <mail@cbaines.net>, guix-devel@gnu.org
Subject: Re: Thoughts on committers pushing simple changes from other committers?
Date: Tue, 21 Feb 2023 10:52:54 -0800 [thread overview]
Message-ID: <87v8juq29l.fsf@yucca> (raw)
In-Reply-To: <87y1ordv5p.fsf@cbaines.net>
[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]
On 2023-02-21, Christopher Baines wrote:
> So probably in part due to the recent changes to the commit policy [1] I
> think there are more "simple" changes being sent to guix-patches by
> committers, which I think is good, but that's got me thinking about the
> process for these changes.
>
> 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9aa2b7419854306b7ae78d4c4f7684316b834b1d
>
> Generally, I don't push changes for other committers, but I wonder if
> that would be helpful now.
As someone who submitted a patch a few weeks ago:
https://issues.guix.gnu.org/60940
...which was very recently ACKed, I would definitely welcome someone
pushing it!
There is also no sign like "this has been reviewed by N people" better
than one person authoring it and another person pushing and signing it,
with some Reviewed-by or other relevent tags in the commit.
For some patches (60940 took a few months of on-again, off-again work,
testing, and poking at it), by the time it lands as a submitted patch, I
might be a little tired of staring at it. :)
Even with a quick (e.g. a couple days) response to a submitted patch, I
likely have moved onto other things, it may not be fresh in my mind, the
right things may not be in my /gnu/store anymore to quickly re-test it,
it may take a bit to apply the patch on the right branch...
In this particular case, not only has my attention shifted to other
things for a while (e.g. Debian freeze cycle and things entirely outside
of computer realms) ... to top it off the machine I tested the changes
on ceased to exist!
A lot can happen in a few days, or weeks, etc.
Obviously, for someone else to push a "my" patch, they may have to go
through a lot of the same sorts of issues... but if they have freshly
reviewed it, maybe they are more in a state of "working on guix" and it
might be less of a context switch? Or maybe not...
I guess one way might be to be more explicit about intentions and access
when submitting or reviewing patches:
"Reviews definitely appreciated, but please let me push it myself when
it is ready."
"On reviewing this patch, it looks good to me, but I cannot push it
myself right now. Push when you can or maybe another committer can do
it."
"Thanks for the patch, I will push in X days unless you beat me to it!"
"Reviewers, if you like this patch, go ahead and push it, as I do not
have commit access."
"I am so *done* with this patch, any reviewers please consider pushing
directly if you think it is ready!"
Just a few ideas, could maybe formalize and document it a bit with some
specific recommended tags or keywords or whatever...
Maybe QA could even look up the committers by email and compare against
the submitter to determine if they have commit access or not, and
display that information on the patch review pages? No need to be
perfect, just more right than not. :)
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2023-02-21 18:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 12:54 Thoughts on committers pushing simple changes from other committers? Christopher Baines
2023-02-21 14:57 ` Andreas Enge
2023-02-21 18:00 ` Leo Famulari
2023-02-22 9:35 ` Andreas Enge
2023-02-21 17:58 ` Leo Famulari
2023-02-21 18:52 ` Vagrant Cascadian [this message]
2023-02-21 21:20 ` Simon Tournier
2023-02-25 18:06 ` Ludovic Courtès
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=87v8juq29l.fsf@yucca \
--to=vagrant@debian.org \
--cc=guix-devel@gnu.org \
--cc=mail@cbaines.net \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).