Hi Martin, The reason that I'm suggesting this approach is twofold.
First, people are *really* nervous about screwing up someone else's material when they dive into a monolithic repository. I've had several people comment on how, while they hate the fact that we have 100+ repos, they like the fact that they can't accidentally mess up the rest of the system. Second, different maintainers have different levels of attentiveness and may want to shoot their master branch out ahead of the pack. I look at the SSG project as a top level project that is concerned with a build structure and several sub-projects that are concerned with various different software components. Therefore, it would be great to be able to independently version control and develop each of the sub-projects and just rely on the top level project as a build infrastructure. Thanks, Trevor On Mon, Nov 28, 2016 at 11:23 AM, Martin Preisler <[email protected]> wrote: > ----- Original Message ----- > > From: "Trevor Vaughan" <[email protected]> > > To: "SCAP Security Guide" <[email protected]> > > Sent: Tuesday, November 22, 2016 9:16:33 AM > > Subject: Re: How should we expand commit access to SSG? > > > > 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. > > I think we can trust people have good intentions and there is no need to > separate access like this. Either we trust the contributors and they can > change anything or we don't trust them and we don't let them push any > commits. > > Many of the changes affect all the products and this separation would > complicate that I think. > > -- > Martin Preisler > Identity Management and Platform Security | Red Hat, Inc. > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide@lists. > fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave@ > lists.fedorahosted.org > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
