[fab] Re: "community maintainers working on core" dilemma

[Warren Togami]

Thorsten Leemhuis wrote:
> [...]
>> The next question, then: what processes can we put in place that will
>> allow trusted community developers to submit patches in a "fast track"  
>> way, such that the official RH maintainer can simply take a quick look,
>> rebuild, and release?
> 
> My preferred variant:
> 
> 1. community developer commits his changes to a version control system
> somewhere
> 2. he sends some kind of pull request to the red hat maintainer
> 3. red hat maintainer looks at the changes
> 3a) he doesn't like them -- he mails the community maintainer some
> reasons why he doesn't like them
> 3b) he likes them -- he pulls them and queues build

The Core+Extras merge combined with the move to a distributed VCS would 
allow something like this.

With distributed VCS, *anybody* can make a copy of the repo, make local 
changes, and somebody else with access can check everything before 
checking it in.

I envision the Core+Extras merge to work something like this below. 
"Core" and "Extras" names are used only to compare to today.

1) All packages have ACL's
2) "Core" package ACL's generally open to Red Hat engineers and a 
certain higher rank of "Extras" contributors, like sponsors. 
(Case-by-case basis on ACL restrictiveness.  Like gcc or kernel would be 
very tight, but GNOME would be pretty open.)
3) Multiple owners are possible for each package.  Generally each "Core" 
package has both a Red Hat and Fedora community owner.  Upstream 
developers could be added too.
4) Entire SIG's could own packages group.
5) The package universe expands in concentric circles, with stuff 
further out from "Core" with less and less restrictive ACL's.

Distributed VCS clones and approval through somebody else with access is 
only necessary for contributors who have not yet earned a higher "rank" 
with direct ACL access to a certain package.

Warren Togami
wtogami at redhat.com