<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/9/14, 10:08 AM, Jan Lieskovsky
wrote:<br>
</div>
<blockquote
cite="mid:939175155.2566880.1397052508759.JavaMail.zimbra@redhat.com"
type="cite">
<pre wrap="">----- Original Message -----
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>From: "Josh Kayse"
<span class="moz-txt-citetags">> </span>Sent: Wednesday, April 9, 2014 3:48:10 PM
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>Forgot to mention, thanks for starting this list.
</pre>
</blockquote>
<pre wrap="">No problem.
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>On Apr 9, 2014, at 5:42 AM, Jan Lieskovsky <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:jlieskov@redhat.com"><jlieskov@redhat.com></a> wrote:
<span class="moz-txt-citetags">> </span>
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> > </span>----- Original Message -----
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> >> </span>From: "Shawn Wells" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:shawn@redhat.com"><shawn@redhat.com></a>
<span class="moz-txt-citetags">> >> </span>Sent: Tuesday, April 8, 2014 7:53:38 PM
<span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>On 4/8/14, 10:16 AM, Trevor Vaughan wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> >>> </span>Just out of curiosity, what happened with this in the end?
<span class="moz-txt-citetags">> >>> </span>
<span class="moz-txt-citetags">> >>> </span>I just noticed a few more suggestions that Github-style pull requests
<span class="moz-txt-citetags">> >>> </span>would be really useful.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>There were valid opinions expressed for both staying on FedoraHosted and
<span class="moz-txt-citetags">> >> </span>migrating to GitHub. So, effectively, a stalemate.
<span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>The SSG community has grown amazingly -- both in contributors and usage
<span class="moz-txt-citetags">> >> </span>-- and because of this success Red Hat is preparing to ship SSG in
<span class="moz-txt-citetags">> >> </span>future versions of RHEL [1]. This exacerbates the need for a manageable
<span class="moz-txt-citetags">> >> </span>ticketing system with easy patch submission as very shortly every RHEL
<span class="moz-txt-citetags">> >> </span>installation will have a copy of SSG. FedoraHosted simply wasn't
<span class="moz-txt-citetags">> >> </span>designed to include the same tooling and developer ecosystem as afforded
<span class="moz-txt-citetags">> >> </span>on GitHub (and that's NOT a ding against it's designers!).
<span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>The community is a coalition of the willing. Our shared purpose drives
<span class="moz-txt-citetags">> >> </span>the community, and I strongly feel the need to build out tools that will
<span class="moz-txt-citetags">> >> </span>allow us to scale. I'm concerned -- likely overly so -- at how to
<span class="moz-txt-citetags">> >> </span>prepare for a wave of interest once we begin shipping in RHEL.
<span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>With that said, who am I to <b class="moz-txt-star"><span class="moz-txt-tag">*</span>mandate<span class="moz-txt-tag">*</span></b> the migration to GitHub?
<span class="moz-txt-citetags">> >> </span>Admittedly part of me wants to just go ahead and do it, however that
<span class="moz-txt-citetags">> >> </span>could come at making a non-trivial amount of people (esp. committers,
<span class="moz-txt-citetags">> >> </span>who would be effected by the change) feel alienated/ignored. Certainly
<span class="moz-txt-citetags">> >> </span>we can't make everyone happy all the time, though.
<span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>Thoughts would be <b class="moz-txt-star"><span class="moz-txt-tag">*</span>most<span class="moz-txt-tag">*</span></b> welcome.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>I think the part problem of the stalemate you mention above being we didn't
<span class="moz-txt-citetags">> > </span>create the analysis yet:
<span class="moz-txt-citetags">> > </span>* to identify current bottlenecks,
<span class="moz-txt-citetags">> > </span>* to identify current features we need,
<span class="moz-txt-citetags">> > </span>* to identify future features we might need to smoothly support scaling
<span class="moz-txt-citetags">> > </span>etc.
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>In my opinion it's strange to switch from one hosting vendor to the another
<span class="moz-txt-citetags">> > </span>without performing this. On one hand as you said the move will take some
<span class="moz-txt-citetags">> > </span>time /
<span class="moz-txt-citetags">> > </span>resources, so the motivation should be clearly expressed why it's worthy to
<span class="moz-txt-citetags">> > </span>spend that time on the move (+ additional time current users to get
<span class="moz-txt-citetags">> > </span>familiar
<span class="moz-txt-citetags">> > </span>with the new scheme / process). On the other hand such analysis is
<span class="moz-txt-citetags">> > </span>necessary
<span class="moz-txt-citetags">> > </span>yet before we actually perform the move to know for sure, that the move
<span class="moz-txt-citetags">> > </span>will
<span class="moz-txt-citetags">> > </span>actually make the things better (that's why we need to identify the
<span class="moz-txt-citetags">> > </span>bottlenecks).</pre>
</blockquote>
</blockquote>
</blockquote>
<br>
For what it's worth, when I was playing around, importing the source
from FedoraHosted to GitHub was exceedingly trivial. It took just
minutes.<br>
<br>
IIRC, I refreshed my local repo, reset my remote origin URL in
.git/config to GitHub, and did a push. <br>
<br>
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.<br>
<br>
<blockquote
cite="mid:939175155.2566880.1397052508759.JavaMail.zimbra@redhat.com"
type="cite">
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">
<pre wrap="">
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>So instead of asking if we should move from Fedorahosted to GitHub, we
<span class="moz-txt-citetags">> > </span>should
<span class="moz-txt-citetags">> > </span>try to identify the list of items a smooth and easy patch proposal & review
<span class="moz-txt-citetags">> > </span>process should have. We can maintain that list on the mailing list (within
<span class="moz-txt-citetags">> > </span>this thread) or even create a dedicated wiki page for that (gathering such
<span class="moz-txt-citetags">> > </span>requirements
<span class="moz-txt-citetags">> > </span>and allowing mailing list participants to offer enhancements).
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>To start with such a list, the items which come to mind are as follows:
<span class="moz-txt-citetags">> > </span>* bottlenecks:
<span class="moz-txt-citetags">> > </span> - patch proposal / review process differs from GitHub's one => it's
<span class="moz-txt-citetags">> > </span> non-trivial
<span class="moz-txt-citetags">> > </span> for users accustomed to use GitHub way easy to flip to our scheme,
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span> - small ratio of using ticketing system functionality => new users don't
<span class="moz-txt-citetags">> > </span> have
<span class="moz-txt-citetags">> > </span> a way how to find out list of issues currently being worked at or find
<span class="moz-txt-citetags">> > </span> the
<span class="moz-txt-citetags">> > </span> most burning problem,
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span> - patch review process not separated by complexity of the fix (in other
<span class="moz-txt-citetags">> > </span> words
<span class="moz-txt-citetags">> > </span> same rules are applied for simple typo fixes on one hand, while for the
<span class="moz-txt-citetags">> > </span> complex rewrites on the other. While obviously simple typo fixes / fixes
<span class="moz-txt-citetags">> > </span> not actually changing the functionality, but rather fixing some error
<span class="moz-txt-citetags">> > </span> [failing
<span class="moz-txt-citetags">> > </span> make etc.] should have higher urgency and could have been [once tested]
<span class="moz-txt-citetags">> > </span> pushed
<span class="moz-txt-citetags">> > </span> to the repository without the need for even one ACK),
<span class="moz-txt-citetags">> > </span>
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>I’d like to point out that tracking patches on the mailing list seems to be a
<span class="moz-txt-citetags">> </span>bottleneck. There have been multiple occasions where contributors have had
<span class="moz-txt-citetags">> </span>to remind the list of patch sets that need to be reviewed. This requires
<span class="moz-txt-citetags">> </span>the contributor to keep track of what patches need to be approved and what
<span class="moz-txt-citetags">> </span>mail message the patch is tied to.
</pre>
</blockquote>
<pre wrap="">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:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/archives/spacewalk-devel/2014-February/msg00078.html">https://www.redhat.com/archives/spacewalk-devel/2014-February/msg00078.html</a></pre>
</blockquote>
<br>
+1 <br>
<br>
<br>
<blockquote
cite="mid:939175155.2566880.1397052508759.JavaMail.zimbra@redhat.com"
type="cite">
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> > </span> - missing user's roles on patch review process. One part what Gerrit
<span class="moz-txt-citetags">> > </span> brings (besides
<span class="moz-txt-citetags">> > </span> the patches being available online without the need for additional email
<span class="moz-txt-citetags">> > </span> communication)
<span class="moz-txt-citetags">> > </span> being the patch reviewer's role separation - there are users with ad hoc
<span class="moz-txt-citetags">> > </span> / a priori
<span class="moz-txt-citetags">> > </span> permission to submit patches (selected into the group once they provided
<span class="moz-txt-citetags">> > </span> required
<span class="moz-txt-citetags">> > </span> "level of trust") without the need to wait for ACKs (the "core
<span class="moz-txt-citetags">> > </span> upstream"). Then there
<span class="moz-txt-citetags">> > </span> are occasional contributors who based on their time possibilities might
<span class="moz-txt-citetags">> > </span> comment on
<span class="moz-txt-citetags">> > </span> particular issue / provide a patch for it, but who actually require some
<span class="moz-txt-citetags">> > </span> of the admins
<span class="moz-txt-citetags">> > </span> to submit their patch into the repo after the review. I think this point
<span class="moz-txt-citetags">> > </span> the current
<span class="moz-txt-citetags">> > </span> email communication doesn't allow us to implement.
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>* the features:
<span class="moz-txt-citetags">> > </span> …
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>Based on some of the bottlenecks identified, I believe there needs to be a
<span class="moz-txt-citetags">> </span>tool that tracks patch submissions and their status. Additionally there
<span class="moz-txt-citetags">> </span>needs to be a ticketing system to identify what needs to be worked on.
</pre>
</blockquote>
<pre wrap="">Yeah, looks so (if we decide to stay at Fedorahosted).</pre>
</blockquote>
<br>
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.<br>
<br>
##<br>
<br>
<blockquote
cite="mid:939175155.2566880.1397052508759.JavaMail.zimbra@redhat.com"
type="cite">
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> > </span>* the future features:
<span class="moz-txt-citetags">> > </span> - feel free to comment here what we are currently missing, and might want
<span class="moz-txt-citetags">> > </span> in the future
<span class="moz-txt-citetags">> > </span> (what GitHub has support for, and Fedorahosted doesn't)
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>Maybe once there is conclusion from this thread / more points, as proposed
<span class="moz-txt-citetags">> > </span>we should move
<span class="moz-txt-citetags">> > </span>it to dedicated wiki page to track the already obtained consensus.
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>Comments welcome.
<span class="moz-txt-citetags">> > </span>
<span class="moz-txt-citetags">> > </span>Thank you && Regards, Jan.
<span class="moz-txt-citetags">> > </span>--
<span class="moz-txt-citetags">> > </span>Jan iankko Lieskovsky / Red Hat Security Technologies Team
<span class="moz-txt-citetags">> > </span>
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>
<span class="moz-txt-citetags">> >> </span>[1] <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=1038655">https://bugzilla.redhat.com/show_bug.cgi?id=1038655</a>
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> > </span>_______________________________________________</pre>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Shawn Wells
Director, Innovation Programs
<a class="moz-txt-link-abbreviated" href="mailto:shawn@redhat.com">shawn@redhat.com</a> | 443.534.0130
@shawndwells</pre>
</body>
</html>