----- 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(a)redhat.com> wrote:
> ----- Original Message -----
>> From: "Shawn Wells" <shawn(a)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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Thanks,
-josh
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team