Re: How to get reviews on gerrit? aka. patches ignored for three years.

Daniel Gröber <[email protected]>
Newsgroups gmane.linux.bios
Message-ID <[email protected]>
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
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.