On Apr 9, 2014, at 5:42 AM, Jan Lieskovsky <[email protected]> wrote:
> ----- Original Message ----- >> From: "Shawn Wells" <[email protected]> >> 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 > >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655 > _______________________________________________ > scap-security-guide mailing list > [email protected] > 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 _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
