Martin Roth via coreboot wrote:
If we continue with this method (and for the rest of this month), I think we want to encourage shorter patch trains, consisting of only related patches.
Ouch! Yes please, for sure, regardless of the submit strategy.
Currently, it seems like projects will occasionally build up enormous trains of patches that aren't necessarily related so that they can pull all of their patches at once just by grabbing the last one.
I can understand such a desire, it does simplify things for the pushing developer and their testers, but then that shouldn't be done in upstream Gerrit.
I guess for contributors who can only commit lots of unrelated changes to a single internal branch (e.g. because they don't use git internally) would have an extra TODO in the export to git commits. :\
It's of course unfortunate to require that extra work but I find the benefit for the community significant!
The different "topics" in that train of commits become directly visible and can receive individual outside engagement much easier. I think that's unlikely to happen with commits in the middle of a long branch.
On a personal note I find unrelated commits in a branch quite confusing, others can of course be different there! :)
It also sounds like rebasing all of the patches so that the entire train is contiguous is really needed - no more patches based on older versions of the previous patch. I think the same is true for abandoned patches - rebase everything so that the patch train isn't broken in the middle.
May be - but that shouldn't be too bad?
I agree that it would be great for Jenkins to recognize when new commits are effectively unchanged since last test so that many "rebase builds" can be skipped but I don't have a great suggestion for how to make it happen. Sorry. :\
Kind regards
//Peter