Felix Held wrote: > Having a commit queue or even running a build test for every patch > before it gets submitted would catch more breakages before the patches > land in the tree than switching to the new submit strategy,
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. I think each commit is still build tested and verified? And different pushed changesets continue to be build tested individually and can be submitted individually - right? Hmm, what happens when commit 1/2 in changeset 1 is submitted and someone then wants to submit commit 1/2 in changeset 2 before the other commit in the first changeset? Let's try in August I guess. :) I'm sure the change could be rolled back quickly in case there's any kind of annoying disaster problem in the repo. Kind regards //Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org