[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