I would suggest making sub-projects for each of the distributions and then
use git submodules to tie it all together at the build level.
That way, you can restrict write access to particular users.
Alternatively, you could use protected branches and allow branch
maintainers to manage those and have a small set of core mergers that bring
it into the mainline.
On Mon, Nov 21, 2016 at 12:45 PM, Shawn Wells <shawn(a)redhat.com> wrote:
SSG originated from NSA. They collaborated with Red Hat to help build
community and author content for RHEL. The community has since expanded --
both in terms of people from across the world and content beyond Red Hat
related things. Success!
As our community and content expands, we should figure out how to handle
commit access to the SSG repo. Some 95 people have submitted code patches
to SSG . 18 of them have currently have commit/merge access. The vast
majority of the merge-access group are Red Hat staff, followed by trusted
partners like Gabe/redhatrises and Joe/joenall, a then smidge of government
(NSA, DISA FSO).
With content being developed and maintained for Ubuntu and WRLinux, I
think it makes sense to those "core maintainers" commit access. These are
the people who care most deeply for that body of content and have shown
good judgement to determine what's best for the overall code base, their
particularly content of interest, and broader community. These individuals
would still follow normal PR processes for their own code, but could merge
PRs of others.
IMHO, the "Managing Participants" section of Karl Fogel's 'Producing
Source Software' book has a well thought out approach:
In short: *It's not about complexity or frequency or code contributions
because there are many non-programmer contributors. Elevate privileges of
those who show good judgement and community stewardship.*
Then there's the procedural side. Who has a say in who gets commit access?
Where does deliberation happen? Having a 'public vote' on the mailing list
risks turning into a popularity contest. Having a 'secret council' risks
loosing community trust. Both situations are equally unappealing. I'm not
really sure to handle this. And I recognize I'm likely over thinking this!
Historically, it has been fairly apparent who should get merge access and
when. Generally these decisions were met by the community with "yeah,
$person totally makes sense!" Access was granted by Jeff Blank or myself
after we ran it by a few other communicate members. Simon (now Martin)
maintain appropriate accesses for the full-time Red Hat engineers. This
model has worked well for us so I propose keeping with it. The guiding
principal remains good judgement and community stewardship.
We now have many new community members and several new bodies of content
being developed. Even if we remain on the same process it seems healthy to
revisit the conversation on-list.
scap-security-guide mailing list -- scap-security-guide@lists.
To unsubscribe send an email to scap-security-guide-leave@
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --