On 2/19/14, 12:03 PM, Spencer Shimko wrote:
On Wed, Feb 19, 2014 at 11:17 AM, Jeffrey Blank <blank@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.

GitHub forking != forking.

Classically we think of forking as a diversion of community. Upstream sources not meeting the needs of a specialty group, so the special interest forks and does their own thing. Hopefully the SSG community remains responsive and flexible enough to prevent such a condition.

Forking on GitHub is a bit different. Using Greg Elin's GitMachines project as an example, forking SSG on GitHub would allow us to:
- Track that GitMachines forked SSG;
- Establish a parent/child relationship with downstream projects;
- Remind the GitMachine developers that SSG is the upstream for SCAP content, hopefully driving them to submit pathes/bugs

>
> 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.

Exactly. From a consumer standpoint, SSG ships within EPEL and is signed with Red Hat's GPG key. Progress is being made towards shipping in RHEL proper (more on that later today). Association with Red Hat is unquestionable.

We're discussing a developer community change. A different git target that allows us better project management tools.