<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 16, 2014 at 10:52 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Sep 16, 2014 at 5:01 PM, Russell Bryant <span dir="ltr"><<a href="mailto:russell@russellbryant.net" target="_blank">russell@russellbryant.net</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Sep 16, 2014 at 3:48 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:</span> </div></div></div></blockquote></span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>So, to set what I hope are a few guidelines:<br></div></div></div></div></div></div></div></blockquote></span></div></div></div></blockquote></span><div>(1) I know this is a subject with a lot of opinions, and coming to a concurrence on something that is opinion based is tough. Voice opinions after thinking, "would I be willing to spend time working on this"?<br>(2) This is a project that can easily suck several developers for a long time if the scope of it expands substantially. The scope should hopefully be kept as tight as possible, as we will have a lot of re-tooling to do once the git move occurs (all CI, code review, releasing, etc.)<br></div><div>(3) The Asterisk project has several hard requirements, a few softer ones, that have to be met:<br></div><div>  * Code submitted has to be assigned to a CLA. We have to verify that people proposing patches have acknowledged that they were licensed to submit said patch in some fashion.<br></div><div>  * Issue tracking has to be done in JIRA (large investment, huge cost in moving to anything else right now).<br></div><div>  * Code must be reviewed.<br></div><div>  * Any substitute for Review Board, Bamboo, or other existing tools should have obvious benefits over the existing tools.<br></div><span class=""><div></div></span></div></div></div></blockquote><div>  </div><div>Very nice set of guidelines.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>For the last few years, most of my time has been going into OpenStack [1].  We use git and I have become a big fan of our workflow and infrastructure.  It's all open source and reusable.</div><div><br></div><div>From a high level, all patches go to a code review system.  *Every* patch must be peer reviewed (usually by 2 people, but that's a policy decision).  *Every* patch must also pass tests.  Once a patch passes both tests and peer review, it is automatically merged into the repository.</div><div><br></div><div>I *love* that workflow for several reasons.  If it's appealing, it's probably much easier to do it now while you're doing a big switch anyway.  If you're not sold, I'm certainly not hurt.  Like I said, I just wanted to offer info.  The current plan will be less up front setup for sure.</div></div></div></div></blockquote><div><br></div></span><div>I am a huge fan of this.<br><br></div><div>We've been moving (slowly but surely) towards this model. Code is reviewed more often than not, and with Crowd integration, anyone can propose a patch. Tests are written for the vast majority of new work. We *do* still have a problem with bouncing tests - and while Bamboo may point the finger more at 12+ currently (due to a current spat with native RTP bridges, direct media, and transfers) - the bouncing is actually more pernicious in many ways with the 1.8/11 branches. We'd have to solve that problem if we move to this model.<br><br>I don't consider that a bad thing at all.</div></div></div></div></blockquote><div><br></div><div>OpenStack struggles with this problem, as well.  It can be incredibly painful.  If a test is just failing some of the time, you get developers confused and frustrated that seemingly unrelated failures are blocking their patch.  Worse, you may get a mess of a backlog in the CI system as things have to get re-run.  We keep a dashboard of current bugs being hit sorted by frequency so we know what the biggest offenders are. <a href="http://status.openstack.org/elastic-recheck/">http://status.openstack.org/elastic-recheck/</a>  (Note that running this is another set of infrastructure that I didn't mention, but it's interesting to see I think.)</div><div><br></div><div>There are things you can do to mitigate the impact while working to improve things over time.  You can mark some CI jobs as "non-voting", meaning that the job runs and you see the results on the patch, but it doesn't affect the overall pass/fail result.  If you split up tests into some subsets, you can have some jobs voting and some non-voting.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>If you're a hands on kind of person, browse <a href="http://review.openstack.org/" target="_blank">http://review.openstack.org/</a> for open code reviews.  You can also see patches going through CI pipelines on <a href="http://status.openstack.org/zuul//" target="_blank">http://status.openstack.org/zuul//</a></div><div><br></div><div>The major tools involved are:</div><div><br></div><div> - gerrit for code review and repository management [2][3]</div><div> - jenkins for CI [4]</div><div> - Zuul, A CI job scheduler that automates running things in response to events on gerrit. [5]</div><div> - CGit, repo hosting [6][7]</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>This would replace Review Board and Bamboo as well, so we'll need to consider the effort involved with that.<br></div><span class=""><div></div></span></div></div></div></blockquote><div><br></div><div>Yes, for sure.  I think it's worthwhile long term, and it's at least largely automated and proven, so that helps.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Everything we use is managed via puppet and all of the configuration is in git.  It's designed to be reusable.  The folks that run it have documented how to re-use it [8] and are quite friendly.  You can find them in #openstack-infra on freenode.</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>Awesome. I'll do that - in particular, I'm interested what is involved in the recurring maintenance of gerrit/Jenkins/Zuul.<br></div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>On IRC, jeblair is the infrastructure project lead.  He's also an Asterisk fan, so that helps.  :-)</div><div><br></div><div>Depending on the depth of the question(s), it may be better to use the openstack-infra mailing list:</div><div><br></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>-- Git hooks</div><div><br></div><div>For what, exactly?  It's probably easier to discuss the problem that needs to be solved.</div></div></div></div></blockquote><div><br></div></span><div>In general, there are a few use cases for either git hooks or web hooks (or something else, such as the Gerrit event stream):<br></div><div>(1) Auto-close issues in JIRA<br></div></div></div></div></blockquote><div><br></div><div>It looks like there is a git plugin that supports smart commits.</div><div><br></div><div><a href="https://marketplace.atlassian.com/plugins/com.xiplink.jira.git.jira_git_plugin">https://marketplace.atlassian.com/plugins/com.xiplink.jira.git.jira_git_plugin</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>(2) Auto-close reviews in Review Board (but clearly not an issue in this case)<br></div><div>(3) Prevent pushes from private branches going to public branches. This would have to be done a pre-hook in some fashion.<br><br></div><div>I think there are various ways to achieve all three of these, although admittedly the 'private branch' one is the most tricky and annoying.</div></div></div></div></blockquote><div><br></div><div>Yeah, that is kind of tricky and annoying.  :-)</div><div><br></div><div>It does seem like a git hook could provide the type of validation done today on the svn server side, though.  As long as the branch is marked as "private" in some way (the remote branch it's tracking, some special file, ...), you could validate the push location, I suppose.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- Web hooks</div><div><br></div><div>Again, it's probably worth discussing the use case.  Gerrit has an event stream.  That event stream includes merges.  Tools to do things in responses to merges (which could be running a web hook) listen and react.</div><div><br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>-- Performance</div><div><br></div><div>Yes.  :-)</div><div><br></div><div>There's lots of stats I could dig up, but as one example, I track code review stats for a subset of projects on <a href="http://review.openstack.org" target="_blank">review.openstack.org</a>  In the last year, for that subset, there have been 266,127 code reviews done (avg > 700 per day).  That gives some sense of scale.  From a quick glance at the CI status page (<a href="http://status.openstack.org/zuul/" target="_blank">http://status.openstack.org/zuul/</a>), it has been launching about 500-600 jobs per hour today.</div><div><br></div><div>-- Process Recommendation</div><div><br></div><div>I discussed this a good bit above, but I'm happy to answer questions.</div><span></span></div></div></div></blockquote><div><br></div></span><div>Wiki page updated!<br><br></div><div>You make a lot of good points, and I think it's worth honestly exploring this option. It does look like it would be more work, but as you pointed out, now is the time to do it - and it may not be substantially more than what we're already going to have to do. We'll have to take a deeper look at Gerrit and find out.<br><br>Thanks for weighing in on this!<br></div></div></div></div></blockquote><div><br></div><div>You're welcome!  If nothing else, it's interesting to explore the different approaches projects are taking for inspiration.  No matter what you end up with, git <3. </div><div><br></div><div>-- </div><div>Russell Bryant</div></div></div></div>