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
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
