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 * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * 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.
What does everyone think?
On Feb 16, 2014, at 4:03 PM, Shawn Wells shawn@redhat.com 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
- Most committers likely to have GitHub account for other projects anyway
- Easier for community to fork SSG code (e.g. gitmachines project)
- 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.
What does everyone think?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I hate seeing projects move away from fedorahosted because I know that they want to be a premier hosting platform.
But all of the cons are very minor and the pros are significant. Additionally, github would also provide a way for hosting some of the artifacts from the repo such as the HTML versions of the guide.
-josh
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.
* 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.
* 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-mitigatio...
I personally think code provenance and supply chain assurance should trump everything else.
-Steve
On 02/16/2014 10:37 PM, Steve Grubb 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.
* 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.
* 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-mitigatio...
I personally think code provenance and supply chain assurance should trump everything else.
-Steve _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Another option would be to utilize github for collaboration but maintain fedorahosted as the authoritative source.
-josh
Greetings all,
This is my first post, so let me briefly introduce myself before opining on a move to GitHub.
I recently finished 3+ years at the FCC as Chief Data Officer. Before that, I started up the Sunlight Labs at the Sunlight Foundation (a 21st century non-profit using Internet for greater government transparency). I actively work with data and write code. I'm currently pursuing a GitMachines with funding from the Knight Foundation to develop accreditation-ready virtual machines to bridge the security (and certification) gap between government IT Administrators and Civic Tech Innovators.
Getting hooked up scap-security on Fedora Projects felt confusing. I had to understand Fedora vs Fedora Projects vs Repos. GitHub always felt much easier than source forge to get and keep up with a repo. I can understand GitHub would also be confusing to start using to manage a repo, but GitHub requires very little knowledge to checkout or clone a repo.
I've touched CVS, I used SVN for a few years. Now I use Git (and GitHub) and I don't look back.
If there is a real question about the transition, I'd recommend a learning adventure with one or two projects on GitHub first. (I'm big on learning before doing.)
I'm not worried about GitHub being hacked -- As good practice, I keep my own pristine clones of the repo so I can do disaster recovery.
I'm not worried about quality control, because only people I approve can commit code; pull requests make code commits very transparent; and Git in general makes commits easier to track.
I spend much of my day with two or more GitHub windows open. GitHub issues support drag and drop image uploading (e.g., screenshots) which is fantastic for sharing information. GitHub also automatically renders markdown and geoJson [1]. Gists are incredibly helpful for sharing snippets of code.
GitHub's notifications can be controlled very granularly allowing you to easily track via your notification page or email repos, individual issues, and whenever your GitHub handle is mentioned. It's easy to stay up to date in multiple repos.
GitHub's pull-requests provide significant transparency for managing contributions. A pull request is request to contribute code. Code contributions to a repo can only be done ONE way: by an individual who has been explicitly granted contribution rights. However, other persons who have not been granted contributor access can request a specific change set (e.g., commit) be reviewed an "pulled" into your repo. Anyone can request, but only the repo authorized maintainers can approve. GitHub pull-request workflow displays graphically the diff what what is changed by the pull request. It's common to get pull requests to correct documentation, or to fix a single bug. Pull requests can also be easily-mapped to issues.
When I think about open source, I used to think about the licensing infrastructure that supports the easier collaboration around intellectual property. Now I also think about the code versioning infrastructure of Git and GitHub that supports the easier collaboration around writing and reviewing code.
Clay Shirky gives an interesting 20 minute talk on Git and GitHub where he describes GitHub as a new form of arguing [2]. It also touches on government so is worth watching.
Github is making a bigger push into government in general, too [3].
And finally, Git and GitHub think about code management fundamentally different from other repos. Here's Linus Torvald describing these differences. He also discusses the security issue and networks of trust about 26 minutes in.
[1] https://help.github.com/articles/mapping-geojson-files-on-github [2] http://www.ted.com/talks/clay_shirky_how_the_internet_will_one_day_transform... [3] http://government.github.com/ [4] http://www.youtube.com/watch?v=4XpnKHJAok8
Greg Elin personal cell: 917-304-3488 personal email: greg@fotonotes.net email: gregelin@gitmachines.com
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb sgrubb@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.
* 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.
* 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-mitigatio...
I personally think code provenance and supply chain assurance should trump everything else.
-Steve _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb sgrubb@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 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-mitigatio...
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 2/17/14, 6:19 PM, Spencer Shimko wrote:
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb sgrubb@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-mitigatio...
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?
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@redhat.com To: scap-security-guide@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@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-mitigatio...
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Tue, 2014-02-18 at 22:32 -0500, Shawn Wells wrote:
On 2/17/14, 6:19 PM, Spencer Shimko wrote:
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb sgrubb@redhat.com wrote:
On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote:
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?
I want to say +1 "just do it", but I think poll might actually be the best way forward. Because if everyone isn't onboard, then this could possibly be the start of a slow downward spiral.
I vote Aye.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
So, while you're moving stuff to github, can you get Mcnos to open that up, as well as sourceforge?
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Graham Williamson Sent: Wednesday, February 19, 2014 7:36 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: [RFC] time to move to github?
On Tue, 2014-02-18 at 22:32 -0500, Shawn Wells wrote:
On 2/17/14, 6:19 PM, Spencer Shimko wrote:
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb sgrubb@redhat.com wrote:
On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote:
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?
I want to say +1 "just do it", but I think poll might actually be the best way forward. Because if everyone isn't onboard, then this could possibly be the start of a slow downward spiral.
I vote Aye.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Aye!
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Feb 19, 2014, at 7:35 AM, Graham Williamson graham@williamsonsinc.id.au wrote:
On Tue, 2014-02-18 at 22:32 -0500, Shawn Wells wrote:
On 2/17/14, 6:19 PM, Spencer Shimko wrote:
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb sgrubb@redhat.com wrote:
On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote:
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?
I want to say +1 "just do it", but I think poll might actually be the best way forward. Because if everyone isn't onboard, then this could possibly be the start of a slow downward spiral.
I vote Aye.
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Mon, 2014-02-17 at 18:19 -0500, Spencer Shimko wrote:
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb sgrubb@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-mitigatio...
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
I must say that I'm a big fan of GitHub in general.
The SSH key migration issue isn't much of an issue as the startup guide easily runs you through the steps.
Not hosted by RedHat is kind of a pro/con. On the one hand, you might end up with some brand diminishing but, on the other, you might end up with more people using other OSs contributing to the project. When things are in FedoraHosted, they tend to be thought of as Red Hat only. (This is a community pro, not necessarily a Red Hat pro).
Also, with their recent team-up with Gerrit http://gerrithub.io/, I'm even more of a fan.
I will say that I've found more projects just trolling through GitHub than I have FedoraHosted.
Trevor
On Sun, Feb 16, 2014 at 4:03 PM, Shawn Wells shawn@redhat.com 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 * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * 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.
What does everyone think?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
This is a very interesting question.
From my perspective, the greatest pro is improved project management
options on GitHub (easier branching etc). The others are fairly minor (and many are resolved by viewing the project wiki).
I am not sure I view one thing listed as a "pro" to be such, and this is the ease of forking. I do not want a variety of government agencies creating Frankenstein forks of scap-security-guide. I want them to use the profiling mechanisms of XCCDF to select what they need from a single high-quality dictionary of compliance checks (for each product for which such content exists). One of the unstated goals of the project is to keep the variety of government compliance machines under some control by providing a solution which meets >95% of use cases.
Also, the association of the project with Red Hat (in this case, by providing hosting) is very important from the Government perspective, which I represent.
So, I am not totally convinced of the value in doing this...yet. But it deserves thorough consideration, and I look forward to more discussion.
On 02/16/2014 04:03 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 * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * 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.
What does everyone think?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Wed, Feb 19, 2014 at 11:17 AM, Jeffrey Blank blank@eclipse.ncsc.mil wrote:
This is a very interesting question.
From my perspective, the greatest pro is improved project management options on GitHub (easier branching etc). The others are fairly minor (and many are resolved by viewing the project wiki).
I am not sure I view one thing listed as a "pro" to be such, and this is the ease of forking. I do not want a variety of government agencies creating Frankenstein forks of scap-security-guide. I want them to use the profiling mechanisms of XCCDF to select what they need from a single high-quality dictionary of compliance checks (for each product for which such content exists). One of the unstated goals of the project is to keep the variety of government compliance machines under some control by providing a solution which meets >95% of use cases.
Nothing prevents them from forking now and hosting it on an internal system, forge.mil, etc. This is an open source project, and text-based to begin with, so I think preventing forks by using Fedora Hosted is a losing battle.
If you're worried that other source code repositories containing SSG content may confuse people, that is possible. However, I believe the targeted consumers of the SSG content will get it from vendors who know where the proper upstream project resides and knows to pull the content from their repository.
Also, the association of the project with Red Hat (in this case, by providing hosting) is very important from the Government perspective, which I represent.
Based on interactions on other lists like MIL-OSS and Gov-Sec I think what a lot of the Government customers care about is that it is packaged, shipped, and supported by Red Hat. I might be wrong on this, but there doesn't seem to be a lot of questions raised regarding the site used to host the source code during development.
Thanks, --Spencer
So, I am not totally convinced of the value in doing this...yet. But it deserves thorough consideration, and I look forward to more discussion.
On 02/16/2014 04:03 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 * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * 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.
What does everyone think?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 2/19/14, 12:03 PM, Spencer Shimko wrote:
On Wed, Feb 19, 2014 at 11:17 AM, Jeffrey Blankblank@eclipse.ncsc.mil wrote:
This is a very interesting question.
From my perspective, the greatest pro is improved project management options on GitHub (easier branching etc). The others are fairly minor (and many are resolved by viewing the project wiki).
I am not sure I view one thing listed as a "pro" to be such, and this is the ease of forking. I do not want a variety of government agencies creating Frankenstein forks of scap-security-guide. I want them to use the profiling mechanisms of XCCDF to select what they need from a single high-quality dictionary of compliance checks (for each product for which such content exists). One of the unstated goals of the project is to keep the variety of government compliance machines under some control by providing a solution which meets >95% of use cases.
Nothing prevents them from forking now and hosting it on an internal system, forge.mil, etc. This is an open source project, and text-based to begin with, so I think preventing forks by using Fedora Hosted is a losing battle.
If you're worried that other source code repositories containing SSG content may confuse people, that is possible. However, I believe the targeted consumers of the SSG content will get it from vendors who know where the proper upstream project resides and knows to pull the content from their repository.
GitHub forking != forking.
Classically we think of forking as a diversion of community. Upstream sources not meeting the needs of a specialty group, so the special interest forks and does their own thing. Hopefully the SSG community remains responsive and flexible enough to prevent such a condition.
Forking on GitHub is a bit different. Using Greg Elin's GitMachines project as an example, forking SSG on GitHub would allow us to: - Track that GitMachines forked SSG; - Establish a parent/child relationship with downstream projects; - Remind the GitMachine developers that SSG is the upstream for SCAP content, hopefully driving them to submit pathes/bugs
Also, the association of the project with Red Hat (in this case, by providing hosting) is very important from the Government perspective, which I represent.
Based on interactions on other lists like MIL-OSS and Gov-Sec I think what a lot of the Government customers care about is that it is packaged, shipped, and supported by Red Hat. I might be wrong on this, but there doesn't seem to be a lot of questions raised regarding the site used to host the source code during development.
Exactly. From a /consumer/ standpoint, SSG ships within EPEL and is signed with Red Hat's GPG key. Progress is being made towards shipping in RHEL proper (more on that later today). Association with Red Hat is unquestionable.
We're discussing a /developer/ community change. A different git target that allows us better project management tools.
Forking on GitHub is a bit different. Using Greg Elin's GitMachines project as an example, forking SSG on GitHub would allow us to:
- Track that GitMachines forked SSG;
- Establish a parent/child relationship with downstream projects;
- Remind the GitMachine developers that SSG is the upstream for SCAP
content, hopefully driving them to submit pathes/bugs
This process could help facilitate synchronization between the SSG and the STIG.
If Steve Grubb has reservations, however, that should give pause.
Regards, -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
Yes -- it is highly desirable to have a fully transparent view of the relationship between SSG and the STIG, as FSO is a major issuer of security baselines.
Things have been very successful in that regard so far, and description of how they could get better (to address where/why any semantic differences would creep in) is most welcome.
On 02/19/2014 12:50 PM, Steinke, Leland J Sr CTR DISA FSO (US) wrote:
Forking on GitHub is a bit different. Using Greg Elin's GitMachines project as an example, forking SSG on GitHub would allow us to:
- Track that GitMachines forked SSG;
- Establish a parent/child relationship with downstream projects;
- Remind the GitMachine developers that SSG is the upstream for SCAP
content, hopefully driving them to submit pathes/bugs
This process could help facilitate synchronization between the SSG and the STIG.
If Steve Grubb has reservations, however, that should give pause.
Regards,
Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 02/19/2014 11:17 AM, Jeffrey Blank wrote:
I do not want a variety of government agencies creating Frankenstein forks of scap-security-guide.
I am unsure whether this is worthy of a fork, but read on.
I want them to use the profiling mechanisms of XCCDF to select what they need from a single high-quality dictionary of compliance checks (for each product for which such content exists). One of the unstated goals of the project is to keep the variety of government compliance machines under some control by providing a solution which meets >95% of use cases.
Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected.
A <Profile> cannot alter the role² attribute of a <Rule> (to unscored rather than full).
We intend to do this using a modified benchmark containing a single <Profile>, and applying arbitrary "profiles" to the evaluation results at a subsequent time.
This is most easily done using a fork describing the necessary changes. A fork may also ease the task of having a single checklist for RHEL6 and RHEL7 comprised of parts common to both as well as parts peculiar to either.
Regards,
Gary
-- ¹ Actually most, as we will not traipse through terabytes of local storage looking for unowned files, e.g. ² Goes back a ways: http://making-security-measurable.1364806.n2.nabble.com/role-unchecked-error....
On 2/19/14, 2:39 PM, Gary Gapinski wrote:
On 02/19/2014 11:17 AM, Jeffrey Blank wrote:
I do not want a variety of government agencies creating Frankenstein forks of scap-security-guide.
I am unsure whether this is worthy of a fork, but read on.
I want them to use the profiling mechanisms of XCCDF to select what they need from a single high-quality dictionary of compliance checks (for each product for which such content exists). One of the unstated goals of the project is to keep the variety of government compliance machines under some control by providing a solution which meets >95% of use cases.
Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected.
A <Profile> cannot alter the role² attribute of a <Rule> (to unscored rather than full).
We intend to do this using a modified benchmark containing a single <Profile>, and applying arbitrary "profiles" to the evaluation results at a subsequent time.
Will SCAP Workbench make this any easier for you?
This is most easily done using a fork describing the necessary changes. A fork may also ease the task of having a single checklist for RHEL6 and RHEL7 comprised of parts common to both as well as parts peculiar to either.
wrt a single checklist, much of that work could be accomplished by adjusting the OVAL. Patches would be very, very welcome.
On 02/19/2014 06:04 PM, Shawn Wells wrote:
On 2/19/14, 2:39 PM, Gary Gapinski wrote:
We intend to do this using a modified benchmark containing a single <Profile>, and applying arbitrary "profiles" to the evaluation results at a subsequent time.
Will SCAP Workbench make this any easier for you?
I am unsure.
Currently, a variant XCCDF document is produced using a (XSL) transform of the original XCCDF document driven by a document containing a set of changes identifying insert/modify/delete targets using XPath references to the original. The changes include <Benchmark> descendant-or-self element and attribute alterations (e.g., id, <title>, <description>, <version>, <platform>, etc.), <Profile> excision and insertion, <Value> modifications, <Rule> role specification, in a few cases <Rule>-specific <platform> insertion, <Group>/<Rule> excision, and OCIL excision. The OVAL document remains unchanged; the CPE related documents are manually altered to address CentOS. The altered SCAP bundle is then provided to the compliance metrics infrastructure.
This is tedious. Performed in order to maintain (in)fidelity to the original and to avoid maintaining a distinct XCCDF document (though I remain open to that variation as it may approach equal pain at some later time). Particularly awkward due to XCCDF shortcomings: e.g., a <Profile> lacks precise control of all aspects of changes, and <select>, <set|refine-value>, <Value>+<value>, and <Rule> elements are in the same solar system but on different planets, in communion solely via paranormal channels. Much easier would be a simple list of desired checklist items where all attributes of an item were specified together (particularly <value>(s)).
This is most easily done using a fork describing the necessary changes. A fork may also ease the task of having a single checklist for RHEL6 and RHEL7 comprised of parts common to both as well as parts peculiar to either.
wrt a single checklist, much of that work could be accomplished by adjusting the OVAL. Patches would be very, very welcome.
Complexity increases due to the SSG split into RHEL 6 and 7 branches. While some version-specific OVAL will be needed, most checklist items (XCCDF rules) are not version-specific (many are not even distribution-specific).
An à la carte approach would be easier were individual security posture items defined, then elaborated upon for different venues (e.g., password complexity, with subordinate platform- and version-specific checks).
Such ease would of course facilitate unorthodox compilations.
Hello Gary, Martin,
----- Original Message -----
From: "Gary Gapinski" gapinski@nasa.gov To: scap-security-guide@lists.fedorahosted.org Sent: Wednesday, February 19, 2014 8:39:39 PM Subject: Re: [RFC] time to move to github?
On 02/19/2014 11:17 AM, Jeffrey Blank wrote:
I do not want a variety of government agencies creating Frankenstein forks of scap-security-guide.
I am unsure whether this is worthy of a fork, but read on.
I want them to use the profiling mechanisms of XCCDF to select what they need from a single high-quality dictionary of compliance checks (for each product for which such content exists). One of the unstated goals of the project is to keep the variety of government compliance machines under some control by providing a solution which meets >95% of use cases.
Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected.
Gary, if I got your use case from this (and your subsequent email from today) correctly, the request being as follows: * on one hand to have a "profile / checklist" of all rules (grepped by their uniqueness) that ever existed for RHEL {6,7} products. All rules would be selected by default, and * to have possibility to score only subset of them during scan
(feel free to correct me if I didn't the request details properly).
Projected into scap-workbench functionality this means: * have possibility to merge various profiles (by grepping various but only unique rules), * have possibility how to specify the subset of rules (within that resulting checklist) that should be scored during scan.
scap-workbench (SW) currently supports tailoring (e.g. a way how to select subset of rules from particular profile into new one). From that implies to me that the first point could be (possibly) reached with currently supported SW functionality as follows: 1) Select particular profile. Use tailoring. Select all rules from it, and save it. 2) Load another profile in the "Profile:" field of the SW section, load the previously saved tailoring file, and click customize. Naive view suggests SW should in that scenario allow to add rules from the selected profile to the original tailoring (but didn't try it, so might be wrong)
If not (Cc-ing Martin for hint on this), there should be a SW ticket: [1] https://fedorahosted.org/scap-workbench/newticket
created for this enhancement (please note you need to be logged in to be able to file new SW ticket).
For what is worthy regarding selecting just of a subset of rules, that should be scored during the scan, I don't think this is currently supported / possible in SW (Martin pls correct me here too). => This would need another ticket to be filed to cover this scenario.
To sum up: * either "merging of rules" is currently supported in SW already, and you could perform as described above. Or an RFE should be filed for it this to be possible in the future (let me know, if I should file that ticket on your behalf), * scoring subset of profile rules during scan would require new RFE ticket (again can file it on your behalf, just let me know).
The advantage of aforementioned approach (when compared to scap-security-guide fork) being in case more users having same request / use case scenario as you, they could profit from these (possibly new) SW features without needing to perform additional steps (SSG fork & own XSLT transforms implementation).
Of course, all of the above depends on the fact if underlying standards / scanner implementation allows this (needs deeper inspection). Stay tuned.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Hopefully from the above being visible that (in my opinion) parser tools customizations are preferred way rather than SSG content forks (IOW agree with Jeffrey, that there should be one "core" content repository being able to handle various use-cases, rather than dozen of content forks, each of them bended to serve / handle particular instance expectations).
A <Profile> cannot alter the role² attribute of a <Rule> (to unscored rather than full).
We intend to do this using a modified benchmark containing a single <Profile>, and applying arbitrary "profiles" to the evaluation results at a subsequent time.
This is most easily done using a fork describing the necessary changes. A fork may also ease the task of having a single checklist for RHEL6 and RHEL7 comprised of parts common to both as well as parts peculiar to either.
Regards,
Gary
-- ¹ Actually most, as we will not traipse through terabytes of local storage looking for unowned files, e.g. ² Goes back a ways: http://making-security-measurable.1364806.n2.nabble.com/role-unchecked-error.... _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Gary, if I got your use case from this (and your subsequent email from today) correctly, the request being as follows:
- on one hand to have a "profile / checklist" of all rules (grepped by their uniqueness) that ever existed for RHEL {6,7} products. All rules would be selected by default, and
- to have possibility to score only subset of them during scan
What does 'grepped by their uniqueness' mean here? Every single rule is unique in an XCCDF because it has to have a unique ID (enforced by XSD and schematron). Can 2 rules exist in a benchmark that you would consider not unique?
If each rule has @selected=true (this is recommended for all SCAP content), then the default profile serves as such "all rules" profile.
Does openscap allow user to select which rules should be included in the score computation? I don't think so. If this feature is desired we have to implement it in openscap first.
(feel free to correct me if I didn't the request details properly).
Projected into scap-workbench functionality this means:
- have possibility to merge various profiles (by grepping various but only unique rules),
- have possibility how to specify the subset of rules (within that resulting checklist) that should be scored during scan.
scap-workbench (SW) currently supports tailoring (e.g. a way how to select subset of rules from particular profile into new one). From that implies to me that the first point could be (possibly) reached with currently supported SW functionality as follows:
Select particular profile. Use tailoring. Select all rules from it, and save it.
Load another profile in the "Profile:" field of the SW section, load the previously saved tailoring file, and click customize. Naive view suggests SW should in that scenario allow to add rules from the selected profile to the original tailoring (but didn't try it, so might be wrong)
If not (Cc-ing Martin for hint on this), there should be a SW ticket: [1] https://fedorahosted.org/scap-workbench/newticket
created for this enhancement (please note you need to be logged in to be able to file new SW ticket).
I am having trouble understanding the use-case. Right now SW cannot merge 2 existing profiles into 1. You can however load a tailoring file and tailor profiles in it, thus changing the profiles. I believe the latter satisfies 2).
For what is worthy regarding selecting just of a subset of rules, that should be scored during the scan, I don't think this is currently supported / possible in SW (Martin pls correct me here too). => This would need another ticket to be filed to cover this scenario.
I believe that is the case.
Thanks for the reply, Martin.
Gary, if I got your use case from this (and your subsequent email from today) correctly, the request being as follows:
- on one hand to have a "profile / checklist" of all rules (grepped by
their uniqueness) that ever existed for RHEL {6,7} products. All rules would be selected by default, and
- to have possibility to score only subset of them during scan
What does 'grepped by their uniqueness' mean here?
Under 'grepped by their uniqueness' have meant more "human perception (IOW rule names)" level rather than "automated tool processing perception (IOW unique by rule ids)" level.
Every single rule is unique in an XCCDF because it has to have a unique ID (enforced by XSD and schematron). Can 2 rules exist in a benchmark that you would consider not unique?
See above. Maybe my misunderstanding. Of course they would have unique ids, but was thinking more they to be unique in the sense for example if there's "Package aide installed" rule for both RHEL-6 and RHEL-7 content, the tool would / could recognize they are the same and display / offer for selection only one of them. Anyway, it's clear now this wouldn't be possible (your explanation above).
If each rule has @selected=true (this is recommended for all SCAP content), then the default profile serves as such "all rules" profile.
Does openscap allow user to select which rules should be included in the score computation? I don't think so. If this feature is desired we have to implement it in openscap first.
Is this supported use-case by the standard? Or standard unrelated? If standard doesn't forbids it, I would file a RFE against openscap for this.
(feel free to correct me if I didn't the request details properly).
Projected into scap-workbench functionality this means:
- have possibility to merge various profiles (by grepping various but only unique rules),
- have possibility how to specify the subset of rules (within that
resulting checklist) that should be scored during scan.
scap-workbench (SW) currently supports tailoring (e.g. a way how to select subset of rules from particular profile into new one). From that implies to me that the first point could be (possibly) reached with currently supported SW functionality as follows:
Select particular profile. Use tailoring. Select all rules from it, and save it.
Load another profile in the "Profile:" field of the SW section, load the previously saved tailoring file, and click customize. Naive view suggests SW should in that scenario allow to add rules from the selected profile to the original tailoring (but didn't try it, so might be wrong)
If not (Cc-ing Martin for hint on this), there should be a SW ticket: [1] https://fedorahosted.org/scap-workbench/newticket
created for this enhancement (please note you need to be logged in to be able to file new SW ticket).
I am having trouble understanding the use-case. Right now SW cannot merge 2 existing profiles into 1.
Yeah, was about merging (more exactly try to apply currently implemented functionality to achieve merging of them).
You can however load a tailoring file and tailor profiles in it, thus changing the profiles.
Sure (aware it's possible to tune actual profile by selecting only certain rules [IOW make a subset of profile rules]).
But is it possible also enlarge the original profile with additional rules (those copied / moved from another profile)?
I believe the latter satisfies 2).
If it allows also adding new rules (not present in the original profile, tailoring was created from) then yes.
For what is worthy regarding selecting just of a subset of rules, that should be scored during the scan, I don't think this is currently supported / possible in SW (Martin pls correct me here too). => This would need another ticket to be filed to cover this scenario.
I believe that is the case.
Was mainly checking if such use-case is allowed by the standard. If so, will file a RFE for this (since looks as reasonable request).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-- Martin Preisler
Hello, Jan:
On 02/20/2014 05:30 AM, Jan Lieskovsky wrote:
Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected.
Gary, if I got your use case from this (and your subsequent email from today) correctly, the request being as follows:
- on one hand to have a "profile / checklist" of all rules (grepped by their uniqueness) that ever existed for RHEL {6,7} products. All rules would be selected by default, and
- to have possibility to score only subset of them during scan
(feel free to correct me if I didn't the request details properly).
I'll try to address this from the composite of both of my previous posts.
First, to your second itemization…
Yes. We wish to evaluate most rules, thus obtaining a record of security posture, while scoring an arbitrary subset. The result of such an evaluation will, subsequent to evaluation, be subjected to further analysis using arbitrary foci in a large data repository.
This can be achieved using "select" and "role" attributes on a <refine-rule> element (XCCDF ≥1.2). The schema indicates these are mutable as well as weight and severity.
Not so easy to achieve is to alter other parts of the checklist not subject to a tailoring profile. Our compliance metrics infrastructure — currently only XCCDF 1.4 capable — requires that benchmark id and profile id be changed, and the folks responsible wish a only a single profile to be used to reduce complexity. We track revisions using the status and version elements. Excision of unused matter such as unused rules and OCIL is optional but desirable.
The altered checklist presented to the compliance metrics infrastructure need not be and is not the same as that presented as a prose document for general reference. In particular, sections such as those dealing with services such as web and email would not necessarily be immediately automated but still used as configuration guidance. I have yet to determine whether such service-specific checklist sections can be routinely automated using special rules that determine the presence or absence of such services (likely using platform qualifiers at the group or rule level).
Second, to your first itemization…
We intend to use a single checklist for both RHEL6 and RHEL7 (and derivatives), ideally augmented at a subsequent time for use with Debian distributions (the compliance metrics folks want as few checklists as possible: e.g., we just released a combined Internet Explorer 9/10/11 checklist). Such use requires altered platform specificity at the checklist and rule level. We had hoped that SSG use a similar approach at least for RHEL 6 and 7 (single rules and single checks where common; platform-specific checks when platform-specific checks are required, and platform-specific rules when required).
In other words, a single checklist for Linux distributions having a single rule for each single security practice common to all, but possibly having different expressions in several.
This is rather the same as a compilation obtained from «one "core" content repository being able to handle various use-cases».
Projected into scap-workbench functionality this means: [snip]
To sum up:
- either "merging of rules" is currently supported in SW already, and you could perform as described above. Or an RFE should be filed for it this to be possible in the future (let me know, if I should file that ticket on your behalf),
- scoring subset of profile rules during scan would require new RFE ticket (again can file it on your behalf, just let me know).
The advantage of aforementioned approach (when compared to scap-security-guide fork) being in case more users having same request / use case scenario as you, they could profit from these (possibly new) SW features without needing to perform additional steps (SSG fork & own XSLT transforms implementation).
Of course, all of the above depends on the fact if underlying standards / scanner implementation allows this (needs deeper inspection). Stay tuned.
I will. Tailoring appears adequate for rule role modification, not obviously so for some of the other desired alterations.
Were I to reduce our intended checklist to a simple list, it would be one specifying each desired rule to be obtained from a repository of such individual checklist items, as well its desired select and role attributes, and the desired variable value(s) to be used. Governing this selection would be target platforms. OCIL presence or absence would be arbitrary. The resulting compilation would have an id, title, description, version, status, etc.
That is not the same as a <Tailoring> construct.
Though it does not fit easily into the manner of "tailoring" anticipated by those who have devised SCAP, our intended compilation is appropriate for our current needs.
P.S.: Hopefully from the above being visible that (in my opinion) parser tools customizations are preferred way rather than SSG content forks (IOW agree with Jeffrey, that there should be one "core" content repository being able to handle various use-cases, rather than dozen of content forks, each of them bended to serve / handle particular instance expectations).
I agree.
In our case, we do not wish to perturb the individual rules and associated checks, just the manner in which they are compiled into a checklist. Ours is currently a derivation rather than a compilation. The latter is preferable, the former currently easier.
Regards,
Gary
PS: I like github for many of the reasons thus far mentioned, and would prefer it if it made my tasks easier, which may not have anything to do with forking. The "split" of SSG content for RHEL 6 and 7 does indeed make my tasks more difficult.
Hello Gary,
apologize for late reply (other things prevented me from sooner reaction). Anyway:
----- Original Message -----
From: "Gary Gapinski" gapinski@nasa.gov To: "Jan Lieskovsky" jlieskov@redhat.com, scap-security-guide@lists.fedorahosted.org Sent: Friday, February 21, 2014 1:36:05 PM Subject: Re: [RFC] time to move to github?
Hello, Jan:
On 02/20/2014 05:30 AM, Jan Lieskovsky wrote:
Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected.
Gary, if I got your use case from this (and your subsequent email from today) correctly, the request being as follows:
- on one hand to have a "profile / checklist" of all rules (grepped by
their uniqueness) that ever existed for RHEL {6,7} products. All rules would be selected by default, and
- to have possibility to score only subset of them during scan
(feel free to correct me if I didn't the request details properly).
I'll try to address this from the composite of both of my previous posts.
First, to your second itemization…
Yes. We wish to evaluate most rules, thus obtaining a record of security posture, while scoring an arbitrary subset. The result of such an evaluation will, subsequent to evaluation, be subjected to further analysis using arbitrary foci in a large data repository.
This can be achieved using "select" and "role" attributes on a <refine-rule> element (XCCDF ≥1.2). The schema indicates these are mutable as well as weight and severity.
Not so easy to achieve is to alter other parts of the checklist not subject to a tailoring profile. Our compliance metrics infrastructure — currently only XCCDF 1.4 capable — requires that benchmark id and profile id be changed, and the folks responsible wish a only a single profile to be used to reduce complexity. We track revisions using the status and version elements. Excision of unused matter such as unused rules and OCIL is optional but desirable.
The altered checklist presented to the compliance metrics infrastructure need not be and is not the same as that presented as a prose document for general reference. In particular, sections such as those dealing with services such as web and email would not necessarily be immediately automated but still used as configuration guidance. I have yet to determine whether such service-specific checklist sections can be routinely automated using special rules that determine the presence or absence of such services (likely using platform qualifiers at the group or rule level).
Second, to your first itemization…
We intend to use a single checklist for both RHEL6 and RHEL7 (and derivatives), ideally augmented at a subsequent time for use with Debian distributions (the compliance metrics folks want as few checklists as possible: e.g., we just released a combined Internet Explorer 9/10/11 checklist). Such use requires altered platform specificity at the checklist and rule level. We had hoped that SSG use a similar approach at least for RHEL 6 and 7 (single rules and single checks where common; platform-specific checks when platform-specific checks are required, and platform-specific rules when required).
In other words, a single checklist for Linux distributions having a single rule for each single security practice common to all, but possibly having different expressions in several.
This is rather the same as a compilation obtained from «one "core" content repository being able to handle various use-cases».
Projected into scap-workbench functionality this means: [snip]
To sum up:
- either "merging of rules" is currently supported in SW already, and you
could perform as described above. Or an RFE should be filed for it this to be possible in the future (let me know, if I should file that ticket on your behalf),
- scoring subset of profile rules during scan would require new RFE ticket (again can file it on your behalf, just let me know).
The advantage of aforementioned approach (when compared to scap-security-guide fork) being in case more users having same request / use case scenario as you, they could profit from these (possibly new) SW features without needing to perform additional steps (SSG fork & own XSLT transforms implementation).
Of course, all of the above depends on the fact if underlying standards / scanner implementation allows this (needs deeper inspection). Stay tuned.
I will. Tailoring appears adequate for rule role modification, not obviously so for some of the other desired alterations.
Were I to reduce our intended checklist to a simple list, it would be one specifying each desired rule to be obtained from a repository of such individual checklist items, as well its desired select and role attributes, and the desired variable value(s) to be used. Governing this selection would be target platforms. OCIL presence or absence would be arbitrary. The resulting compilation would have an id, title, description, version, status, etc.
That is not the same as a <Tailoring> construct.
Hmm, looks like I misunderstood this could be performed via tailoring.
In any case since one example is better than thousand of words (and if I remember correctly you to have mentioned having a reference implementation available already -- checking would it be possible you to point me to the fork of SSG repo / XSLT transformation performing the desired change?
If not (the code not being private) could you apply that transformation at current SSG content, and share the result with me, so I could have a look and find out, what's actually desired without having to dive too deeply into the corresponding specifications?
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Though it does not fit easily into the manner of "tailoring" anticipated by those who have devised SCAP, our intended compilation is appropriate for our current needs.
P.S.: Hopefully from the above being visible that (in my opinion) parser tools customizations are preferred way rather than SSG content forks (IOW agree with Jeffrey, that there should be one "core" content repository being able to handle various use-cases, rather than dozen of content forks, each of them bended to serve / handle particular instance expectations).
I agree.
In our case, we do not wish to perturb the individual rules and associated checks, just the manner in which they are compiled into a checklist. Ours is currently a derivation rather than a compilation. The latter is preferable, the former currently easier.
Regards,
Gary
PS: I like github for many of the reasons thus far mentioned, and would prefer it if it made my tasks easier, which may not have anything to do with forking. The "split" of SSG content for RHEL 6 and 7 does indeed make my tasks more difficult.
On 02/24/2014 12:25 PM, Jan Lieskovsky wrote:
Hello Gary,
apologize for late reply (other things prevented me from sooner reaction). Anyway:
No problem.
I will typically be late as well.
Hmm, looks like I misunderstood this could be performed via tailoring.
In any case since one example is better than thousand of words (and if I remember correctly you to have mentioned having a reference implementation available already -- checking would it be possible you to point me to the fork of SSG repo / XSLT transformation performing the desired change?
If not (the code not being private) could you apply that transformation at current SSG content, and share the result with me, so I could have a look and find out, what's actually desired without having to dive too deeply into the corresponding specifications?
Yes, but not for a few days.
It is a transformation applied to SSG RHEL6/dist/content/ssg-rhel6-xccdf.xml. There is no actual "fork".
Regards,
Gary
On Wed, Feb 19, 2014 at 2:39 PM, Gary Gapinski gapinski@nasa.gov wrote:
Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected.
A <Profile> cannot alter the role² attribute of a <Rule> (to unscored rather than full).
This is an interesting use case I relate to: wanting to know results of all tests, but only really caring about a subset.
For example, the current/default XCCDF report format via OSCAP does not summarize pass/fail by severity. In the scan I am using there are only 17 critical controls. Don't I want my reports to guide where I put my attention first? It's on my ist to change that for my needs.
Being able to categorize system state and then apply varying states against varying contexts is highly useful for prioritizing and analysis, IMO. Do I want to take automatic actions according to some algorithm of tests and criticality? Is pass/fail really a binary or even a scalar operation, or is it more flexible and context driven?
I well know the anxiousness from someone forking my carefully-crafted software to use in unintended ways. I also know the joy of finding open source code that I can bend to my use case.
Openness means never having to say your sorry for forking around. Experiments are the driving force of evolution.
Greg Elin personal cell: 917-304-3488 personal email: greg@fotonotes.net email: gregelin@gitmachines.com
On 02/16/2014 10:03 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 * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * 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.
What does everyone think?
GitHub is good tool. However, it may cause to the technical debate to dilute a bit. Discussion on patches will be tossed to multiple places (mailing list, github review, comments to separate hunks, etc.).
There might be people on the mailing list, who time to time review incoming patches during their afternoon-e-mail-snacking. Such people may not have morale to watch requests on github. Also their ability to search back in time may be limited.
But I am just old school sport and I am not an active contributor, hence I have very little to say. The contributors shall decide.
+1 to github and hopefully abandoning the sending of patchsets to the mailing list for review.
Jeff
On 02/16/2014 04:03 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 * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * 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.
What does everyone think?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
Thanks,
Trevor
On Fri, Feb 28, 2014 at 3:26 PM, Jeff Bachtel < jbachtel@bericotechnologies.com> wrote:
+1 to github and hopefully abandoning the sending of patchsets to the mailing list for review.
Jeff
On 02/16/2014 04:03 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 * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * 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.
What does everyone think?
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because: - the process of patch approval was not clear, - communication around a patch is made difficult by mail (which are already follinwg throughout the days) - current open issues are not listed and cannot be discussed by the community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells shawn@redhat.com wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap-security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents.
Thank you!
I also find the patch by email process confusing.
I consider that my issue, of course, and that I need to just sit down and learn it. Alas, learning patch by email becomes one of those tasks that is very easy to put off in the face of other urgencies.
I'll ask a silly question. What if we put a branch on GitHub to test while continuing to use Fedora hosted? It would be a little extra work for a bit for someone to keep them in sync. But if they are both Git under the hood, shouldn't it be relatively easy to maintain both for a 45 day trial.
Greg Elin personal cell: 917-304-3488 personal email: greg@fotonotes.net email: gregelin@gitmachines.com
On Tue, Apr 8, 2014 at 3:01 PM, Shawn Wells shawn@redhat.com wrote:
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap-security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents.
Thank you!
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hello Greg,
thank you for the reply.
----- Original Message -----
From: "Greg Elin" Sent: Tuesday, April 8, 2014 9:16:29 PM
I also find the patch by email process confusing.
It's confusing because it differs from the GitHub's one? [*] Or you are missing the Gerrit instance to be able to focus just at the most preferred issue and have easy way to comment on that one? Or the ticketing system? Anything else?
I consider that my issue, of course, and that I need to just sit down and learn it. Alas, learning patch by email becomes one of those tasks that is very easy to put off in the face of other urgencies.
So the issue is git-email setup? [*]
I'll ask a silly question. What if we put a branch on GitHub to test while continuing to use Fedora hosted? It would be a little extra work for a bit for someone to keep them in sync. But if they are both Git under the hood, shouldn't it be relatively easy to maintain both for a 45 day trial.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] As already mentioned, it's documented at: https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper
but maybe it should be improved to be more elaborated / sophisticated like e.g. oVirt's one: http://www.ovirt.org/Working_with_oVirt_Gerrit
is (so interested contributor could "in five minutes" finish the setup easily, and start looking into the issues)
Greg Elin personal cell: 917-304-3488 personal email: greg@fotonotes.net email: gregelin@gitmachines.com
On Tue, Apr 8, 2014 at 3:01 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap- security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents. Thank you!
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Jan, thanks for responding to me.
Let's say I want to make a small patch to fix a typo. Do you have a link that explains how I would get started using current process?
Greg
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Apr 9, 2014, at 5:59 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Hello Greg,
thank you for the reply.
----- Original Message -----
From: "Greg Elin" Sent: Tuesday, April 8, 2014 9:16:29 PM
I also find the patch by email process confusing.
It's confusing because it differs from the GitHub's one? [*] Or you are missing the Gerrit instance to be able to focus just at the most preferred issue and have easy way to comment on that one? Or the ticketing system? Anything else?
I consider that my issue, of course, and that I need to just sit down and learn it. Alas, learning patch by email becomes one of those tasks that is very easy to put off in the face of other urgencies.
So the issue is git-email setup? [*]
I'll ask a silly question. What if we put a branch on GitHub to test while continuing to use Fedora hosted? It would be a little extra work for a bit for someone to keep them in sync. But if they are both Git under the hood, shouldn't it be relatively easy to maintain both for a 45 day trial.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] As already mentioned, it's documented at: https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper
but maybe it should be improved to be more elaborated / sophisticated like e.g. oVirt's one: http://www.ovirt.org/Working_with_oVirt_Gerrit
is (so interested contributor could "in five minutes" finish the setup easily, and start looking into the issues)
Greg Elin personal cell: 917-304-3488 personal email: greg@fotonotes.net email: gregelin@gitmachines.com
On Tue, Apr 8, 2014 at 3:01 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap- security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents. Thank you!
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hi Greg,
----- Original Message -----
From: "Greg Elin" Sent: Wednesday, April 9, 2014 3:07:28 PM
Jan, thanks for responding to me.
Let's say I want to make a small patch to fix a typo. Do you have a link that explains how I would get started using current process?
It was provided in my original reply: https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Greg
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Apr 9, 2014, at 5:59 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Hello Greg,
thank you for the reply.
----- Original Message -----
From: "Greg Elin" Sent: Tuesday, April 8, 2014 9:16:29 PM
I also find the patch by email process confusing.
It's confusing because it differs from the GitHub's one? [*] Or you are missing the Gerrit instance to be able to focus just at the most preferred issue and have easy way to comment on that one? Or the ticketing system? Anything else?
I consider that my issue, of course, and that I need to just sit down and learn it. Alas, learning patch by email becomes one of those tasks that is very easy to put off in the face of other urgencies.
So the issue is git-email setup? [*]
I'll ask a silly question. What if we put a branch on GitHub to test while continuing to use Fedora hosted? It would be a little extra work for a bit for someone to keep them in sync. But if they are both Git under the hood, shouldn't it be relatively easy to maintain both for a 45 day trial.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] As already mentioned, it's documented at: https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper
but maybe it should be improved to be more elaborated / sophisticated like e.g. oVirt's one: http://www.ovirt.org/Working_with_oVirt_Gerrit
is (so interested contributor could "in five minutes" finish the setup easily, and start looking into the issues)
Greg Elin personal cell: 917-304-3488 personal email: greg@fotonotes.net email: gregelin@gitmachines.com
On Tue, Apr 8, 2014 at 3:01 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap- security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents. Thank you!
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
+1 on moving the source repository to GitHub - the projects I've put up there are easy to manage and I've had great interaction with contributors.
----- Original Message ----- From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Tuesday, April 8, 2014 3:01:37 PM Subject: Re: [RFC] time to move to github?
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap-security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents.
Thank you! _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
----- Original Message -----
From: "Frank Caviggia" Sent: Wednesday, April 9, 2014 5:33:36 AM
+1 on moving the source repository to GitHub - the projects I've put up there are easy to manage and I've had great interaction with contributors.
Frank, same question - can you elaborate what makes the project(s) easy to be manageable & have great interaction with contributors? (ideally via listing the underlying features allowing this)
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
----- Original Message ----- From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Tuesday, April 8, 2014 3:01:37 PM Subject: Re: [RFC] time to move to github?
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap-security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents.
Thank you! _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Frank Caviggia Consultant, Red Hat fcaviggi@redhat.com (M) (571) 295-4560 _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hi Jan,
thanks for your feedback on this whole discussion.
From my experience on github, here are the positive aspects:
- users can file issues in a convenient and nice UI: most devs often have a github account and enjoy contributing to other projects (social network coding) - repositories are provided with stats (on commits, traffic and views, contributors, ...) - users can fork the code and see how there code evolves compared to the actual master (nice to have derivated policies and let them evolve on a side track) - forks can also be identified easily and contributed to with a possible merge in the upsteam repo (side track goes back to the main road) - users can issue patch (pull requests) which are easy to diff (nice UI) and integrate in the repo - considerable communities of devs and lots of features to consolidate a community (follow, repository starring, repo watch,...) - and most important: all those aspects are all integrated into a single interface (single account).
Beside all this, I fairly understand that such a move should not be decided in a snap :)
Ronald
On Wed, Apr 9, 2014 at 12:11 PM, Jan Lieskovsky jlieskov@redhat.com wrote:
----- Original Message -----
From: "Frank Caviggia" Sent: Wednesday, April 9, 2014 5:33:36 AM
+1 on moving the source repository to GitHub - the projects I've put up
there
are easy to manage and I've had great interaction with contributors.
Frank, same question - can you elaborate what makes the project(s) easy to be manageable & have great interaction with contributors? (ideally via listing the underlying features allowing this)
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
----- Original Message ----- From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Tuesday, April 8, 2014 3:01:37 PM Subject: Re: [RFC] time to move to github?
On 4/8/14, 2:57 PM, Ronald wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
The https://fedorahosted.org/scap-security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github.
my two cents.
Thank you! _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Frank Caviggia Consultant, Red Hat fcaviggi@redhat.com (M) (571) 295-4560 _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Honestly +1 here.
I have pretty much all of my repos hosted under Github and their patch and review process is *easy* particularly when combined with the new Gerrit system that's free for FOSS projects.
Trevor
On Tue, Apr 8, 2014 at 2:57 PM, Ronald mini.pelle@gmail.com wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community (to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells shawn@redhat.com wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hello Trevor,
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 2:12:52 AM
Honestly +1 here.
I have pretty much all of my repos hosted under Github and their patch and review process is *easy*
Can you be more specific what makes that patch review process easy? Anything else behind having the patch review handled via Gerrit?
particularly when combined with the new Gerrit system that's free for FOSS projects.
So would just request Gerrit instance for SSG project via the Fedora infrastructure solve our obstacles? [*]
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] You to understand I am not against moving to GitHub. Just trying to identify the difference / advantages / improvements, and if some of them would be doable without the move to GitHub (less requirements for the time / resources wrt to actions related with the move)
Trevor
On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle@gmail.com > wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Absolutely!
So, patch reviews are made easier by the following:
GitHub
1) Syntax highlighting 2) Inline commenting that persists over time 3) Immediate tracing of tickets to code via hashtags 4) Notification of individuals and groups via directed responses (@) 5) Easy raw file downloads
Gerrit
1) Syntax highlighting 2) Inline commenting that persists over time 3) Forced clean history based on Gerrit rules 4) Complete tracking of revision history (GitHub doesn't give you this) 5) Ability to restore abandoned changes if necessary 6) Authoritative, uncorruptable (unless you allow direct pushing) repository.
If I remember correctly, FedoraHosted will not use any product not packaged with RHEL/Fedora and Gerrit proved to be too difficult to package for whatever reason.
There is another Gerrit-like system that the FedoraHosted systems can use but I didn't find it to be as powerful as Gerrit when I last tried to use it.
Thanks,
Trevor
On Wed, Apr 9, 2014 at 6:05 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Hello Trevor,
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 2:12:52 AM
Honestly +1 here.
I have pretty much all of my repos hosted under Github and their patch
and
review process is *easy*
Can you be more specific what makes that patch review process easy? Anything else behind having the patch review handled via Gerrit?
particularly when combined with the new Gerrit system that's free for FOSS projects.
So would just request Gerrit instance for SSG project via the Fedora infrastructure solve our obstacles? [*]
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] You to understand I am not against moving to GitHub. Just trying to identify the difference / advantages / improvements, and if some of them would be doable without the move to GitHub (less requirements for the time / resources wrt to actions related with the move)
Trevor
On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle@gmail.com > wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion),
I've
been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things clear
for
global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests
would
be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage
--
and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable
ticketing
system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include
the
same tooling and developer ecosystem as afforded on GitHub (and that's
NOT a
ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives
the
community, and I strongly feel the need to build out tools that will
allow
us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
More on github patching
On GitHub, a request to make a patch, or "pull" in code automatically creates an issue ticket. The pull request/patch can be discussed. This means the the discussion, patch, and commit pointer are all found at a single URL.
Additionally, individuals can be reference and linked in the conversation using the "@username" convention. Any use of @gregelin immediately includes that comment in my Github notification feed and emails me.
Email is very convenient and feels intimate among a tight community.
After working at a federal agency and seeing how much work was done inside of email and effectively made obscure (if not invisible) to the rest of the enterprise, I much prefer discussions that aggregate at a single URL.
Greg
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Apr 9, 2014, at 9:08 AM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
Absolutely!
So, patch reviews are made easier by the following:
GitHub
- Syntax highlighting
- Inline commenting that persists over time
- Immediate tracing of tickets to code via hashtags
- Notification of individuals and groups via directed responses (@)
- Easy raw file downloads
Gerrit
- Syntax highlighting
- Inline commenting that persists over time
- Forced clean history based on Gerrit rules
- Complete tracking of revision history (GitHub doesn't give you this)
- Ability to restore abandoned changes if necessary
- Authoritative, uncorruptable (unless you allow direct pushing) repository.
If I remember correctly, FedoraHosted will not use any product not packaged with RHEL/Fedora and Gerrit proved to be too difficult to package for whatever reason.
There is another Gerrit-like system that the FedoraHosted systems can use but I didn't find it to be as powerful as Gerrit when I last tried to use it.
Thanks,
Trevor
On Wed, Apr 9, 2014 at 6:05 AM, Jan Lieskovsky jlieskov@redhat.com wrote: Hello Trevor,
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 2:12:52 AM
Honestly +1 here.
I have pretty much all of my repos hosted under Github and their patch and review process is *easy*
Can you be more specific what makes that patch review process easy? Anything else behind having the patch review handled via Gerrit?
particularly when combined with the new Gerrit system that's free for FOSS projects.
So would just request Gerrit instance for SSG project via the Fedora infrastructure solve our obstacles? [*]
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] You to understand I am not against moving to GitHub. Just trying to identify the difference / advantages / improvements, and if some of them would be doable without the move to GitHub (less requirements for the time / resources wrt to actions related with the move)
Trevor
On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle@gmail.com > wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
So, I am furiously scrolling through email messages to try and confirm it was Jan who suggested we articulate needs and goals before any change. +1 on that idea. It is good practice.
I realizing how god awful email is to catch up and understand any discussion you are not following in real time.
GitHub issues, like most web based discussion UIs, handle threading and quoting much better than email. That is a giant +1 if you want drive expanded the community and increase use.
Finally, FWIW, I think redundancy is important. Having the repo at both repos has an upside.
Greg
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Apr 9, 2014, at 9:08 AM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
Absolutely!
So, patch reviews are made easier by the following:
GitHub
- Syntax highlighting
- Inline commenting that persists over time
- Immediate tracing of tickets to code via hashtags
- Notification of individuals and groups via directed responses (@)
- Easy raw file downloads
Gerrit
- Syntax highlighting
- Inline commenting that persists over time
- Forced clean history based on Gerrit rules
- Complete tracking of revision history (GitHub doesn't give you this)
- Ability to restore abandoned changes if necessary
- Authoritative, uncorruptable (unless you allow direct pushing) repository.
If I remember correctly, FedoraHosted will not use any product not packaged with RHEL/Fedora and Gerrit proved to be too difficult to package for whatever reason.
There is another Gerrit-like system that the FedoraHosted systems can use but I didn't find it to be as powerful as Gerrit when I last tried to use it.
Thanks,
Trevor
On Wed, Apr 9, 2014 at 6:05 AM, Jan Lieskovsky jlieskov@redhat.com wrote: Hello Trevor,
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 2:12:52 AM
Honestly +1 here.
I have pretty much all of my repos hosted under Github and their patch and review process is *easy*
Can you be more specific what makes that patch review process easy? Anything else behind having the patch review handled via Gerrit?
particularly when combined with the new Gerrit system that's free for FOSS projects.
So would just request Gerrit instance for SSG project via the Fedora infrastructure solve our obstacles? [*]
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] You to understand I am not against moving to GitHub. Just trying to identify the difference / advantages / improvements, and if some of them would be doable without the move to GitHub (less requirements for the time / resources wrt to actions related with the move)
Trevor
On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle@gmail.com > wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 3:08:13 PM
Absolutely!
So, patch reviews are made easier by the following:
GitHub
- Syntax highlighting
- Inline commenting that persists over time
- Immediate tracing of tickets to code via hashtags
- Notification of individuals and groups via directed responses (@)
- Easy raw file downloads
Gerrit
- Syntax highlighting
- Inline commenting that persists over time
- Forced clean history based on Gerrit rules
- Complete tracking of revision history (GitHub doesn't give you this)
- Ability to restore abandoned changes if necessary
- Authoritative, uncorruptable (unless you allow direct pushing)
repository.
Thank you for your time, Trevor. Looking at that list of such handy features I would say it's definitely worthy to give the move a try.
If I remember correctly, FedoraHosted will not use any product not packaged with RHEL/Fedora and Gerrit proved to be too difficult to package for whatever reason.
Yes, other thing to consider (from further look) looks it might not be that easy / straightforward to create own Gerrit instance: https://fedorahosted.org/fedora-infrastructure/ticket/2924
Looks not to be present even in OpenShift yet: https://www.openshift.com/content/instant-application-gerrit-code-review
So if we wanted the power of Gerrit, we either need to: * move to GitHub, * administer our own SSG specific instance (another resources consumption)
There is another Gerrit-like system that the FedoraHosted systems can use but I didn't find it to be as powerful as Gerrit when I last tried to use it.
Which concrete one you have meant -- got the links? (couldn't find anything like that, but maybe my queries have just wrong keywords)
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks,
Trevor
On Wed, Apr 9, 2014 at 6:05 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Hello Trevor,
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 2:12:52 AM
Honestly +1 here.
I have pretty much all of my repos hosted under Github and their patch
and
review process is *easy*
Can you be more specific what makes that patch review process easy? Anything else behind having the patch review handled via Gerrit?
particularly when combined with the new Gerrit system that's free for FOSS projects.
So would just request Gerrit instance for SSG project via the Fedora infrastructure solve our obstacles? [*]
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] You to understand I am not against moving to GitHub. Just trying to identify the difference / advantages / improvements, and if some of them would be doable without the move to GitHub (less requirements for the time / resources wrt to actions related with the move)
Trevor
On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle@gmail.com > wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion),
I've
been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things clear
for
global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests
would
be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage
--
and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable
ticketing
system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include
the
same tooling and developer ecosystem as afforded on GitHub (and that's
NOT a
ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives
the
community, and I strongly feel the need to build out tools that will
allow
us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Jan,
The tool is ReviewBoard http://www.reviewboard.org/
Here's the original thread that I was thinking of for reference https://fedorahosted.org/fedora-infrastructure/ticket/2924.
There are quite a few Gerrit vs (everything else) posts out there and ReviewBoard would go a long way toward helping put in a lot of what I would like to see but it's (in my opinion) still not as powerful as Gerrit.
Trevor
On Wed, Apr 9, 2014 at 10:31 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 3:08:13 PM
Absolutely!
So, patch reviews are made easier by the following:
GitHub
- Syntax highlighting
- Inline commenting that persists over time
- Immediate tracing of tickets to code via hashtags
- Notification of individuals and groups via directed responses (@)
- Easy raw file downloads
Gerrit
- Syntax highlighting
- Inline commenting that persists over time
- Forced clean history based on Gerrit rules
- Complete tracking of revision history (GitHub doesn't give you this)
- Ability to restore abandoned changes if necessary
- Authoritative, uncorruptable (unless you allow direct pushing)
repository.
Thank you for your time, Trevor. Looking at that list of such handy features I would say it's definitely worthy to give the move a try.
If I remember correctly, FedoraHosted will not use any product not
packaged
with RHEL/Fedora and Gerrit proved to be too difficult to package for whatever reason.
Yes, other thing to consider (from further look) looks it might not be that easy / straightforward to create own Gerrit instance: https://fedorahosted.org/fedora-infrastructure/ticket/2924
Looks not to be present even in OpenShift yet: https://www.openshift.com/content/instant-application-gerrit-code-review
So if we wanted the power of Gerrit, we either need to:
- move to GitHub,
- administer our own SSG specific instance (another resources consumption)
There is another Gerrit-like system that the FedoraHosted systems can use but I didn't find it to be as powerful as Gerrit when I last tried to use it.
Which concrete one you have meant -- got the links? (couldn't find anything like that, but maybe my queries have just wrong keywords)
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks,
Trevor
On Wed, Apr 9, 2014 at 6:05 AM, Jan Lieskovsky jlieskov@redhat.com
wrote:
Hello Trevor,
----- Original Message -----
From: "Trevor Vaughan" Sent: Wednesday, April 9, 2014 2:12:52 AM
Honestly +1 here.
I have pretty much all of my repos hosted under Github and their
patch
and
review process is *easy*
Can you be more specific what makes that patch review process easy? Anything else behind having the patch review handled via Gerrit?
particularly when combined with the new Gerrit system that's free for FOSS projects.
So would just request Gerrit instance for SSG project via the Fedora infrastructure solve our obstacles? [*]
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] You to understand I am not against moving to GitHub. Just trying to identify the difference / advantages / improvements, and if some of them
would
be doable without the move to GitHub (less requirements for the time / resources wrt to actions related with the move)
Trevor
On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle@gmail.com >
wrote:
Hi there,
from a personal perspective, as a github users (read biased opinion),
I've
been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
- communication around a patch is made difficult by mail (which are
already
follinwg throughout the days)
- current open issues are not listed and cannot be discussed by the
community
(to propose patch for instance)
I have the feeling that a move to github would make lots of things
clear
for
global collaboration. Although, the fact that the project is hosted
at
fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn@redhat.com >
wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests
would
be really useful.
There were valid opinions expressed for both staying on FedoraHosted
and
migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and
usage
--
and because of this success Red Hat is preparing to ship SSG in
future
versions of RHEL [1]. This exacerbates the need for a manageable
ticketing
system with easy patch submission as very shortly every RHEL
installation
will have a copy of SSG. FedoraHosted simply wasn't designed to
include
the
same tooling and developer ecosystem as afforded on GitHub (and
that's
NOT a
ding against it's designers!).
The community is a coalition of the willing. Our shared purpose
drives
the
community, and I strongly feel the need to build out tools that will
allow
us to scale. I'm concerned -- likely overly so -- at how to prepare
for a
wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub?
Admittedly
part of me wants to just go ahead and do it, however that could come
at
making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't
make
everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap-
security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information
--
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
Hello Ronald,
thank you for the input on this.
----- Original Message -----
Hi there,
from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because:
- the process of patch approval was not clear,
It's unclear because it differs from the approach as being used on GitHub? (=> takes additional time contributors accustomed to GitHub patch process style to make familiar with it & start contributing)
The process is documented at: https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper
- communication around a patch is made difficult by mail (which are already
follinwg throughout the days)
I am not sure it's due the way we communicate (mail). There are more sources for the difficulties. Will comment on this further in reply to Shawn's post.
- current open issues are not listed and cannot be discussed by the community
(to propose patch for instance)
In other words we are not used to utilize the underlying ticketing system too much, therefore it's not clear what are the current blockers / issues being worked in that moment at?
Fedorahosted SSG instance has support for ticketing system: https://fedorahosted.org/scap-security-guide/report/1
But you are correct, that last one was filed ~2months ago: https://fedorahosted.org/scap-security-guide/ticket/434
and that from this PoV it might seem, there hasn't been progress on the project from that time (though obviously by count of patches provided in between this clearly isn't true).
If nothing else, this might indicate we already have features / possibilities how to make the patch proposal / review process more straightforward to future contributors. But not might be using them (too) effectively.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)
my two cents.
Ronald
On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn@redhat.com > wrote:
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
[1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655
scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/9/14, 5:10 AM, Jan Lieskovsky wrote:
Fedorahosted SSG instance has support for ticketing system: https://fedorahosted.org/scap-security-guide/report/1
But you are correct, that last one was filed ~2months ago: https://fedorahosted.org/scap-security-guide/ticket/434
and that from this PoV it might seem, there hasn't been progress on the project from that time (though obviously by count of patches provided in between this clearly isn't true).
I was messing around a few months ago and created a placeholder github account: https://github.com/ssgproject
Which lead to trying out the ticket system (fine, yes, I was a bit excessive....): https://github.com/ssgproject/content/issues
The GitHub system allows for easier application of labels, assignments, ties back to milestones, and most important (to me) is providing a central dashboard. People can subscribe/unsubscribe to issues they find important. If you associate yourself with the project in GitHub you automatically get an EMail when comments are posted, new tickets, etc. From my (very limited!) playing, it appears you can reply via the Web UI at github.com or directly from your EMail client.
When we patch the tickets, you simply put the reference number in your commit and it'll automagically close the ticket for you. Compared to FedoraHosted, you must track commits and hopefully remember to close out the tickets. It's annoying and I'll admit that sometimes drives me to push off doing tickets.... it's a hassle.
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com Sent: Tuesday, April 8, 2014 7:53:38 PM
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
I think the part problem of the stalemate you mention above being we didn't create the analysis yet: * to identify current bottlenecks, * to identify current features we need, * to identify future features we might need to smoothly support scaling etc.
In my opinion it's strange to switch from one hosting vendor to the another without performing this. On one hand as you said the move will take some time / resources, so the motivation should be clearly expressed why it's worthy to spend that time on the move (+ additional time current users to get familiar with the new scheme / process). On the other hand such analysis is necessary yet before we actually perform the move to know for sure, that the move will actually make the things better (that's why we need to identify the bottlenecks).
So instead of asking if we should move from Fedorahosted to GitHub, we should try to identify the list of items a smooth and easy patch proposal & review process should have. We can maintain that list on the mailing list (within this thread) or even create a dedicated wiki page for that (gathering such requirements and allowing mailing list participants to offer enhancements).
To start with such a list, the items which come to mind are as follows: * bottlenecks: - patch proposal / review process differs from GitHub's one => it's non-trivial for users accustomed to use GitHub way easy to flip to our scheme,
- small ratio of using ticketing system functionality => new users don't have a way how to find out list of issues currently being worked at or find the most burning problem,
- patch review process not separated by complexity of the fix (in other words same rules are applied for simple typo fixes on one hand, while for the complex rewrites on the other. While obviously simple typo fixes / fixes not actually changing the functionality, but rather fixing some error [failing make etc.] should have higher urgency and could have been [once tested] pushed to the repository without the need for even one ACK),
- missing user's roles on patch review process. One part what Gerrit brings (besides the patches being available online without the need for additional email communication) being the patch reviewer's role separation - there are users with ad hoc / a priori permission to submit patches (selected into the group once they provided required "level of trust") without the need to wait for ACKs (the "core upstream"). Then there are occasional contributors who based on their time possibilities might comment on particular issue / provide a patch for it, but who actually require some of the admins to submit their patch into the repo after the review. I think this point the current email communication doesn't allow us to implement.
* the features: ... * the future features: - feel free to comment here what we are currently missing, and might want in the future (what GitHub has support for, and Fedorahosted doesn't)
Maybe once there is conclusion from this thread / more points, as proposed we should move it to dedicated wiki page to track the already obtained consensus.
Comments welcome.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Apr 9, 2014, at 5:42 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com Sent: Tuesday, April 8, 2014 7:53:38 PM
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
I think the part problem of the stalemate you mention above being we didn't create the analysis yet:
- to identify current bottlenecks,
- to identify current features we need,
- to identify future features we might need to smoothly support scaling etc.
In my opinion it's strange to switch from one hosting vendor to the another without performing this. On one hand as you said the move will take some time / resources, so the motivation should be clearly expressed why it's worthy to spend that time on the move (+ additional time current users to get familiar with the new scheme / process). On the other hand such analysis is necessary yet before we actually perform the move to know for sure, that the move will actually make the things better (that's why we need to identify the bottlenecks).
So instead of asking if we should move from Fedorahosted to GitHub, we should try to identify the list of items a smooth and easy patch proposal & review process should have. We can maintain that list on the mailing list (within this thread) or even create a dedicated wiki page for that (gathering such requirements and allowing mailing list participants to offer enhancements).
To start with such a list, the items which come to mind are as follows:
- bottlenecks:
patch proposal / review process differs from GitHub's one => it's non-trivial for users accustomed to use GitHub way easy to flip to our scheme,
small ratio of using ticketing system functionality => new users don't have a way how to find out list of issues currently being worked at or find the most burning problem,
patch review process not separated by complexity of the fix (in other words same rules are applied for simple typo fixes on one hand, while for the complex rewrites on the other. While obviously simple typo fixes / fixes not actually changing the functionality, but rather fixing some error [failing make etc.] should have higher urgency and could have been [once tested] pushed to the repository without the need for even one ACK),
I don’t believe this is necessary. There are several/many projects that have the same patch review process regardless of the complexity/scope of the patch. For instance the sssd project requires 2 person review of every commit. I would recommend that the process is kept as uniform as possible to minimize complexity.
- missing user's roles on patch review process. One part what Gerrit brings (besides the patches being available online without the need for additional email communication) being the patch reviewer's role separation - there are users with ad hoc / a priori permission to submit patches (selected into the group once they provided required "level of trust") without the need to wait for ACKs (the "core upstream"). Then there are occasional contributors who based on their time possibilities might comment on particular issue / provide a patch for it, but who actually require some of the admins to submit their patch into the repo after the review. I think this point the current email communication doesn't allow us to implement.
- the features:
...
- the future features:
- feel free to comment here what we are currently missing, and might want in the future (what GitHub has support for, and Fedorahosted doesn't)
Maybe once there is conclusion from this thread / more points, as proposed we should move it to dedicated wiki page to track the already obtained consensus.
Comments welcome.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
* bottlenecks: - ease of contribution: Currently you must have a fedora account in order to participate in the ticketing system hosted on fedorahosted.org. There are substantially more people that have a github account than have a fedora account. Additionally, be requiring a fedora account that is just one more account people must setup/remember/maintain.
-josh
Forgot to mention, thanks for starting this list.
On Apr 9, 2014, at 5:42 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com Sent: Tuesday, April 8, 2014 7:53:38 PM
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
I think the part problem of the stalemate you mention above being we didn't create the analysis yet:
- to identify current bottlenecks,
- to identify current features we need,
- to identify future features we might need to smoothly support scaling etc.
In my opinion it's strange to switch from one hosting vendor to the another without performing this. On one hand as you said the move will take some time / resources, so the motivation should be clearly expressed why it's worthy to spend that time on the move (+ additional time current users to get familiar with the new scheme / process). On the other hand such analysis is necessary yet before we actually perform the move to know for sure, that the move will actually make the things better (that's why we need to identify the bottlenecks).
So instead of asking if we should move from Fedorahosted to GitHub, we should try to identify the list of items a smooth and easy patch proposal & review process should have. We can maintain that list on the mailing list (within this thread) or even create a dedicated wiki page for that (gathering such requirements and allowing mailing list participants to offer enhancements).
To start with such a list, the items which come to mind are as follows:
- bottlenecks:
patch proposal / review process differs from GitHub's one => it's non-trivial for users accustomed to use GitHub way easy to flip to our scheme,
small ratio of using ticketing system functionality => new users don't have a way how to find out list of issues currently being worked at or find the most burning problem,
patch review process not separated by complexity of the fix (in other words same rules are applied for simple typo fixes on one hand, while for the complex rewrites on the other. While obviously simple typo fixes / fixes not actually changing the functionality, but rather fixing some error [failing make etc.] should have higher urgency and could have been [once tested] pushed to the repository without the need for even one ACK),
I’d like to point out that tracking patches on the mailing list seems to be a bottleneck. There have been multiple occasions where contributors have had to remind the list of patch sets that need to be reviewed. This requires the contributor to keep track of what patches need to be approved and what mail message the patch is tied to.
- missing user's roles on patch review process. One part what Gerrit brings (besides the patches being available online without the need for additional email communication) being the patch reviewer's role separation - there are users with ad hoc / a priori permission to submit patches (selected into the group once they provided required "level of trust") without the need to wait for ACKs (the "core upstream"). Then there are occasional contributors who based on their time possibilities might comment on particular issue / provide a patch for it, but who actually require some of the admins to submit their patch into the repo after the review. I think this point the current email communication doesn't allow us to implement.
- the features:
…
Based on some of the bottlenecks identified, I believe there needs to be a tool that tracks patch submissions and their status. Additionally there needs to be a ticketing system to identify what needs to be worked on.
- the future features:
- feel free to comment here what we are currently missing, and might want in the future (what GitHub has support for, and Fedorahosted doesn't)
Maybe once there is conclusion from this thread / more points, as proposed we should move it to dedicated wiki page to track the already obtained consensus.
Comments welcome.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Thanks, -josh
----- Original Message -----
From: "Josh Kayse" Sent: Wednesday, April 9, 2014 3:48:10 PM
Forgot to mention, thanks for starting this list.
No problem.
On Apr 9, 2014, at 5:42 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com Sent: Tuesday, April 8, 2014 7:53:38 PM
On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
Just out of curiosity, what happened with this in the end?
I just noticed a few more suggestions that Github-style pull requests would be really useful.
There were valid opinions expressed for both staying on FedoraHosted and migrating to GitHub. So, effectively, a stalemate.
The SSG community has grown amazingly -- both in contributors and usage -- and because of this success Red Hat is preparing to ship SSG in future versions of RHEL [1]. This exacerbates the need for a manageable ticketing system with easy patch submission as very shortly every RHEL installation will have a copy of SSG. FedoraHosted simply wasn't designed to include the same tooling and developer ecosystem as afforded on GitHub (and that's NOT a ding against it's designers!).
The community is a coalition of the willing. Our shared purpose drives the community, and I strongly feel the need to build out tools that will allow us to scale. I'm concerned -- likely overly so -- at how to prepare for a wave of interest once we begin shipping in RHEL.
With that said, who am I to *mandate* the migration to GitHub? Admittedly part of me wants to just go ahead and do it, however that could come at making a non-trivial amount of people (esp. committers, who would be effected by the change) feel alienated/ignored. Certainly we can't make everyone happy all the time, though.
Thoughts would be *most* welcome.
I think the part problem of the stalemate you mention above being we didn't create the analysis yet:
- to identify current bottlenecks,
- to identify current features we need,
- to identify future features we might need to smoothly support scaling
etc.
In my opinion it's strange to switch from one hosting vendor to the another without performing this. On one hand as you said the move will take some time / resources, so the motivation should be clearly expressed why it's worthy to spend that time on the move (+ additional time current users to get familiar with the new scheme / process). On the other hand such analysis is necessary yet before we actually perform the move to know for sure, that the move will actually make the things better (that's why we need to identify the bottlenecks).
So instead of asking if we should move from Fedorahosted to GitHub, we should try to identify the list of items a smooth and easy patch proposal & review process should have. We can maintain that list on the mailing list (within this thread) or even create a dedicated wiki page for that (gathering such requirements and allowing mailing list participants to offer enhancements).
To start with such a list, the items which come to mind are as follows:
- bottlenecks:
- patch proposal / review process differs from GitHub's one => it's
non-trivial for users accustomed to use GitHub way easy to flip to our scheme,
- small ratio of using ticketing system functionality => new users don't
have a way how to find out list of issues currently being worked at or find the most burning problem,
- patch review process not separated by complexity of the fix (in other
words same rules are applied for simple typo fixes on one hand, while for the complex rewrites on the other. While obviously simple typo fixes / fixes not actually changing the functionality, but rather fixing some error [failing make etc.] should have higher urgency and could have been [once tested] pushed to the repository without the need for even one ACK),
I’d like to point out that tracking patches on the mailing list seems to be a bottleneck. There have been multiple occasions where contributors have had to remind the list of patch sets that need to be reviewed. This requires the contributor to keep track of what patches need to be approved and what mail message the patch is tied to.
Yes, this seems to be a big one. From what I have looked further, the fact the patch might get lost / unnoticed without additional pings was (one of the) reasons why Spacewalk project moved to GitHub from Fedorahosted too: https://www.redhat.com/archives/spacewalk-devel/2014-February/msg00078.html
- missing user's roles on patch review process. One part what Gerrit
brings (besides the patches being available online without the need for additional email communication) being the patch reviewer's role separation - there are users with ad hoc / a priori permission to submit patches (selected into the group once they provided required "level of trust") without the need to wait for ACKs (the "core upstream"). Then there are occasional contributors who based on their time possibilities might comment on particular issue / provide a patch for it, but who actually require some of the admins to submit their patch into the repo after the review. I think this point the current email communication doesn't allow us to implement.
- the features:
…
Based on some of the bottlenecks identified, I believe there needs to be a tool that tracks patch submissions and their status. Additionally there needs to be a ticketing system to identify what needs to be worked on.
Yeah, looks so (if we decide to stay at Fedorahosted).
- the future features:
- feel free to comment here what we are currently missing, and might want
in the future (what GitHub has support for, and Fedorahosted doesn't)
Maybe once there is conclusion from this thread / more points, as proposed we should move it to dedicated wiki page to track the already obtained consensus.
Comments welcome.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Thanks, -josh _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On 4/9/14, 10:08 AM, Jan Lieskovsky wrote:
----- Original Message -----
From: "Josh Kayse" Sent: Wednesday, April 9, 2014 3:48:10 PM
Forgot to mention, thanks for starting this list.
No problem.
On Apr 9, 2014, at 5:42 AM, Jan Lieskovskyjlieskov@redhat.com wrote:
----- Original Message -----
>From: "Shawn Wells"shawn@redhat.com >Sent: Tuesday, April 8, 2014 7:53:38 PM > >On 4/8/14, 10:16 AM, Trevor Vaughan wrote: >>>Just out of curiosity, what happened with this in the end? >>> >>>I just noticed a few more suggestions that Github-style pull requests >>>would be really useful. > >There were valid opinions expressed for both staying on FedoraHosted and >migrating to GitHub. So, effectively, a stalemate. > >The SSG community has grown amazingly -- both in contributors and usage >-- and because of this success Red Hat is preparing to ship SSG in >future versions of RHEL [1]. This exacerbates the need for a manageable >ticketing system with easy patch submission as very shortly every RHEL >installation will have a copy of SSG. FedoraHosted simply wasn't >designed to include the same tooling and developer ecosystem as afforded >on GitHub (and that's NOT a ding against it's designers!). > >The community is a coalition of the willing. Our shared purpose drives >the community, and I strongly feel the need to build out tools that will >allow us to scale. I'm concerned -- likely overly so -- at how to >prepare for a wave of interest once we begin shipping in RHEL. > >With that said, who am I to*mandate* the migration to GitHub? >Admittedly part of me wants to just go ahead and do it, however that >could come at making a non-trivial amount of people (esp. committers, >who would be effected by the change) feel alienated/ignored. Certainly >we can't make everyone happy all the time, though. > >Thoughts would be*most* welcome.
I think the part problem of the stalemate you mention above being we didn't create the analysis yet:
- to identify current bottlenecks,
- to identify current features we need,
- to identify future features we might need to smoothly support scaling
etc.
In my opinion it's strange to switch from one hosting vendor to the another without performing this. On one hand as you said the move will take some time / resources, so the motivation should be clearly expressed why it's worthy to spend that time on the move (+ additional time current users to get familiar with the new scheme / process). On the other hand such analysis is necessary yet before we actually perform the move to know for sure, that the move will actually make the things better (that's why we need to identify the bottlenecks).
For what it's worth, when I was playing around, importing the source from FedoraHosted to GitHub was exceedingly trivial. It took just minutes.
IIRC, I refreshed my local repo, reset my remote origin URL in .git/config to GitHub, and did a push.
Current commiters would need to do the same. Once the URL was updated everything just worked. Also, as a wonderful surprise, it kept 'git log' information in tact. If your GitHub EMail matches the one for prior commits, everything syncs up.
So instead of asking if we should move from Fedorahosted to GitHub, we should try to identify the list of items a smooth and easy patch proposal & review process should have. We can maintain that list on the mailing list (within this thread) or even create a dedicated wiki page for that (gathering such requirements and allowing mailing list participants to offer enhancements).
To start with such a list, the items which come to mind are as follows:
- bottlenecks:
- patch proposal / review process differs from GitHub's one => it's
non-trivial for users accustomed to use GitHub way easy to flip to our scheme,
- small ratio of using ticketing system functionality => new users don't
have a way how to find out list of issues currently being worked at or find the most burning problem,
- patch review process not separated by complexity of the fix (in other
words same rules are applied for simple typo fixes on one hand, while for the complex rewrites on the other. While obviously simple typo fixes / fixes not actually changing the functionality, but rather fixing some error [failing make etc.] should have higher urgency and could have been [once tested] pushed to the repository without the need for even one ACK),
I’d like to point out that tracking patches on the mailing list seems to be a bottleneck. There have been multiple occasions where contributors have had to remind the list of patch sets that need to be reviewed. This requires the contributor to keep track of what patches need to be approved and what mail message the patch is tied to.
Yes, this seems to be a big one. From what I have looked further, the fact the patch might get lost / unnoticed without additional pings was (one of the) reasons why Spacewalk project moved to GitHub from Fedorahosted too: https://www.redhat.com/archives/spacewalk-devel/2014-February/msg00078.html
+1
- missing user's roles on patch review process. One part what Gerrit
brings (besides the patches being available online without the need for additional email communication) being the patch reviewer's role separation - there are users with ad hoc / a priori permission to submit patches (selected into the group once they provided required "level of trust") without the need to wait for ACKs (the "core upstream"). Then there are occasional contributors who based on their time possibilities might comment on particular issue / provide a patch for it, but who actually require some of the admins to submit their patch into the repo after the review. I think this point the current email communication doesn't allow us to implement.
- the features:
…
Based on some of the bottlenecks identified, I believe there needs to be a tool that tracks patch submissions and their status. Additionally there needs to be a ticketing system to identify what needs to be worked on.
Yeah, looks so (if we decide to stay at Fedorahosted).
We can setup a gerrit.ssgproject.org for this purpose. I've arranged free web hosting provided by Red Hat on OpenShift. We haven't utilized it much though.
##
- the future features:
- feel free to comment here what we are currently missing, and might want
in the future (what GitHub has support for, and Fedorahosted doesn't)
Maybe once there is conclusion from this thread / more points, as proposed we should move it to dedicated wiki page to track the already obtained consensus.
Comments welcome.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
For what it's worth, when I was playing around, importing the source from FedoraHosted to >GitHub was exceedingly trivial. It took just minutes.
IIRC, I refreshed my local repo, reset my remote origin URL in .git/config to GitHub, and >did a push.
Current commiters would need to do the same. Once the URL was updated everything just >worked. Also, as a wonderful surprise, it kept 'git log' information in tact. If your >GitHub EMail matches the one for prior commits, everything syncs up.
I can confirm this, I copied the official FedoraHosted repo to my Github account while doing some initial work on a new profile project. In doing so, it picked up all the commit history, release, branches, tags, and contributors. You can tell who of the committers already has GitHub accounts by the contributor list.
It was as simple as Shawn mentioned, I cloned from FH to local then pushed from local to a new repo @ Github.
https://github.com/nzwulfin/scap-security-guide is the GitHub repo in question (very old, no warrantees)
-Matt
Matt Micene Solution Architect, Platforms RHCA #100-002-435 DLT Solutions
scap-security-guide@lists.fedorahosted.org