[RFC] time to move to github?

Joe Wulf joe_wulf at yahoo.com
Wed Feb 19 03:52:23 UTC 2014


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 at redhat.com>
>To: scap-security-guide at 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 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.
>> 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 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/20140218/56adec0e/attachment-0001.html>


More information about the scap-security-guide mailing list