https://kallithea-scm.org/repos/kallithea/files/tip/setup.py
https://github.com/codeinn/vcs/blob/master/setup.py



On Sun, Nov 30, 2014 at 1:16 AM, Wes Turner <wes.turner@gmail.com> wrote:
Is there a kalithea celery task to mirror / SYNC with github, for pull requests and/or issues?

https://pypi.python.org/pypi/Kallithea/
https://kallithea-scm.org/
https://kallithea-scm.org/repos/kallithea
https://bitbucket.org/conservancy/kallithea

http://pythonhosted.org//Kallithea
http://kallithea.readthedocs.org/en/latest/

http://pypi.python.org/pypi/vcs
http://pythonhosted.org//vcs
https://github.com/codeinn/vcs


On Sun, Nov 30, 2014 at 12:50 AM, Wes Turner <wes.turner@gmail.com> wrote:
- [ ] Paste-able links

On Sun, Nov 30, 2014 at 12:31 AM, Wes Turner <wes.turner@gmail.com> wrote:
- [ ] Stable URIs
- [ ] Commit hashes

On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner <wes.turner@gmail.com> wrote:
- [ ] Markdown
- [ ] ReStructuredText

- [ ] Review (why are these out of band?)

On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner <wes.turner@gmail.com> wrote:
Specifically, which features are most ideal here?

- [ ] Userbase
- [ ] TTW editing only over SSL (see: Zope 2)
- [ ] Pull Requests (see also: BitBucket, Torvalds rant)
- [ ] Simple Issue Tagging
- [ ] Pingbacks
- [ ] CI Integration


On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft <donald@stufft.io> wrote:

> On Nov 30, 2014, at 12:06 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
>
> Nick Coghlan <ncoghlan@gmail.com> writes:
>
>> 1. I strongly believe that the long term sustainability of the overall
>> open source community requires the availability and use of open source
>> infrastructure.
>
> I concur. This article <URL:http://mako.cc/writing/hill-free_tools.html>
> makes the arguments well, IMO.
>
>> 2. I also feel that this proposal is far too cavalier in not even
>> discussing the possibility of helping out the Mercurial team […] we'd
>> prefer to switch to something else entirely rather than organising a
>> sprint with them at PyCon to help ensure that our existing Mercurial
>> based infrastructure is approachable for git & GitHub users?
>
> Exactly. For such a core tool, instead of pushing proprietary platforms
> at the expense of software freedom, the sensible strategy for a project
> (Python) that hopes to be around in the long term is to use and improve
> the free software platforms.

I think there is a big difference here between using a closed source VCS
or compiler and using a closed source code host. Namely in that the
protocol is defined by git so switching from one host to another is easy.

It’s akin to saying that if we chose to run the PyPI services on a Windows
machine that it is somehow makes it less-free even though we could
have chosen to run it on a “free” OS and we weren’t doing much, if anything,
to tie us to that particular OS.

If it makes people feel better we can continue to support the existing
mechanisms of contribution, then people can choose between interacting
with a “non free” host and “free” tooling. I suspect most people will choose
the “non-free” tooling.