----- 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).
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),
- 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
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
