[RFC] time to move to github?

Greg Elin gregelin at gitmachines.com
Mon Feb 17 17:39:44 UTC 2014


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 at fotonotes.net
email: gregelin at gitmachines.com











On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb <sgrubb at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140217/6448c74b/attachment.html>


More information about the scap-security-guide mailing list