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

[Nick Coghlan]

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