<div dir="ltr"><div><div><div><div>(ack, forgot to reply-all the list)<br><br></div><div>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></div><div>0. OpenID integration would be awesome.<br></div>1. Test before merge should be something that is considered (c.f., <a href="https://blogs.janestreet.com/making-never-break-the-build-scale/" target="_blank">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></div>2. Integration with Jenkins over Buildbot?- Jenkins is kind of the broad standard. <br></div>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 ;) ).<br><br></div>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.<div class=""><div id=":1py" class="" tabindex="0"><img class="" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 4:04 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" target="_blank">forge.python.org</a>":<br>
<a href="https://www.python.org/dev/peps/pep-0474/" target="_blank">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/" target="_blank">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" target="_blank">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/" target="_blank">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" target="_blank">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>
<span class="HOEnZb"><font color="#888888"><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" target="_blank">http://lists.sfconservancy.org/mailman/listinfo/kallithea-general</a><br>
</font></span></blockquote></div><br></div>