On 4 July 2016 at 10:34, Chris Krycho wrote:
> The bots Mozilla runs around both Rust and Servo should make a lot of this
> much lower overhead if they can be repurposed (as I believe several other
> communities have already done).
>
> Homu, the build manager tool, runs CI (including buildbots, Tr
Once the GH migration occurs I think we will take a look at Homu (it's been
brought up previously).
On Sun, Jul 3, 2016, 17:35 Chris Krycho wrote:
> The bots Mozilla runs around both Rust and Servo should make a lot of this
> much lower overhead if they can be repurposed (as I believe several ot
OK, I see this point now. Still looking for time to review the rest of your
PEP!
--Guido (mobile)
On Jul 3, 2016 3:29 PM, "Martin Teichmann" wrote:
> Hi Guido,
>
> sorry I missed your post...
>
> >> One of the big issues that makes library authors reluctant to use
> >> metaclasses
> >> (even whe
The bots Mozilla runs around both Rust and Servo should make a lot of this much
lower overhead if they can be repurposed (as I believe several other
communities have already done).
Homu, the build manager tool, runs CI (including buildbots, Travis, etc.), is
integrated with GitHub PRs so mainta
On 4 July 2016 at 06:22, Brett Cannon wrote:
> [forking the conversation since the subject has shifted]
>
> On Sun, 3 Jul 2016 at 09:50 Steve Dower wrote:
>>
>> Many of our users prefer stability (the sort who plan operating system
>> updates years in advance), but generally I'm in favour of more
On 4 July 2016 at 00:39, Guido van Rossum wrote:
> Another thought recently occurred to me. Do releases really have to be
> such big productions? A recent ACM article by Tom Limoncelli[1]
> reminded me that we're doing releases the old-fashioned way --
> infrequently, and with lots of manual labor
On Sat, Jul 2, 2016 at 10:50 AM, Martin Teichmann
wrote:
> Hi list,
>
> so this is the next round for PEP 487. During the last round, most of
> the comments were in the direction that a two step approach for
> integrating into Python, first in pure Python, later in C, was not a
> great idea and ev
On 03Jul2016 1556, Terry Reedy wrote:
On 7/3/2016 4:22 PM, Brett Cannon wrote:
So if we really wanted to go this route of breaking out the stdlib, I
think we have two options. One is to have the cpython repo represent the
CPython interpreter and then have a separate stdlib repo. The other
optio
On 7/3/2016 4:22 PM, Brett Cannon wrote:
So if we really wanted to go this route of breaking out the stdlib, I
think we have two options. One is to have the cpython repo represent the
CPython interpreter and then have a separate stdlib repo. The other
option is to still have cpython represent th
Hi Guido,
sorry I missed your post...
>> One of the big issues that makes library authors reluctant to use
>> metaclasses
>> (even when they would be appropriate) is the risk of metaclass conflicts.
>
> Really? I've written and reviewed a lot of metaclasses and this has never
> worried me. The pr
My thinking on this issue was that some/most packages from the stdlib would
move into site-packages. Certainly I'd expect asyncio to be in this category,
and probably typing. Even going as far as email and urllib would potentially be
beneficial (to those packages, is my thinking).
Obviously not
Hi Nick,
thanks for the nice review!
> I think making __init_subclass__ implicitly a class method is still
> the right thing to do if this proposal gets accepted, we'll just want
> to see if we can do something to tidy up that aspect of the
> documentation at the same time.
I could write some do
I actually thought about Rust when thinking about 3 month releases (I know
they release faster though). What i would want to know is whether the RMs
for Rust are employed by Mozilla and thus have work time to do but it vs
Python RMs & friends who vary ob whether they get work time.
On Sun, Jul 3,
On Sun, Jul 3, 2016, 14:22 Paul Moore wrote:
> On 3 July 2016 at 22:04, Brett Cannon wrote:
> > This last bit is what I would advocate if we broke the stdlib out unless
> an
> > emergency patch release is warranted for a specific module (e.g. like
> > asyncio that started this discussion). Obvio
On Jul 3, 2016 1:45 PM, "Paul Moore" wrote:
>
[...]
> Furthermore, pip/setuptools are just getting to the point of allowing
> for dependencies conditional on Python version. If independent stdlib
> releases were introduced, we'd need to implement dependencies based on
> stdlib version as well - co
On 3 July 2016 at 22:04, Brett Cannon wrote:
> This last bit is what I would advocate if we broke the stdlib out unless an
> emergency patch release is warranted for a specific module (e.g. like
> asyncio that started this discussion). Obviously backporting is its own
> thing.
It's also worth not
On Sun, Jul 3, 2016, 13:43 Paul Moore wrote:
> On 3 July 2016 at 21:22, Brett Cannon wrote:
> > Topic 2
> > ===
> > Independent releases of the stdlib could be done, although if we break
> the
> > stdlib up into individual repos then it shifts the conversation as
> > individual modules could
As an observer and user—
It may be worth asking the Rust team what the main pain points are in
coordinating and managing their releases.
Some context for those unfamiliar: Rust uses a Chrome- or Firefox-like release
train approach, with stable and beta releases every six weeks. Each release
cy
On 3 July 2016 at 21:22, Brett Cannon wrote:
> Topic 2
> ===
> Independent releases of the stdlib could be done, although if we break the
> stdlib up into individual repos then it shifts the conversation as
> individual modules could simply do their own releases independent of the big
> stdlib
[forking the conversation since the subject has shifted]
On Sun, 3 Jul 2016 at 09:50 Steve Dower wrote:
> Many of our users prefer stability (the sort who plan operating system
> updates years in advance), but generally I'm in favour of more frequent
> releases.
>
So there's our 18 month cadenc
Many of our users prefer stability (the sort who plan operating system updates
years in advance), but generally I'm in favor of more frequent releases. It
will likely require more complex branching though, presumably based on the LTS
model everyone else uses.
One thing we've discussed before is
Another thought recently occurred to me. Do releases really have to be
such big productions? A recent ACM article by Tom Limoncelli[1]
reminded me that we're doing releases the old-fashioned way --
infrequently, and with lots of manual labor. Maybe we could
(eventually) try to strive for a lighter-
On 2 July 2016 at 10:50, Martin Teichmann wrote:
> Hi list,
>
> so this is the next round for PEP 487. During the last round, most of
> the comments were in the direction that a two step approach for
> integrating into Python, first in pure Python, later in C, was not a
> great idea and everything
Hi Nick,
First, thanks a lot for your detailed answer, it was very instructive to me.
My answers below.
2016-07-03 6:09 GMT+02:00 Nick Coghlan :
> On 2 July 2016 at 16:17, Ludovic Gasc wrote:
> > Hi everybody,
> >
> > I fully understand that AsyncIO is a drop in the ocean of CPython, you're
> >
24 matches
Mail list logo
