Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.

On Tue, 23 May 2023, Konstantin Ryabitsev wrote:

> Can you please describe the lifecycle of a patch and how it gets from "user
> sends a change to the mailing list" to "that patch becomes a commit in the
> official project repository where it lives forever."

A patch is sent to the list.  There are some number of review / revision 
rounds, ending with a reviewer or maintainer saying it is OK to commit (or 
OK after some specified changes, or OK in the absence of objections within 
some given period, etc.).  If the person posting the patch has commit 
access, they commit it; otherwise they should ask the maintainer to do so 
for them.  Maintainers of parts of the compiler may commit their patches 
without someone else reviewing them.  (There are also reviewers who can 
approve other people's patches in their area of the compiler but not their 
own - and global reviewers can approve patches anywhere in the compiler.)  
Once someone has had a few good patches approved and committed by someone 
else, they'll probably be asked to complete the form for getting commit 
access, naming the relevant maintainer as approver (only maintainers can 
approve commit access, non-maintainers with commit access can't do so).

Anyone with commit access can create their own branches in their 
refs/users/ namespace if they wish, and use them without needing review 
for commits going there.  Shared development branches under 
refs/heads/devel/ have whatever rules are established by the people 
setting up those branches.

Rules about patch approval are not enforced automatically, only the basic 
checks for certain kinds of problems with commits and for such things as 
non-fast-forward pushes only being allowed in namespaces such as 
refs/users/ and refs/vendors/.

The above is for GCC, but the general idea is similar for other projects, 
with differences of detail in the ref namespaces used, the checks carried 
out on commits and exactly how maintainership works.

-- 
Joseph S. Myers
[email protected]