Re: [RFC PATCH v4 0/6] CI: js/ci-github-workflow-markup rebased on "use $GITHUB_ENV"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

>> With the other 29-patch series applied on the same base as before,
>> test_failure_ does not have such "fi" inside.  Misapplication of
>> rebase or something?
>
> This re-submission was rebased on "master", so that "fi" in the context
> is from the now-landed ab/test-tap-fix-for-immediate.
>
> I saw you'd fixed that conflict already, but figured rebasing before
> submission (as usual) would be helpful anyway, sorry about the
> confusion.
>
>> In any case, I've wiggled both series in and rebuilt 'seen'.
>> Looking good as before.
>
> Thanks, the end-state of the resolution looks good, and matches what I
> have locally.

OK, I guessed that much.

It may be OK for a topic to be rebased to an updated 'master' when
it is not close to be merged to 'next', but I prefer to see a reroll
to keep the same base, unless the new round starts depending on the
new base in a way more than just textually (i.e. e.g. wants to use a
new API function), as that makes it easier to read the comparison
with the previous round because a reasonably looking range-diff may
not necessarily mean that a patch that hasn't changed much from the
previous round would fit well inside the updated context.  This is
especially true for a series on the large-ish side, as I cannot
trust range-diff for an rebased series as much as I can for an
update on the same base.

This time, I tried to queue the new ones on updated 'master' and
then compared it with the result of merging the ones that I wriggled
to apply to the same base to the same updated 'master' to make sure
the end result is the same while I was working on making them apply
before I sent the message you are responding to, so I am reasonably
happy with the result.

It may not be a bad idea, as we are in pre-release freeze anyway,
for me to discard the two topics and replace them with a fresh
application of the same version on top of 'master', as we have
already verified that the updates from the previous iteration look
reasonable, to prepare for post-release (either merging to 'next' or
taking another reroll).

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux