[RFC] time to move to github?

Shawn Wells shawn at redhat.com
Wed Apr 9 19:28:08 UTC 2014


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 at redhat.com>  wrote:
>> >
>>> > >----- Original Message -----
>>>> > >>From: "Shawn Wells"<shawn at 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 at redhat.com | 443.534.0130
@shawndwells

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140409/a7a163fe/attachment.html>


More information about the scap-security-guide mailing list