Hi Peter!
Hmm, I'm not sure about that? I understand the effective difference
with the new strategy to merely be that a later commit in a pushed
changeset/branch can't be submitted before an earlier one.
That is my understanding of this too. What I wanted to point out in my
last email is that switching form cherry-pick to always rebase will only
catch a small part of the things that resulted in a broken tree in the
last year or two. The majority of tree breakages was caused by two
independent patches doing something that won't result in a git conflict,
but in compile failures. For example when some devicetree register name
was changed in the chip.h file and all devicetrees that were in tree at
the time and in a separate patch a new mainboard was introduced, but
that mainboard was only build-tested on top of the tree before the
devicetree change was submitted. Submitting both the board and the
devicetree change won't cause a git conflict, but compiling the board
will fail causing the tree to be broken. Since this is usually a quick
fix that can be submitted via the fast patch with 3x +2, it's not too
bad IMHO.
Cherry-pick is useful for longer patch trains where the earlier parts
are independent, but some later part needs all the earlier parts. In
that case some parts that are independent from the patches before them
and are already reviewed and ready to be submitted would need to wait
until the patches before them are submittable too. And yes, submitting
patches out of order has already resulted in a broken tree in a very
small percentage of cases, but most of the time it was also easy to fix.
The main advantage of the always rebase strategy is that with the
currently used cherry-pick approach Gerrit shows a merge conflict on
later patches in a patch train that depend on some earlier change until
the previous patches are submitted, which is a bit confusing when you're
not aware that this isn't some error to worry about. The always rebase
strategy doesn't have this oddity.
I think each commit is still build tested and verified?
Not right before it gets submitted. It still gets build-tested like
before when the patch is pushed to Gerrit and after it got submitted.
And different pushed changesets continue to be build tested
individually and can be submitted individually - right?
Correct.
I'm sure the change could be rolled back quickly in case there's any
kind of annoying disaster problem in the repo.
I don't expect the always rebase submit strategy to cause any major problem.
Regards,
Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
