<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10pt">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.<br>+1 Just do it!<br><br>R,<br>-Joe<div><br></div><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;">  <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 10pt;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1">  <font face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> Shawn Wells &lt;shawn@redhat.com&gt;<br> <b><span style="font-weight: bold;">To:</span></b> scap-security-guide@lists.fedorahosted.org <br> <b><span
 style="font-weight: bold;">Sent:</span></b> Tuesday, February 18, 2014 10:32 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [RFC] time to move to github?<br> </font> </div> <div class="y_msg_container"><br>On 2/17/14, 6:19 PM, Spencer Shimko wrote:<br clear="none">&gt; On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb &lt;<a shape="rect" ymailto="mailto:sgrubb@redhat.com" href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>&gt; wrote:<br clear="none">&gt;&gt; On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote:<br clear="none">&gt;&gt;&gt; As the SSG development community grows, so does the need for matured<br clear="none">&gt;&gt;&gt; tools and workflow. There's been some discussion of moving to GitHub.<br clear="none">&gt;&gt;&gt;<br clear="none">&gt;&gt;&gt; On the pro side:<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * Easier to signup and request commit access<br clear="none">&gt;&gt; Why is this a good thing? Do you
 really want _anybody_ able to commit? There<br clear="none">&gt;&gt; has to be strict sign-off or review before committing code in any security<br clear="none">&gt;&gt; sensitive project.<br clear="none">&gt; The approval process remains similar to the current situation. Just<br clear="none">&gt; because people can signup and request access doesn't mean they are<br clear="none">&gt; granted access.&nbsp; Not everyone can commit that has an account - the<br clear="none">&gt; project owners still grant access.<br clear="none"><br clear="none">Right. GitHub also makes subdivision easier, e.g. commit writes only to <br clear="none">documentation vs core SCAP content.<br clear="none"><br clear="none">On FedoraHosted these would be two project spaces, "SSG Docs," and "SSG <br clear="none">Content." On GitHub we can breakout the repos while retaining easy <br clear="none">access through a central organizational account.<br clear="none"><br
 clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * Most committers likely to have GitHub account for other projects<br clear="none">&gt;&gt;&gt; anyway<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * Easier for community to fork SSG code (e.g. gitmachines project)<br clear="none">&gt;&gt; Again, why is this a good thing? Don't we want everyone making a common core<br clear="none">&gt;&gt; of code better? Or do you want one group to fork the code and do it better and<br clear="none">&gt;&gt; not even tell you there are problems? Keeping everyone in the same boat and<br clear="none">&gt;&gt; rowing in the same direction is better all around.<br clear="none">&gt; Having a central location for decentralized development is pretty<br clear="none">&gt; standard and I know you've been using this model for years on other<br clear="none">&gt; projects.&nbsp; Using the term "fork" might be a sticking point.&nbsp; This<br clear="none">&gt; doesn't necessarily
 mean the traditional connotation where the code<br clear="none">&gt; from one project under active development is used as a starting point<br clear="none">&gt; for a separate project that no longer contributes back to the first<br clear="none">&gt; project at all.&nbsp; In github forking is seen as a good thing and is<br clear="none">&gt; often quite beneficial to the development of the project being forked.<br clear="none">&gt;<br clear="none">&gt; I fork a project on github when I like the project and want to<br clear="none">&gt; contribute a change to the project.&nbsp; I fork the project (read-&gt;clone),<br clear="none">&gt; make my changes, push my changes back to my clone on github, then<br clear="none">&gt; submit a pull request to the project's owner. My change gets reviewed,<br clear="none">&gt; commented on, and hopefully, merged into the upstream to everyone's<br clear="none">&gt; satisfaction.&nbsp; I am making the common core better. In
 reality, this is<br clear="none">&gt; almost exactly like current distributed code development.&nbsp; Except,<br clear="none">&gt; instead of using a mailing list for code review, you use github.<br clear="none">&gt;<br clear="none">&gt; When a github user forks they use the "fork" button.&nbsp; This creates a<br clear="none">&gt; visible trail that you can use to see who has forked and where they've<br clear="none">&gt; gone with it.&nbsp; As a project lead you now know a bit about the people<br clear="none">&gt; who are tracking your project and might be contributing.<br clear="none"><br clear="none">Spencer's correct; the concept if fork is favorable. Additionally, we <br clear="none">can track forks on GitHub however on FedoraHosted we simply have no idea <br clear="none">who downstream communities are.<br clear="none"><br clear="none">&gt; In the end, regardless of where the project is hosted, it is open<br clear="none">&gt; source.&nbsp; You can't
 guarantee that you're going to get a bug report<br clear="none">&gt; propagated upstream. But I think github is more conducive to that<br clear="none">&gt; workflow and you are more likely to have people telling you they're<br clear="none">&gt; contributing via the fork button, and telling you there are problems,<br clear="none">&gt; as opposed to other alternatives.<br clear="none">&gt;<br clear="none">&gt; Also, note that you don't have to use github for code review etc.&nbsp; You<br clear="none">&gt; can use it just for a central repo.&nbsp; Development progress can be made<br clear="none">&gt; on list without using github for review/etc.&nbsp; I am still torn on which<br clear="none">&gt; method I like more for code review. I'd go out on a limb (branch :))<br clear="none">&gt; though and say that github is more likely to receive drive-by bug<br clear="none">&gt; reports and code contributions than a mailing list. A lot of people<br clear="none">&gt;
 just don't want to jump on another ML for a single code change or<br clear="none">&gt; minor issue.<br clear="none"><br clear="none">The flexibility of both mailing list patches + pull requests is very <br clear="none">ideal as we grow in content and community.<br clear="none"><br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * Dramatically better ticketing system<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  - labels<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  - user-friendly GUI<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  - git commit hooks (put ticket # in patch title, auto<br clear="none">&gt;&gt;&gt; resolves ticket)<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  - multi-developer collaboration on tickets easier through<br clear="none">&gt;&gt;&gt; @name calls<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * "Pull
 Request" concept: Patches centrally managed and merged,<br clear="none">&gt;&gt;&gt; ensures no missed patches on mailing list<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * Simplified branching (e.g. allows a -stable and -dev branch).<br clear="none">&gt;&gt;&gt; Possible on FedoraHosted, not as intuitive<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * Increased reliability of infrastructure (especially latency of<br clear="none">&gt;&gt;&gt; git pulls)<br clear="none">&gt;&gt;&gt;<br clear="none">&gt;&gt;&gt; On the cons:<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * Slight developer hassle to migrate SSH keys<br clear="none">&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;  * "Not hosted by RedHat" -- concern from some that migrating from a<br clear="none">&gt;&gt;&gt; redhat/fedora hosted URL will diminish project brand.<br clear="none">&gt;&gt; How good is github? Its got a reputation for code that is anonymously dumped<br clear="none">&gt;&gt; and
 not maintained. Another con, github has been hacked...Fedorahosted, not:<br clear="none">&gt;&gt;<br clear="none">&gt;&gt; <a shape="rect" href="https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation" target="_blank">https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation</a><br clear="none">&gt;&gt;<br clear="none">&gt;&gt; I personally think code provenance and supply chain assurance should trump<br clear="none">&gt;&gt; everything else.<br clear="none">&gt; Don't most source code sites have projects that become unmaintained<br clear="none">&gt; for various reasons?&nbsp; I have passing interests myself, and just<br clear="none">&gt; because I stop using something I wrote doesn't mean I don't want to<br clear="none">&gt; share it, or no longer want it to be shared by others. Unmaintained<br clear="none">&gt; projects come along with an open ecosystem developed by people that<br clear="none">&gt; like to
 share things.&nbsp; Having your project on a site that has projects<br clear="none">&gt; that haven't been committed to in a year doesn't impact the pedigree.<br clear="none">&gt;<br clear="none">&gt; Personally, the reason I like github (etc) is it has great tools and<br clear="none">&gt; features that are rather unique.&nbsp; As I said above, I'm torn on which<br clear="none">&gt; development workflow I like better - github or the traditional mailing<br clear="none">&gt; list approach.&nbsp; But I can say with certainty - these sites have a<br clear="none">&gt; great set of features that draw me to them and make contributing to<br clear="none">&gt; the projects easier and more painless, and I think that says a lot.<br clear="none">&gt;<br clear="none">&gt; Your supply chain assurance shouldn't come from a statement like "the<br clear="none">&gt; site hosting our code hasn't been hacked."&nbsp; There is a long, long list<br clear="none">&gt; of central
 repositories for code that have been compromised and we all<br clear="none">&gt; continue to consume and use code from those sites on a daily basis.<br clear="none">&gt; There are numerous ways to achieve higher assurance in this area,<br clear="none">&gt; development processes that are actually followed, signing commits,<br clear="none">&gt; signing releases, distributed revision control itself, etc. Nothing<br clear="none">&gt; about github detracts from code provenance or supply chain assurance.<br clear="none"><br clear="none">To test things out (as Greg Elin suggested), I merged the code into GitHub:<br clear="none"><a shape="rect" href="https://github.com/ssgproject" target="_blank">https://github.com/ssgproject</a><br clear="none"><br clear="none">It picked up historical changes made by those who have GitHub accounts, e.g:<br clear="none"><a shape="rect" href="https://github.com/ssgproject/content/commits/master/Makefile"
 target="_blank">https://github.com/ssgproject/content/commits/master/Makefile</a><br clear="none"><br clear="none">As mentioned, GutHub can also host HTML pages, giving us a version <br clear="none">controlled repo for the docs. We can CNAME ssgproject.org against this.<br clear="none"><a shape="rect" href="https://github.com/ssgproject/ssgproject.github.io" target="_blank">https://github.com/ssgproject/ssgproject.github.io</a><br clear="none"><a shape="rect" href="http://ssgproject.github.io/" target="_blank">http://ssgproject.github.io/</a><br clear="none"><br clear="none">A few days ago I also played around with the ticket system:<br clear="none"><a shape="rect" href="https://github.com/ssgproject/content/issues" target="_blank">https://github.com/ssgproject/content/issues</a><br clear="none"><br clear="none">IMO, this seems like a much better community site. What's the right way <br clear="none">to go about this -- "just do it," or perhaps setup a
 poll?<div class="yqt4880701923" id="yqtfd27866"><br clear="none">_______________________________________________<br clear="none">scap-security-guide mailing list<br clear="none"><a shape="rect" ymailto="mailto:scap-security-guide@lists.fedorahosted.org" href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br clear="none"><a shape="rect" href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br clear="none"></div><br><br></div> </div> </div> </blockquote><div></div>   </div></body></html>