On Wed, Feb 19, 2014 at 11:17 AM, Jeffrey Blank <[email protected]> wrote: > This is a very interesting question. > > From my perspective, the greatest pro is improved project management > options on GitHub (easier branching etc). The others are fairly minor > (and many are resolved by viewing the project wiki). > > I am not sure I view one thing listed as a "pro" to be such, and this is > the ease of forking. I do not want a variety of government agencies > creating Frankenstein forks of scap-security-guide. I want them to use > the profiling mechanisms of XCCDF to select what they need from a single > high-quality dictionary of compliance checks (for each product for which > such content exists). One of the unstated goals of the project is to > keep the variety of government compliance machines under some control by > providing a solution which meets >95% of use cases.
Nothing prevents them from forking now and hosting it on an internal system, forge.mil, etc. This is an open source project, and text-based to begin with, so I think preventing forks by using Fedora Hosted is a losing battle. If you're worried that other source code repositories containing SSG content may confuse people, that is possible. However, I believe the targeted consumers of the SSG content will get it from vendors who know where the proper upstream project resides and knows to pull the content from their repository. > > Also, the association of the project with Red Hat (in this case, by > providing hosting) is very important from the Government perspective, > which I represent. Based on interactions on other lists like MIL-OSS and Gov-Sec I think what a lot of the Government customers care about is that it is packaged, shipped, and supported by Red Hat. I might be wrong on this, but there doesn't seem to be a lot of questions raised regarding the site used to host the source code during development. Thanks, --Spencer > > So, I am not totally convinced of the value in doing this...yet. But it > deserves thorough consideration, and I look forward to more discussion. > > > > On 02/16/2014 04:03 PM, Shawn Wells wrote: >> As the SSG development community grows, so does the need for matured >> tools and workflow. There's been some discussion of moving to GitHub. >> >> On the pro side: >> * Easier to signup and request commit access >> * Most committers likely to have GitHub account for other projects >> anyway >> * Easier for community to fork SSG code (e.g. gitmachines project) >> * Dramatically better ticketing system >> - labels >> - user-friendly GUI >> - git commit hooks (put ticket # in patch title, auto >> resolves ticket) >> - multi-developer collaboration on tickets easier through >> @name calls >> * "Pull Request" concept: Patches centrally managed and merged, >> ensures no missed patches on mailing list >> * Simplified branching (e.g. allows a -stable and -dev branch). >> Possible on FedoraHosted, not as intuitive >> * Increased reliability of infrastructure (especially latency of git >> pulls) >> >> On the cons: >> * Slight developer hassle to migrate SSH keys >> * "Not hosted by RedHat" -- concern from some that migrating from a >> redhat/fedora hosted URL will diminish project brand. >> >> What does everyone think? >> >> _______________________________________________ >> scap-security-guide mailing list >> [email protected] >> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide -- Spencer Shimko Quark Security, Inc quarksecurity.com O: 443-457-8275 x1000 M: 858-877-3623 _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
