On 2/17/14, 6:19 PM, Spencer Shimko wrote:
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb
<sgrubb(a)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-mitiga...
>
> 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?