please try to avoid sending pullreqs late on release-candidate day

please try to avoid sending pullreqs late on release-candidate day

[Peter Maydell]

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.

thanks
-- PMM

Re: please try to avoid sending pullreqs late on release-candidate day

[Gerd Hoffmann]

On Tue, Jul 21, 2020 at 04:56:25PM +0100, Peter Maydell wrote:
> 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.

I usually try, but it didn't work out this time due to patches coming
in late ...

Speaking of testing:  What is the state of gitlab ci?  How much of the
testing has been migrated over?  I've noticed I can push branches and
tags to a qemu fork @ gitlab.com and gitlab ci runs a bunch of tests.

What is the best way to indicate that the tag did pass gitlab ci
already?  Maybe simply send a pull request with gitlab.com url?

take care,
  Gerd

Re: please try to avoid sending pullreqs late on release-candidate day

[Jason Wang]

On 2020/7/21 下午11:56, Peter Maydell wrote:
> 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.


Ok, will do.

Thanks


>
> thanks
> -- PMM
>

Re: please try to avoid sending pullreqs late on release-candidate day

[Peter Maydell]

On Tue, 21 Jul 2020 at 22:16, Gerd Hoffmann <kraxel@redhat.com> wrote:
> Speaking of testing:  What is the state of gitlab ci?  How much of the
> testing has been migrated over?  I've noticed I can push branches and
> tags to a qemu fork @ gitlab.com and gitlab ci runs a bunch of tests.

I still need to look at Cleber's most recent patchset which
has the scripting for this.

> What is the best way to indicate that the tag did pass gitlab ci
> already?

There's no need to indicate anything, it wouldn't alter my testing
process.

thanks
-- PMM

Re: please try to avoid sending pullreqs late on release-candidate day

[Kevin Wolf]

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.

I sent the majority of my fixes for -rc1 on Friday, not the least to
give us some time in case we get a testing failure. However, the earlier
you send the pull request, the greater the chance that you get some new
patches after the pull request. In this case, the patches were only
ready Tuesday afternoon, so even sending on Monday instead of Friday
wouldn't have helped.

The alternative would have been letting them wait for -rc2. I suppose
you can always says "too late" and make that decision for me, but I
wouldn't want to unnecessarily move things to a later RC. Do you think
we shouldn't send a pull request in case of doubt?

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.

Kevin

Re: please try to avoid sending pullreqs late on release-candidate day

[Peter Maydell]

On Wed, 22 Jul 2020 at 10:36, Kevin Wolf <kwolf@redhat.com> wrote:
>
> 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.
>
> I sent the majority of my fixes for -rc1 on Friday, not the least to
> give us some time in case we get a testing failure. However, the earlier
> you send the pull request, the greater the chance that you get some new
> patches after the pull request. In this case, the patches were only
> ready Tuesday afternoon, so even sending on Monday instead of Friday
> wouldn't have helped.

Patches that arrive and are only ready Tuesday afternoon are
naturally at risk of slipping into the next RC. That's OK.
Though when we get to rc2/rc3 you should warn me when you
expect that so I can make a decision about whether it's better
to slip the rc by a day to wait for them.

> The alternative would have been letting them wait for -rc2. I suppose
> you can always says "too late" and make that decision for me, but I
> wouldn't want to unnecessarily move things to a later RC. Do you think
> we shouldn't send a pull request in case of doubt?

Mostly what I mean is "don't assume that because RC day is Tuesday
that you can send a pullreq on Tuesday and have it get into the RC".
If it turns out that you have to do that, that's not a big problem.
What is a problem is if half a dozen submaintainers all send a
pullreq at once on the Tuesday afternoon. So in the situation where
you don't anticipate anything much late arriving then send it earlier.

> Can you test multiple pull requests at once?

I could in theory I guess, but my scripting assumes one at once.

thanks
-- PMM

Re: please try to avoid sending pullreqs late on release-candidate day

[Alex Bennée]

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 :-/

>
> Kevin


-- 
Alex Bennée

Re: please try to avoid sending pullreqs late on release-candidate day

[Markus Armbruster]

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.

Re: please try to avoid sending pullreqs late on release-candidate day

[Philippe Mathieu-Daudé]

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.

Re: please try to avoid sending pullreqs late on release-candidate day

[Markus Armbruster]

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.

That's a different issue, I think.

Picking patches that are ready and independent when the complete series
isn't often makes sense.  More so when a deadline is involved.

Re: please try to avoid sending pullreqs late on release-candidate day

[Alex Bennée]

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