All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: please try to avoid sending pullreqs late on release-candidate day
Date: Thu, 23 Jul 2020 17:36:53 +0100	[thread overview]
Message-ID: <871rl2tcgq.fsf@linaro.org> (raw)
In-Reply-To: <16f1e661-edaa-2ee2-008d-3c9ad0e5e10d@redhat.com>


Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 7/23/20 8:28 AM, Markus Armbruster wrote:
>> Alex Bennée <alex.bennee@linaro.org> writes:
>> 
>>> Kevin Wolf <kwolf@redhat.com> writes:
>>>
>>>> Am 21.07.2020 um 17:56 hat Peter Maydell geschrieben:
>>>>> It is not helpful if everybody sends their pullrequests late
>>>>> on the Tuesday afternoon, as there just isn't enough time in the
>>>>> day to merge test and apply them all before I have to cut the tag.
>>>>> Please, if you can, try to send pullrequests earlier, eg Monday.
>>>>
>>> <snip>
>>>>
>>>> So given that we _will_ have some late patches, what can we do to
>>>> improve the situation?
>>>>
>>>> Maybe I could send the pull request before testing it to save some time.
>>>> Your tests will take a while anyway, so if my own testing fails (e.g.
>>>> for the parts of iotests that you don't test), I would still have time
>>>> to NACK my own pull request. This wouldn't buy us more than an hour at
>>>> most and could lead to wasted testing effort on your side (which is
>>>> exactly the resource we want to save).
>>>>
>>>> Can you test multiple pull requests at once? The Tuesday ones tend to be
>>>> small (between 1 and 3 patches was what I saw yesterday), so they should
>>>> be much less likely to fail than large pull requests. If you test two
>>>> pull requests together and it fails so you have to retest one of them in
>>>> isolation, you still haven't really lost time compared to testing both
>>>> individually. And if it succeeds, you cut the testing time in half.
>>>
>>> I've taken to just stacking up patches from my multiple trees to avoid
>>> sending more than one PR a week. Of course sometimes the stack grows a
>>> bit too tall and becomes unwieldy :-/
>> 
>> You're right, stacking unrelated smaller pull requests makes sense when
>> pulling all the pull requests in flight races with a deadline.
>
> I tend to disagree, since few patches from the "candidate fixes for
> 5.1-rc1" series are still being discussed, and we are past rc1. Half
> of them could have been merged in for rc1.

Sometime I do peel of the patches that are already ready and push
through the PR - especially if the stack is getting a bit too wobbly.
However as rc1 had already passed I just continued to collect them.

After all splitting them off is not cost free as I like to ensure my
final tag has a clean run through our CI as well as an overnight soak
through some of the longer tests ("make docker-test-build" & the vm
tests). Usually I tag at the end of the day and then send the PR the
next morning.

I'm about to post v3 of the series - I'll aim to tag it all Friday
evening or over the w/e and post the PR on Monday.

-- 
Alex Bennée


      parent reply	other threads:[~2020-07-23 16:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21 15:56 please try to avoid sending pullreqs late on release-candidate day Peter Maydell
2020-07-21 21:16 ` Gerd Hoffmann
2020-07-22  8:05   ` Peter Maydell
2020-07-22  3:34 ` Jason Wang
2020-07-22  9:36 ` Kevin Wolf
2020-07-22 11:50   ` Peter Maydell
2020-07-22 12:16   ` Alex Bennée
2020-07-23  6:28     ` Markus Armbruster
2020-07-23 10:26       ` Philippe Mathieu-Daudé
2020-07-23 11:12         ` Markus Armbruster
2020-07-23 16:36         ` Alex Bennée [this message]

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

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

  git send-email \
    --in-reply-to=871rl2tcgq.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.