[LLVMdev] [cfe-dev] !!! 3.2 Release branch patching and the Code Owners

[Pawel Wodnicki]

>> This approach is fine for casual reader but
>> does not work for scripting or any automated
>> way of dealing with the build.
> Will you please clarify how the automation / scripting helps with the
> patch approval process?


Generally release patch process works like this:

- patch gets checked-in on the trunk

- developer sends message to the code owner who
approves the patch and sends the *APPROVED* to the
release manager

- somebody (not specified who in the current flow)
merges the patch on to the release_branch

- release manager creates rc1/rc2/and final branches
from the release_branch verifying that each patch
has been approved by the code owner.

This process looks good on the screen but breaks  down
in practice because:

- patches get checked-in onto the release_branch (rare)

- patches get sent to the release manager bypassing code owner

I think the root cause for this is simply the problem in
identifying the code owner by the developer.

We can solve this problem by providing code owner tool that can
map patch to the code owner or owners who should be
notified for approval.



> 
>>  I would like to propose addition of the
>> "folder/file (F)" field. The format
>> would be the same as used by Joe,Owen
>> and Justin
> This won't cover all the cases, since code in question might be
> scattered across the dirs, or single dir can contain several
> maintainers depending on the subject.

In such case it would require the code owner to add multiple
F: fields for all of the dirs and files.

To simplify selecting multiple files we would allow
wildcard matching (globing patterns) at the end of the path

F: (lib/Bitcode/* include/llvm/Bitcode/*)

F: (include/llvm/*.h)

Since code ownership might overlap files and dirs we
should allow F: field to express that.

Code owner tool could easily walk-up the hierarchy
until it reduces the number of owners to 1 or 2.

> 
>>  Therefor I have no choice but to suspend
>> accepting all of the 3.2 patches until the
>> situation gets resolved.
> I'd expect from release manager to understand the llvm/clang internal
> organization and deduce the correct owner in most cases.

Understanding the internal llvm/clang structure is easy,
deducing the correct code owner is not due to the
vague and changing nature of the CODE_OWNERS.TXT


"Exception handling, Windows codegen, ARM EABI"



> 
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> 
> 


Pawel