----- 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 <[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’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 > > _______________________________________________ > > scap-security-guide mailing list > > [email protected] > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > Thanks, > -josh > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
