Hello Trevor,
Can you be more specific what makes that patch review process easy? Anything
----- 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*
else behind having the patch review handled via Gerrit?
So would just request Gerrit instance for SSG project via the Fedora infrastructure
> particularly when combined with the new Gerrit
> system that's free for FOSS projects.
solve our obstacles? [*]
[*] You to understand I am not against moving to GitHub. Just trying to identify
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
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
>