Hi Martin and Peter,
sure, I can let other developers with submit right try out the new submit strategy and not submit anything that's not directly related to what I'm working on right now. I mainly started looking through the submittable patches and submit them when I don't spot anything that should be changed, since noone else was doing that on a regular basis maybe 2.5 years ago and some patches that could be submitted were just sitting in Gerrit for more than a few days. I wouldn't mind if more submitters would regularly look through the submittable patches and send the patches upstream. Please look at the code of the patch first though even though it already has a +2; sometimes you'll catch some bugs or see some improvements for later.
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.
At least for me getting all patches with just checking out the last commit isn't the reason why I occasionally push rather long patch trains. For me the reason is that for example when adding support for a new SoC there will be mostly short patch trains for different unrelated features, but pushing those different short patch trains isn't a good option, since despite working on different features there will be a lot of merge conflicts between the different short branches, especially in the Kconfig and Makefile. When all separate patch trains get reviewed and are submittable, you can likely only submit exactly one branch and then need to manually rebase the other branches, repush those and ask the reviewers to get back the +2 the patches already had and basically do that after every short branch got submitted. So rebasing the different short feature branches into one branch to push to Gerrit makes this much easier for both the developers and the reviewers. In cases where this isn't a problem, I of course try to only have directly related patches in one patch train. I agree that patch trains with more than 20 patches might become a bit confusing and a bit of a pain to deal with, so it's always good to try to stay below that. In the last few years I've only seen very few patch trains that were significantly longer and those were usually related patches.
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. :\
The additional workload for Jenkins is my main concern here although it's also a bit annoying to need to do the extra rebases. This is especially the case when you're the reviewer who gave the patch a +2 and want to submit it after the 24h after the last significant change; in that case you'd either have someone else to do the rebase or find someone else to give the patch another +2, since after doing a rebase Gerrit considers the developer who did the rebase as new author and authors aren't allowed to +2 their own changes and so Gerrit will ignore this +2.
With the knowledge that when there is a patch train that is all submittable, the submit together with previous patches button on the last submittable patch in the train should be used to not need to rebase most of the patches after the previous patch got submittet, the rebases might not be as much of a problem than I initially thought. I'm certainly more used to how things worked before, so this has a bit of a learning curve for me, but I hope that writing about the things I ran into might help others to not run into those themselves.
Regards, Felix