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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
