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

[Paul Nathan]

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

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.

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/20141207/b5114724/attachment.html>