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 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).

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
> > 
> >> 
> >> 
> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655
> > _______________________________________________


-- 
Shawn Wells
Director, Innovation Programs
shawn@redhat.com | 443.534.0130
@shawndwells