[RFC] time to move to github?
Jan Lieskovsky
jlieskov at redhat.com
Wed Apr 9 14:08:28 UTC 2014
----- 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).
> >
> > 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
>
> > - 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).
>
> > * 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
>
> Thanks,
> -josh
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
More information about the scap-security-guide
mailing list