<p dir="ltr"><br>
On 8 Dec 2014 08:10, "Paul Nathan" <<a href="mailto:pnathan@alumni.uidaho.edu">pnathan@alumni.uidaho.edu</a>> wrote:<br>
><br>
> (ack, forgot to reply-all the list)<br>
><br>
> Nick,<br>
><br>
> I'm not a developer or someone who supports Kallithea at my day job, just an interested kibitzer who wants to implement it sometime.  I would remark on a few things though:<br>
><br>
> 0. OpenID integration would be awesome.</p>
<p dir="ltr">Yep, single sign-on support helps significantly with lowering barriers to entry for self-hosted infrastructure.</p>
<p dir="ltr">> 1. Test before merge should be something that is considered (c.f., <a href="https://blogs.janestreet.com/making-never-break-the-build-scale/">https://blogs.janestreet.com/making-never-break-the-build-scale/</a> for discussion here). After working in a few shops, I have to say that a workflow & system that has the "pushed but not confirmed integrated" is a better approach than the "merge and push" out of the box behavior we get with git/hg.<br>
> 2. Integration with Jenkins over Buildbot?- Jenkins is kind of the broad standard.</p>
<p dir="ltr">For both of these, my own near term priority is CPython's infrastructure, which is post-merge CI on BuildBot.</p>
<p dir="ltr">From a broader perspective, yes, Jenkins CI integration and pre-merge CI support are both interesting capabilities.</p>
<p dir="ltr">> 3. Gerrit's "difference between pushes" is nice, but the squash-centric workflow is, ahem, something that I simply can't get behind - it's a net negative, afaict. I also found the refs/for/target system broadly distasteful (fine, I found Gerrit distasteful, period, vs Kiln, Bitbucket, SSH/file based systems, or GitHub  ;) ).</p>
<p dir="ltr">I don't understand what you mean by "squash-centric workflow" - I find the implicit squashing in the pull request model far more likely to encourage folks to just collapse everything into a single commit (either that or the commit history is a complete record of their local development iterations, rather than a clearly structured sequence of logically distinct refactorings, bug fixes and feature additions).</p>
<p dir="ltr">By contrast, Gerrit's support for patch chains is excellent, as it makes it straightforward not only to review each patch in the chain separately, but also to run CI on each one. It should work even better with evolve than it does in git, since evolve should do away with need for "ChangeId" markers in commit messages.</p>
<p dir="ltr">If it's about wanting the option to do a review of the whole commit chain against the branch point, that should just be a matter of offering an additional "base" option in the review UI.</p>
<p dir="ltr">><br>
> Can you expand on the OpenStack/Zuul system? I'm not familiar with it, and nuances would undoubtably escape a quick survey of mine via wikipedia or the docs.</p>
<p dir="ltr">The key difference is that you *don't* merge approved changes directly - trunk may have moved on since the CI ran. So, to avoid race conditions, OpenStack wrote Zuul to serialise merges that core reviewers have approved, running the integration tests automatically before allowing each merge to proceed.</p>
<p dir="ltr">Doing all those CI runs in series would be too slow, though, so Zuul uses an optimistic pipelining model, where it starts multiple CI runs in parallel for all of the tree states at the head of the merge queue. If everything passes, changes can be merged at the same rate as they're approved. If one fails, the pipeline will be halted at that point, the offending patch removed, and then the rest of the pipeline restarted without the failing commit in the merge queue.</p>
<p dir="ltr">More details are available at <a href="http://ci.openstack.org/zuul.html">http://ci.openstack.org/zuul.html</a></p>
<p dir="ltr">Regards,<br>
Nick.</p>
<p dir="ltr">><br>
> On Fri, Dec 5, 2014 at 4:04 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> Hi folks,<br>
>><br>
>> I'm not sure if you're aware, but a while ago I wrote a draft proposal<br>
>> to set up a Kallithea instance at "<a href="http://forge.python.org">forge.python.org</a>":<br>
>> <a href="https://www.python.org/dev/peps/pep-0474/">https://www.python.org/dev/peps/pep-0474/</a><br>
>><br>
>> A competing proposal has since been put forward, suggesting we move<br>
>> the affected repositories to GitHub instead:<br>
>> <a href="https://www.python.org/dev/peps/pep-0481/">https://www.python.org/dev/peps/pep-0481/</a><br>
>><br>
>> Brett Cannon is now going to be coordinating a decision making process<br>
>> (exact timeline TBD, but likely over the next couple of months) to<br>
>> decide how we upgrade CPython's core development tools. Brett's<br>
>> overview of the (complex) situation can be read at<br>
>> <a href="https://gist.github.com/brettcannon/a9c9a5989dc383ed73b4">https://gist.github.com/brettcannon/a9c9a5989dc383ed73b4</a> and my own<br>
>> overview of our current core workflow issues (and my initial, now<br>
>> somewhat dated, draft of a proposed solution) is at<br>
>> <a href="https://www.python.org/dev/peps/pep-0462/">https://www.python.org/dev/peps/pep-0462/</a><br>
>><br>
>> I'd really like for Kallithea to be the centrepiece for that workflow<br>
>> upgrade, but I also don't want to repeat our past mistakes, where we<br>
>> sometimes ended up relying on various pieces of infrastructure<br>
>> software without first establishing a strong relationship with the<br>
>> relevant upstream development community.<br>
>><br>
>> So my question for the Kallithea development community is whether<br>
>> folks would be interested in (or at least OK with) the idea of<br>
>> specifically targeting Kallithea adoption by particular Python user<br>
>> communities?<br>
>><br>
>> While I'm interested in working on that myself (and am optimistic<br>
>> about my chances of getting other folks interested), it isn't<br>
>> something that I would consider acceptable to push for without broad<br>
>> support amongst the existing Kallithea developers for the idea of<br>
>> taking the interests of those communities into account when deciding<br>
>> on the overall direction of the project.<br>
>><br>
>> My own near term interest is obviously in the CPython workflow<br>
>> upgrade, and there are several feature requests that would likely come<br>
>> up in that context:<br>
>><br>
>> * integration with Roundup for issue tracking<br>
>> * integration with BuildBot for CI testing of reviewed patches<br>
>> * pushing to a local git mirror of a master Mercurial repo<br>
>> automatically on each commit<br>
>> * pushing to GitHub/BitBucket mirrors automatically on each commit<br>
>> * allowing folks to log in with their GitHub/BitBucket accounts<br>
>> * accepting PRs via GitHub/BitBucket<br>
>> * supporting easy deployment and management with Salt<br>
>><br>
>> Beyond the question of CPython's workflow, I know that the Fedora<br>
>> community have been looking to upgrade the services on<br>
>> <a href="http://fedorahosted.org">fedorahosted.org</a> for quite some time (mostly focused on GitLab, but<br>
>> they've been having issues getting that into a state that the Fedora<br>
>> Infrastructure team consider maintainable), and there I suspect the<br>
>> main additional features of interest above and beyond those I<br>
>> mentioned for CPython would be:<br>
>><br>
>> * supporting easy deployment and management with Ansible<br>
>> * integration with Bugzilla for issue tracking<br>
>><br>
>> Longer term (as described in PEP 462), I'm interested in the idea of<br>
>> switching to an OpenStack style merge gating workflow, which would<br>
>> potentially mean integrating with the Zuul merge pipelining system.<br>
>><br>
>> Getting even more speculative, I know that there are a number of folks<br>
>> in the OpenStack infrastructure team that aren't particularly happy<br>
>> with the web UI component of the Gerrit code review system. Having<br>
>> Kallithea natively support the Gerrit style branching and change<br>
>> identification model ("refs/for/target" etc) and create appropriate<br>
>> review requests on the server (including the ability to review the<br>
>> diff between different versions of the request) could be a very nice<br>
>> enhancement.<br>
>><br>
>> However, as noted above, I'm a newcomer here, and I wouldn't want to<br>
>> start pushing for these kinds of "specific audience" driven<br>
>> capabilities without first checking that folks would be OK with my<br>
>> doing that.<br>
>><br>
>> Regards,<br>
>> Nick.<br>
>><br>
>> --<br>
>> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
>> _______________________________________________<br>
>> kallithea-general mailing list<br>
>> <a href="mailto:kallithea-general@sfconservancy.org">kallithea-general@sfconservancy.org</a><br>
>> <a href="http://lists.sfconservancy.org/mailman/listinfo/kallithea-general">http://lists.sfconservancy.org/mailman/listinfo/kallithea-general</a><br>
><br>
><br>
</p>