Re: please try to avoid sending pullreqs late on release-candidate day
Philippe Mathieu-Daudé writes:
> On 7/23/20 8:28 AM, Markus Armbruster wrote:
>> Alex Bennée writes:
>>
>>> Kevin Wolf 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.
>>>
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
Re: please try to avoid sending pullreqs late on release-candidate day
Philippe Mathieu-Daudé writes: > On 7/23/20 8:28 AM, Markus Armbruster wrote: >> Alex Bennée writes: >> >>> Kevin Wolf 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. >>> 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
On 7/23/20 8:28 AM, Markus Armbruster wrote: > Alex Bennée writes: > >> Kevin Wolf 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. >>> >> >>> >>> 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
Alex Bennée writes: > Kevin Wolf 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. >> > >> >> 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
Kevin Wolf 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. > > > 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
On Wed, 22 Jul 2020 at 10:36, Kevin Wolf 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
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
On Tue, 21 Jul 2020 at 22:16, Gerd Hoffmann 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
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
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
please try to avoid sending pullreqs late on release-candidate day
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
