Greetings all, 

This is my first post, so let me briefly introduce myself before opining on a move to GitHub.

I recently finished 3+ years at the FCC as Chief Data Officer. Before that, I started up the Sunlight Labs at the Sunlight Foundation (a 21st century non-profit using Internet for greater government transparency). I actively work with data and write code. I'm currently pursuing a GitMachines with funding from the Knight Foundation to develop accreditation-ready virtual machines to bridge the security (and certification) gap between government IT Administrators and Civic Tech Innovators.

Getting hooked up scap-security on Fedora Projects felt confusing. I had to understand Fedora vs Fedora Projects vs Repos. GitHub always felt much easier than source forge to get and keep up with a repo. I can understand GitHub would also be confusing to start using to manage a repo, but GitHub requires very little knowledge to checkout or clone a repo. 

I've touched CVS, I used SVN for a few years. Now I use Git (and GitHub) and I don't look back. 

If there is a real question about the transition, I'd recommend a learning adventure with one or two projects on GitHub first. (I'm big on learning before doing.)

I'm not worried about GitHub being hacked -- As good practice, I keep my own pristine clones of the repo so I can do disaster recovery.

I'm not worried about quality control, because only people I approve can commit code; pull requests make code commits very transparent; and Git in general makes commits easier to track.

I spend much of my day with two or more GitHub windows open. GitHub issues support drag and drop image uploading (e.g., screenshots) which is fantastic for sharing information. GitHub also automatically renders markdown and geoJson [1]. Gists are incredibly helpful for sharing snippets of code. 

GitHub's notifications can be controlled very granularly allowing you to easily track via your notification page or email repos, individual issues, and whenever your GitHub handle is mentioned. It's easy to stay up to date in multiple repos.

GitHub's pull-requests provide significant transparency for managing contributions. A pull request is request to contribute code. Code contributions to a repo can only be done ONE way: by an individual who has been explicitly granted contribution rights. However, other persons who have not been granted contributor access can request a specific change set (e.g., commit) be reviewed an "pulled" into your repo. Anyone can request, but only the repo authorized maintainers can approve. GitHub pull-request workflow displays graphically the diff what what is changed by the pull request. It's common to get pull requests to correct documentation, or to fix a single bug. Pull requests can also be easily-mapped to issues.  

When I think about open source, I used to think about the licensing infrastructure that supports the easier collaboration around intellectual property. Now I also think about the code versioning infrastructure of Git and GitHub that supports the easier collaboration around writing and reviewing code. 

Clay Shirky gives an interesting 20 minute talk on Git and GitHub where he describes GitHub as a new form of arguing [2]. It also touches on government so is worth watching. 

Github is making a bigger push into government in general, too [3]. 

And finally, Git and GitHub think about code management fundamentally different from other repos. Here's Linus Torvald describing these differences. He also discusses the security issue and networks of trust about 26 minutes in.

[1] https://help.github.com/articles/mapping-geojson-files-on-github
[2] http://www.ted.com/talks/clay_shirky_how_the_internet_will_one_day_transform_government.html
[3] http://government.github.com/
[4] http://www.youtube.com/watch?v=4XpnKHJAok8

Greg Elin
personal cell: 917-304-3488
personal email: greg@fotonotes.net
email: gregelin@gitmachines.com











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.


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


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

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