[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