[Python-Dev] How do people like the early 3.5 branch?

Nick Coghlan ncoghlan at gmail.com
Tue Jun 23 04:32:44 CEST 2015


On 17 June 2015 at 09:26, Larry Hastings <larry at hastings.org> wrote:
>
>
> A quick look through the checkin logs suggests that there's literally
> nothing happening in 3.6 right now.  All the checkins are merges.
>
> Is anyone expecting to do work in 3.6 soon?  Or did the early branch just
> create a bunch of make-work for everybody?

A bit of a belated reply here, but my main observations are:

1. I still like the general idea
2. In the absence of ongoing integration testing against major third
party projects, I think the second beta might be a better branch point
than the first one

PEPs 489 (extension module loading) and 492 (async/await) are my main
reason for thinking that:

* For PEP 489, which represented a major refactoring of an existing
system, the first beta revealed a critical gap in the regression test
suite (hence the brown-paper-bag early beta 2 release)
* For PEP 492, which represented the introduction of a major new
system, the first beta revealed some non-trivial interoperability
issues that hadn't been considered in the original design

On the other hand, that qualifier on the second observation is a
fairly important one :)

I've been thinking more about what a gated "third party continuous
integration" repo might look like, and I'm beginning to think if we
structured it appropriately, the idea might be simpler than I
previously thought. The essential components seem to be:

1. Listening to and/or regularly polling the BuildBot master to check
for versions that pass the regression test suite on the stable
Buildbot fleet (I'm not sure what BuildBot's notification options are,
but cron is always available as a fallback option)
2. Pull those revisions into a local repo that's accessible read-only
over the web
3. Tag the specific revision that passed (this keeps track of which
revisions are known to pass the regression test suite, vs those that
only came in as dependencies of passing revisions)
4. Ideally, publish a notification via an asynchronous notification
system (e.g. fedmsg) that other CI systems can consume as a trigger
for their own testing

It's not at the top of my todo list right now, but if nobody beats me
to it I'll try to see what I can set up in Kallithea some time in the
next few months :)

Regards,
Nick.

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


More information about the Python-Dev mailing list