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.tur...@gmail.com> wrote: > - [ ] Paste-able links > > On Sun, Nov 30, 2014 at 12:31 AM, Wes Turner <wes.tur...@gmail.com> wrote: > >> - [ ] Stable URIs >> - [ ] Commit hashes >> >> On Sun, Nov 30, 2014 at 12:11 AM, Wes Turner <wes.tur...@gmail.com> >> wrote: >> >>> - [ ] Markdown >>> - [ ] ReStructuredText >>> >>> - [ ] Review (why are these out of band?) >>> >>> On Sat, Nov 29, 2014 at 11:34 PM, Wes Turner <wes.tur...@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 <don...@stufft.io> >>>> wrote: >>>> >>>>> >>>>> > On Nov 30, 2014, at 12:06 AM, Ben Finney <ben+pyt...@benfinney.id.au> >>>>> wrote: >>>>> > >>>>> > Nick Coghlan <ncogh...@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. >>>>> _______________________________________________ >>>>> Python-Dev mailing list >>>>> Python-Dev@python.org >>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>> Unsubscribe: >>>>> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com >>>>> >>>> >>>> >>> >> >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
