<div dir="ltr">Specifically, which features are most ideal here?<div><br></div><div>- [ ] Userbase</div><div>- [ ] TTW editing only over SSL (see: Zope 2)</div><div>- [ ] Pull Requests (see also: BitBucket, Torvalds rant)</div><div>- [ ] Simple Issue Tagging</div><div>- [ ] Pingbacks</div><div>- [ ] CI Integration</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 29, 2014 at 11:27 PM, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Nov 30, 2014, at 12:06 AM, Ben Finney <<a href="mailto:ben%2Bpython@benfinney.id.au">ben+python@benfinney.id.au</a>> wrote:<br>
><br>
> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> writes:<br>
><br>
>> 1. I strongly believe that the long term sustainability of the overall<br>
>> open source community requires the availability and use of open source<br>
>> infrastructure.<br>
><br>
> I concur. This article <URL:<a href="http://mako.cc/writing/hill-free_tools.html" target="_blank">http://mako.cc/writing/hill-free_tools.html</a>><br>
> makes the arguments well, IMO.<br>
><br>
>> 2. I also feel that this proposal is far too cavalier in not even<br>
>> discussing the possibility of helping out the Mercurial team […] we'd<br>
>> prefer to switch to something else entirely rather than organising a<br>
>> sprint with them at PyCon to help ensure that our existing Mercurial<br>
>> based infrastructure is approachable for git & GitHub users?<br>
><br>
> Exactly. For such a core tool, instead of pushing proprietary platforms<br>
> at the expense of software freedom, the sensible strategy for a project<br>
> (Python) that hopes to be around in the long term is to use and improve<br>
> the free software platforms.<br>
<br>
</span>I think there is a big difference here between using a closed source VCS<br>
or compiler and using a closed source code host. Namely in that the<br>
protocol is defined by git so switching from one host to another is easy.<br>
<br>
It’s akin to saying that if we chose to run the PyPI services on a Windows<br>
machine that it is somehow makes it less-free even though we could<br>
have chosen to run it on a “free” OS and we weren’t doing much, if anything,<br>
to tie us to that particular OS.<br>
<br>
If it makes people feel better we can continue to support the existing<br>
mechanisms of contribution, then people can choose between interacting<br>
with a “non free” host and “free” tooling. I suspect most people will choose<br>
the “non-free” tooling.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
</div></div></blockquote></div><br></div>