Explicitly aiming for Kallithea adoption amongst some significant Python user communities?

Sun Dec 7 18:45:10 EST 2014

On 8 Dec 2014 08:10, "Paul Nathan" <pnathan at alumni.uidaho.edu> wrote:
>
> (ack, forgot to reply-all the list)
>
> Nick,
>
> 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:
>
> 0. OpenID integration would be awesome.

Yep, single sign-on support helps significantly with lowering barriers to
entry for self-hosted infrastructure.

> 1. Test before merge should be something that is considered (c.f.,
https://blogs.janestreet.com/making-never-break-the-build-scale/ 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.
> 2. Integration with Jenkins over Buildbot?- Jenkins is kind of the broad
standard.

For both of these, my own near term priority is CPython's infrastructure,
which is post-merge CI on BuildBot.

>From a broader perspective, yes, Jenkins CI integration and pre-merge CI
support are both interesting capabilities.

> 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  ;) ).

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).

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.

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.

>
> 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.

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.

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.

More details are available at http://ci.openstack.org/zuul.html

Regards,
Nick.

>
> On Fri, Dec 5, 2014 at 4:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> Hi folks,
>>
>> I'm not sure if you're aware, but a while ago I wrote a draft proposal
>> to set up a Kallithea instance at "forge.python.org":
>> https://www.python.org/dev/peps/pep-0474/
>>
>> A competing proposal has since been put forward, suggesting we move
>> the affected repositories to GitHub instead:
>> https://www.python.org/dev/peps/pep-0481/
>>
>> Brett Cannon is now going to be coordinating a decision making process
>> (exact timeline TBD, but likely over the next couple of months) to
>> decide how we upgrade CPython's core development tools. Brett's
>> overview of the (complex) situation can be read at
>> https://gist.github.com/brettcannon/a9c9a5989dc383ed73b4 and my own
>> overview of our current core workflow issues (and my initial, now
>> somewhat dated, draft of a proposed solution) is at
>> https://www.python.org/dev/peps/pep-0462/
>>
>> I'd really like for Kallithea to be the centrepiece for that workflow
>> upgrade, but I also don't want to repeat our past mistakes, where we
>> sometimes ended up relying on various pieces of infrastructure
>> software without first establishing a strong relationship with the
>> relevant upstream development community.
>>
>> So my question for the Kallithea development community is whether
>> folks would be interested in (or at least OK with) the idea of
>> specifically targeting Kallithea adoption by particular Python user
>> communities?
>>
>> While I'm interested in working on that myself (and am optimistic
>> about my chances of getting other folks interested), it isn't
>> something that I would consider acceptable to push for without broad
>> support amongst the existing Kallithea developers for the idea of
>> taking the interests of those communities into account when deciding
>> on the overall direction of the project.
>>
>> My own near term interest is obviously in the CPython workflow
>> upgrade, and there are several feature requests that would likely come
>> up in that context:
>>
>> * integration with Roundup for issue tracking
>> * integration with BuildBot for CI testing of reviewed patches
>> * pushing to a local git mirror of a master Mercurial repo
>> automatically on each commit
>> * pushing to GitHub/BitBucket mirrors automatically on each commit
>> * allowing folks to log in with their GitHub/BitBucket accounts
>> * accepting PRs via GitHub/BitBucket
>> * supporting easy deployment and management with Salt
>>
>> Beyond the question of CPython's workflow, I know that the Fedora
>> community have been looking to upgrade the services on
>> fedorahosted.org for quite some time (mostly focused on GitLab, but
>> they've been having issues getting that into a state that the Fedora
>> Infrastructure team consider maintainable), and there I suspect the
>> main additional features of interest above and beyond those I
>> mentioned for CPython would be:
>>
>> * supporting easy deployment and management with Ansible
>> * integration with Bugzilla for issue tracking
>>
>> Longer term (as described in PEP 462), I'm interested in the idea of
>> switching to an OpenStack style merge gating workflow, which would
>> potentially mean integrating with the Zuul merge pipelining system.
>>
>> Getting even more speculative, I know that there are a number of folks
>> in the OpenStack infrastructure team that aren't particularly happy
>> with the web UI component of the Gerrit code review system. Having
>> Kallithea natively support the Gerrit style branching and change
>> identification model ("refs/for/target" etc) and create appropriate
>> review requests on the server (including the ability to review the
>> diff between different versions of the request) could be a very nice
>> enhancement.
>>
>> However, as noted above, I'm a newcomer here, and I wouldn't want to
>> start pushing for these kinds of "specific audience" driven
>> capabilities without first checking that folks would be OK with my
>> doing that.
>>
>> Regards,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> _______________________________________________
>> kallithea-general mailing list
>> kallithea-general at sfconservancy.org
>> http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20141208/349934da/attachment-0001.html>