Hi Jakub,
On Fri, Sep 29, 2023 at 03:17:23PM +0200, Jakub Czapiga wrote:
Clearly I must be doing something wrong as the patches have been
gathering dust for around three years now.
There might be few reasons for that. First, for patch to be eligible for review it cannot have merge conflicts as resolving them might change patch contents and will most certainly drop all CR+ scores and invalidate some comments. You should try keep patches in mergable state.
My patches all depend on one another, Gerrit seems to treat this as "conflict" when this is entirely normal so I don't see how I can do what you suggest.
I (used to) frequently rebase against master to make sure actual conflicts don't stay there for long FYI.
I push these using HEAD:refs/for/main as was documented last time I checked (3y ago) not sure what else is expected of me.
Second, submitting long patch trains usually makes reviewers to halt until previous patches are reviewed, as changes in patches earlier in the train might invalidate their time put into reviewing. I'd suggest focusing on earlier patches first, merging them and gradually moving to later ones.
Another proplem here being that gerrit makes it very hard to figure out what the "first" patch is anyway. They get shuffled into a random order every time I push the series.
Am I as the submitter supposed to draw the reviewer's attention to which is the first patch or what? That can't possibly be right. The gerrit interface sure makes it seem like reviewers are notified of the fact that they're supposed to do something. UI lies I suppose.
Honestly this gerrit thing may work OK for companies where people are properly incentivized to do their assigned reviews or people in the in-group that know who to poke to get things moving, but for outside contributors the experience is even more fundamentally broken than the email/ML patch workflow and that's saying something.
Consider this as a point of project self-interest. I would have probably been busy writing/reviewing coreboot patches for the past three years if my contributions didn't end up getting dropped on the cherry-pickin room floor.
As I see it: I could have just bought a 50c Winbond flash chip and called it a day, yet here I am refactoring code, adding vendor support and writing tests for security critical code. Isn't that exactly the type of highly motivated individual contributor the coreboot project should be trying to attract?
Well your infrastructure/processes are getting in the way of that.
Please do better <3
--Daniel