[RFC] time to move to github?

Kayse, Josh Joshua.Kayse at gtri.gatech.edu
Wed Apr 9 10:23:01 UTC 2014


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).
> 
> 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
> scap-security-guide at lists.fedorahosted.org
> 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


More information about the scap-security-guide mailing list