[LLVMdev] Code Owner for OpenMP (runtime)

Renato Golin renato.golin at linaro.org
Fri May 1 03:39:24 PDT 2015


On 1 May 2015 at 10:11, Andrey Bokhanko <andreybokhanko at gmail.com> wrote:
> While I'm always happy to see more maintainers (which means better
> chance to get code reviewed!) and Hal is an all-around good guy, this,
> IMHO, sets a bad and dangerous precedent.

Hi Andrey,

I'm in no way affiliated with Intel, if anything, we're fierce
competitors! :) But I totally agree with you.

This has nothing to do with which company owns what, since code owners
don't really own anything.

For example, I am the code owner of ARM on the Linux side, Evan Cheng
is owner of the ARM on the Darwin side. Go back and count how many ARM
commits were reviewed and approved without our review. While you're at
it, count how many times other people trumped me on ARM reviews,
because they knew better, or because they were right and I was wrong,
or just because more people agreed with their solution.

Being a code owner doesn't mean you can do anything with it. It also
doesn't mean you can commit anything to your hearts' desire. It means
you're the poor bastard that will have to scrape unreviewed
submissions if no one else wants to. It means you'll have to stick
your head into arguments to try and calm people down, and probably get
burned along the way. It's a thankless job, it doesn't fare in my
"annual review", it makes enemies more than friends, and it frequently
interrupts my other duties.

Search the list and you'll see a lot of code owners asking for review
on their patches on code they own. Why? Because it involves more than
just a silly change, or an obvious fix, and it probably needs design
of other parts of the compiler to change. Code owners have to be
responsible for the quality all code, which most of the time means ask
other people what they think, getting consensus. It's about the work
you put in, not where you're from.

There's no reason why Churbanov shouldn't be the code owner. Poor Andrey... :)

cheers,
--renato



More information about the llvm-dev mailing list