On Wed, Feb 19, 2014 at 11:17 AM, Jeffrey Blank <blank(a)eclipse.ncsc.mil> 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
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
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