These posts lay things out nicely as to the pros and cons, while also telling people it is gonna happen for the good of the community.
+1 Just do it!

R,
-Joe


From: Shawn Wells <shawn@redhat.com>
To: scap-security-guide@lists.fedorahosted.org
Sent: Tuesday, February 18, 2014 10:32 PM
Subject: Re: [RFC] time to move to github?

On 2/17/14, 6:19 PM, Spencer Shimko wrote:
> On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> On Sunday, February 16, 2014 04:03:24 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
>> Why is this a good thing? Do you really want _anybody_ able to commit? There
>> has to be strict sign-off or review before committing code in any security
>> sensitive project.
> The approval process remains similar to the current situation. Just
> because people can signup and request access doesn't mean they are
> granted access.  Not everyone can commit that has an account - the
> project owners still grant access.

Right. GitHub also makes subdivision easier, e.g. commit writes only to
documentation vs core SCAP content.

On FedoraHosted these would be two project spaces, "SSG Docs," and "SSG
Content." On GitHub we can breakout the repos while retaining easy
access through a central organizational account.

>>>      * Most committers likely to have GitHub account for other projects
>>> anyway
>>>      * Easier for community to fork SSG code (e.g. gitmachines project)
>> Again, why is this a good thing? Don't we want everyone making a common core
>> of code better? Or do you want one group to fork the code and do it better and
>> not even tell you there are problems? Keeping everyone in the same boat and
>> rowing in the same direction is better all around.
> Having a central location for decentralized development is pretty
> standard and I know you've been using this model for years on other
> projects.  Using the term "fork" might be a sticking point.  This
> doesn't necessarily mean the traditional connotation where the code
> from one project under active development is used as a starting point
> for a separate project that no longer contributes back to the first
> project at all.  In github forking is seen as a good thing and is
> often quite beneficial to the development of the project being forked.
>
> I fork a project on github when I like the project and want to
> contribute a change to the project.  I fork the project (read->clone),
> make my changes, push my changes back to my clone on github, then
> submit a pull request to the project's owner. My change gets reviewed,
> commented on, and hopefully, merged into the upstream to everyone's
> satisfaction.  I am making the common core better. In reality, this is
> almost exactly like current distributed code development.  Except,
> instead of using a mailing list for code review, you use github.
>
> When a github user forks they use the "fork" button.  This creates a
> visible trail that you can use to see who has forked and where they've
> gone with it.  As a project lead you now know a bit about the people
> who are tracking your project and might be contributing.

Spencer's correct; the concept if fork is favorable. Additionally, we
can track forks on GitHub however on FedoraHosted we simply have no idea
who downstream communities are.

> In the end, regardless of where the project is hosted, it is open
> source.  You can't guarantee that you're going to get a bug report
> propagated upstream. But I think github is more conducive to that
> workflow and you are more likely to have people telling you they're
> contributing via the fork button, and telling you there are problems,
> as opposed to other alternatives.
>
> Also, note that you don't have to use github for code review etc.  You
> can use it just for a central repo.  Development progress can be made
> on list without using github for review/etc.  I am still torn on which
> method I like more for code review. I'd go out on a limb (branch :))
> though and say that github is more likely to receive drive-by bug
> reports and code contributions than a mailing list. A lot of people
> just don't want to jump on another ML for a single code change or
> minor issue.

The flexibility of both mailing list patches + pull requests is very
ideal as we grow in content and community.

>>>      * 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.
>> How good is github? Its got a reputation for code that is anonymously dumped
>> and not maintained. Another con, github has been hacked...Fedorahosted, not:
>>
>> https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation
>>
>> I personally think code provenance and supply chain assurance should trump
>> everything else.
> Don't most source code sites have projects that become unmaintained
> for various reasons?  I have passing interests myself, and just
> because I stop using something I wrote doesn't mean I don't want to
> share it, or no longer want it to be shared by others. Unmaintained
> projects come along with an open ecosystem developed by people that
> like to share things.  Having your project on a site that has projects
> that haven't been committed to in a year doesn't impact the pedigree.
>
> Personally, the reason I like github (etc) is it has great tools and
> features that are rather unique.  As I said above, I'm torn on which
> development workflow I like better - github or the traditional mailing
> list approach.  But I can say with certainty - these sites have a
> great set of features that draw me to them and make contributing to
> the projects easier and more painless, and I think that says a lot.
>
> Your supply chain assurance shouldn't come from a statement like "the
> site hosting our code hasn't been hacked."  There is a long, long list
> of central repositories for code that have been compromised and we all
> continue to consume and use code from those sites on a daily basis.
> There are numerous ways to achieve higher assurance in this area,
> development processes that are actually followed, signing commits,
> signing releases, distributed revision control itself, etc. Nothing
> about github detracts from code provenance or supply chain assurance.

To test things out (as Greg Elin suggested), I merged the code into GitHub:
https://github.com/ssgproject

It picked up historical changes made by those who have GitHub accounts, e.g:
https://github.com/ssgproject/content/commits/master/Makefile

As mentioned, GutHub can also host HTML pages, giving us a version
controlled repo for the docs. We can CNAME ssgproject.org against this.
https://github.com/ssgproject/ssgproject.github.io
http://ssgproject.github.io/

A few days ago I also played around with the ticket system:
https://github.com/ssgproject/content/issues

IMO, this seems like a much better community site. What's the right way
to go about this -- "just do it," or perhaps setup a poll?

_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide