On Jan 03, 2016, at 03:40 PM, Nick Coghlan wrote:
>For the last hosting transition, PEP 374 covered the process of
>choosing a distributed VCS, while PEP 385 covered the actual
>Subversion -> Mercurial transition, and I think that's a good way to
>go.
Yes, for the transition tasks, a PEP makes se
On Sat, 2 Jan 2016 at 20:39 Eric Snow wrote:
> First, let me add my thanks for sorting this out!
>
> On Jan 2, 2016 11:45, "Brett Cannon" wrote:
> > Well, "support" as in "allow". We won't be keeping Rietveld around (part
> of this move is so we can get off of Rietveld).
>
> I guess I'd missed t
Eric Snow writes:
> I guess I'd missed this point. In my opinion, code review in Github is
unpleasant for anything but small PRs and even for those when there's much
back-and-forth. At work we switched to Github. We moved code review off to
reviewboard a few months later. Setting up the webhoo
Rietveld is no longer an option as our fork of the project is unmaintained
(it was one of the key reasons we even started this process).
On Sun, Jan 3, 2016, 10:28 Stefan Krah wrote:
> Eric Snow writes:
> > I guess I'd missed this point. In my opinion, code review in Github is
> unpleasant for
(Though honestly if we were okay with hosting by Google, Rietveld would
still be an option. But I agree we should first figure out whether we can
live with GitHub's review.)
On Sun, Jan 3, 2016 at 11:26 AM, Brett Cannon wrote:
> Rietveld is no longer an option as our fork of the project is unmai
Ah, the last part there is a nice algorithm. It determines the intended
merge order when patches are submitted to the queue, then runs tests for
multiple patches in parallel. So, assuming most patches pass their tests,
the rate at which patches can land is limited only by how fast it can run
parall
On 4 January 2016 at 03:35, Brett Cannon wrote:
>
> On Sat, 2 Jan 2016 at 20:39 Eric Snow wrote:
>>
>> First, let me add my thanks for sorting this out!
>>
>> On Jan 2, 2016 11:45, "Brett Cannon" wrote:
>> > Well, "support" as in "allow". We won't be keeping Rietveld around (part
>> > of this mo
On 4 January 2016 at 07:23, Guido van Rossum wrote:
> Ah, the last part there is a nice algorithm. It determines the intended
> merge order when patches are submitted to the queue, then runs tests for
> multiple patches in parallel. So, assuming most patches pass their tests,
> the rate at which p
