Felix Held wrote: > 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 want to apologize if it seemed that I asked you to hold back on any effort, especially some not directly related to day-to-day tasks, I did not mean anything like that. I understood Martin's point to be that you spend a lot of time working with Gerrit so have great insight, which I agree with. That said, of course it would be great if more developers try the new submit strategy and see how they feel about it. > 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. Nod, that's very understandable. For this, do you think it could work to not push everything at once, but only one "topic" at a time? In the local repo it would be still be one long series of commits, but each "topic" could have its own branch name locally, although there is no branch in the commit graph. A bit like using tags, but with branch names so that rebase works well locally. The workflow would then be to push the first "topic" (short patch train) to Gerrit, have that enter master, pull and then rebase the following local branches onto master, push next "topic" and so on. This has both benefits and drawbacks; a benefit is that there are more frequent but much smaller patch sets to review, a drawback is that each patch set requires one "Gerrit turnaround" which for a large project could take a while. > 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 would be mitigated by only pushing smaller patch sets at a time. > 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. That's a good point - but that only applies to the "perfect patch set" case, right? It's cool if we can optimize that but I wouldn't want to make things a lot worse for patch sets needing some turnarounds. > I hope that writing about the things I ran into might help others > to not run into those themselves. Thanks a lot for that! Kind regards //Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
