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

[Nick Coghlan]

On 8 December 2014 at 12:45, Mads Kiilerich <mads at kiilerich.com> wrote:
> One of my visions for Kallithea is to avoid lock-in, especially on closed
> software where you don't have any control. I want the internet as my
> "social" network - not something hosted on one site. I want to give people
> the freedom to host their repositories on their own or hosted systems and
> let code and reviews and "pull requests" and "merges" flow between the
> systems.

That's great to hear - this kind of pluggable, component based model
is what I'd like to enable as well, as (depending on how you count) I
have a direct interest in at least three different infrastructure
environments (CPython, beaker-project.org, Red Hat internal), and an
indirect interest in at least two more (fedorahosted.org, upstream
OpenStack), so the monolithic approach of the proprietary hosting
sites really doesn't work for me.

> I will give GitHub credit for having managed to make everybody accept the
> same workflow.

Yeah, as an 80% solution, GitHub is wonderful. The recent python-dev
discussions, and having a colleague point out the existence of
"GerritHub" (which lets you use Gerrit as the code review tool for
your GitHub repos) made me realise there was a potential opportunity
here to make the process of maintaining a repo mirror on GitHub as
painless as possible, which would allow folks to gain many of the
benefits of being present in the GitHub ecosystem, without locking
themselves in to that platform.

> But more than that, I think it is important for projects and
> organizations to establish workflows that fits their own use case. I don't
> think any software can support all reasonable workflows and integrations ...
> and the harder it try, the more it will fail. I think Kallithea has an
> important but also very difficult role to play there. Kallithea should of
> course just work out of the box and also be configurable with more advanced
> features, but it should also stay focussed. There will always be things that
> are better done in customizations or custom development. (The system I
> maintain have something like 20 custom features/changesets that are useful
> for us but not (yet?) are sufficiently generic to be upstreamed. Most of our
> changes are however of general value and done upstream.)

This is the direction I'd like to go as well - have installation
specific configuration, hooks, or even plugins where appropriate, but
also have a path to moving more general improvements upstream.

Since it sounds like that approach is also acceptable from your side,
I'll go ahead and update PEP 474 with some more specific design goals
based on the python-dev discussions, and then start looking at what
can already be done as local hooks, and what may require upstream
contributions to Kallithea.

I've also started work on an OpenShift quickstart (using the existing
Apache licensed quickstart Worldline wrote for RhodeCode as a starting
point), which will hopefully make it easy for folks to try out and
demonstrate their changes while working on Kallithea.

> Some short comments to some of your bullet points:
>
> Issue tracking integration might just require correct configuration of links
> and hooks.
>
> CI might not require more than some Mercurial hooks ... but I guess it also
> could integrate deeply with some PR work flow that probably would be quite
> custom. Zuul also sounds interesting.
>
> Mirroring can also just be done from hooks.

Right, I think all these should be fairly straightforward for the
initial set of support repos we're looking at upgrading. Things get
more interesting once we're talking about the more complex branch
structure in the main CPython repo, but that's out of scope for this
initial phase.

> OpenID-ish login would not be hard to implement. The biggest challenge might
> be how to handle DMCA if you will offer public repo hosting.

We're not currently planning to offer general repo hosting services -
we'll leave that to the commercial players. forge.python.org, at least
initially, will be aimed specifically at CPython and its support
repos, as well as making it available to other folks already using
python.org infrastructure for project hosting (e.g. Jython).

> Cross site PRs ... it is still a bit unknown what that really would mean and
> how we can interact with the big existing hosting sites.

Right, this is the one I consider the biggest "R&D" type question in
my current forge.python.org concept. My current thinking is to make it
possible to register a Kallithea instance as a linked GitHub
application, and then have a webhook triggered off GitHub pull_request
events that syncs the content into a new (or updated) pull request on
the Kallithea side. As a reviewer, you'd still need to go back to
GitHub if you wanted to give the submitter feedback, but the merge
would still happen on the Kallithea instance. (I don't think the
GitHub interface lets you mark a PR as "accepted-but-not-merged", so
that aspect of the user experience will be a bit clumsy)

While I don't know exactly how to make that work as yet, Ian Cordasco,
the author of the github3 client library, offered to help out with any
GitHub integration questions python-dev had, so I'm confident I'll be
able to figure the GitHub side out.

On the Kallithea side, it seems to be that it might be possible to
structure this as a more general "mirror management" capability, that
went beyond simply doing a "hg push" or "git push" on every commit,
and instead allowed the installation of plugins to configure and store
additional data and handle HTTPS requests related to a particular
mirror.

> I am not aware of any saltstack integration but there is
> https://github.com/b6d/ansible_modules_kallithea .

Tymoteusz Jankowski has started some prelimary work for deploying
Kallithea through the PSF's Salt infrastructure at
https://github.com/xliiv/psf-salt/compare/kallithea?expand=1

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia