On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb <[email protected]> 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 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. > > >> * 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
