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

[Hal Finkel]

----- Original Message -----
> From: "Bill Wendling" <wendling at apple.com>
> To: "Pawel Wodnicki" <root at 32bitmicro.com>
> Cc: "llvmdev" <llvmdev at cs.uiuc.edu>, "clang-dev Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Friday, November 16, 2012 6:19:30 PM
> Subject: Re: [LLVMdev] [cfe-dev] !!! 3.2 Release branch patching and the	Code Owners
> 
> On Nov 16, 2012, at 3:52 PM, Pawel Wodnicki <root at 32bitmicro.com>
> wrote:
> 
> > 
> >>> 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.
> 
> 
> For this release, please just use the CODE_OWNERS.TXT file from 3.1.

I don't think this helps the situation. Part of the point of declaring new code owners was to help with the 3.2 release process. If these designations are ambiguous, then we should make them more specific, or, make it the responsibility of the requester to identify the appropriate code owner(s) in the request. 

 -Hal

> 
> -bw
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory