[RFC] time to move to github?

Graham Williamson graham at williamsonsinc.id.au
Wed Feb 19 12:26:31 UTC 2014


On Mon, 2014-02-17 at 18:19 -0500, 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.
> 
> >
> >
> >>      * 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

Git workflow is definitely something that would need to looked at.  A
similar workflow used by the Fedora infrastructure team is those with
commit access instead create a branch on the various projects repo.  Switch 
to that branch, make changes there, push it back to the remote branch on
github, then submit a pull request from that branch back into maste.  The 
rest of the process is similar, review, ACK'd, someone (any of the github 
members with organization repo commiters) merges the pull request.  The 
branch is typically then deleted by the creator.

> 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.
> 
> 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 Fedora infrastructure team also have written some stuff to sync their 
"upstream" github (fedora-infra) projects back into their infrastructure.  
So we could always pull it back into fedorahosted as a "clean" backup periodically.


> 
> >
> >
> >>      * 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. 
> 
> Thanks,
> --Spencer
> >
> > -Steve
> > _______________________________________________
> > scap-security-guide mailing list
> > scap-security-guide at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140219/0ed83e9b/attachment.sig>


More information about the scap-security-guide mailing list