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<[email protected]> wrote:
>
> >----- Original Message -----
> >>From: "Shawn Wells"<[email protected]>
> >>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
[email protected] | 443.534.0130
@shawndwells
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
