----- 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.*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.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 toI 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[1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655_______________________________________________
-- Shawn Wells Director, Innovation Programs shawn@redhat.com | 443.534.0130 @shawndwells