[LLVMdev] RFC: Code Ownership

Meador Inge meadori at codesourcery.com
Mon Nov 12 07:55:00 PST 2012


On 11/12/2012 09:35 AM, Duncan Sands wrote:

> Hi,
> 
> On 12/11/12 15:11, Meador Inge wrote:
>> On 11/11/2012 11:58 PM, Chris Lattner wrote:
>>
>>>> Is there a particular sub-system size that makes sense to mark as owned?  I have been
>>>> reworking the library call simplification infrastructure recently and will be happy
>>>> to sign up as an owner for that.
>>>
>>> I think that "directory level" is the right granularity.  If you're interested in signing
>>> up to maintain and review the whole instcombine library, that would be a great level.  To
>>> see what this entails, see:
>>> http://llvm.org/docs/DeveloperPolicy.html#code-owners
>>
>> I am interested and comfortable with that.  I will wait a few days and then
>> update CODE_OWNERS.TXT.
> 
> while I think it's great that Meador is stepping forward to help out here, it
> does bring up the question of how expert you have to be to become a code owner.
> As far as I know (please correct me if I'm wrong) Meador isn't the number 1 LLVM
> instcombine expert, but instead is someone who knows instcombine fairly well
> and is willing to spend time making sure instcombine is in good shape and stays
> that way.  My take is that you should be able to be a code owner without being
> the ultimate über hacker for that subsystem, since (1) the über hackers will
> have their eye on you and will let you know if you get it wrong; and (2) being
> willing counts for a lot.  More power to volunteers!  Hopefully if people talk
> with each other, help each other out, and maintain a friendly and cooperative
> atmosphere then all problems with code ownership will just come out in the wash.

That is definitely a fair assessment.  I am not the #1 instcombine
super-hacker, but I am willing to keep it in good shape.  Even if that means
bugging other people :-)

Another point to address is whether there can be more than one owner in a
particular area.

-- 
Meador Inge
CodeSourcery / Mentor Embedded



More information about the llvm-dev mailing list