On 05.07.2016 21:11, Brett Cannon wrote:
> On Tue, 5 Jul 2016 at 10:45 Barry Warsaw wrote:
>
>> On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
>>
>>> While we liked the "consistent calendar cadence that is some multiple
>>> of 6 months" idea, several of us thought 12 months was way too short
>
On 6 July 2016 at 11:09, Barry Warsaw wrote:
> On Jul 06, 2016, at 10:55 AM, Nick Coghlan wrote:
>
>>However, if we did decide we wanted to take minimising "time to
>>redistribution" for at least Ubuntu & Fedora into account, then the
>>two main points to consider would be:
>>
>>- starting the ups
On 6 July 2016 at 03:47, Barry Warsaw wrote:
> On Jul 05, 2016, at 10:38 AM, Steve Dower wrote:
>
>>My hope is that it would be essentially a "pip freeze"/"pip install -r ..."
>>(or equivalent with whatever tool is used/created for managing the
>>stdlib). Perhaps using VCS URIs rather than version
On Jul 06, 2016, at 10:55 AM, Nick Coghlan wrote:
>However, if we did decide we wanted to take minimising "time to
>redistribution" for at least Ubuntu & Fedora into account, then the
>two main points to consider would be:
>
>- starting the upstream beta phase before the first downstream alpha fre
On Jul 06, 2016, at 10:02 AM, Nick Coghlan wrote:
>On 6 July 2016 at 03:44, Barry Warsaw wrote:
>
>> Projecting ahead, it probably means 3.7 in mid-2018, which is after the
>> Ubuntu 18.04 LTS release, so we'll only do one major transition before the
>> next LTS. From my perspective, that feels
On 6 July 2016 at 05:11, Brett Cannon wrote:
> Sticking w/ 18 months is also fine, but then I would like to discuss
> choosing what months we try to release to get into a date-based release
> cadence so we know that every e.g. December and June are when releases
> typically happen thanks to our 6
On 6 July 2016 at 03:44, Barry Warsaw wrote:
> For example, 3.6 final will come out in December 2016, so it'll be past our
> current 16.10 Ubuntu release. We've pretty much decided to carry Python 3.5
> through until 17.04, and that'll give us a good year to make 18.04 LTS have a
> solid Python 3
On Tue, 5 Jul 2016 at 10:45 Barry Warsaw wrote:
> On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
>
> >While we liked the "consistent calendar cadence that is some multiple
> >of 6 months" idea, several of us thought 12 months was way too short
> >as it makes for too many entries in third party
On 07/05/2016 10:44 AM, Barry Warsaw wrote:
On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
While we liked the "consistent calendar cadence that is some multiple
of 6 months" idea, several of us thought 12 months was way too short
as it makes for too many entries in third party support matri
On Jul 05, 2016, at 10:38 AM, Steve Dower wrote:
>My hope is that it would be essentially a "pip freeze"/"pip install -r ..."
>(or equivalent with whatever tool is used/created for managing the
>stdlib). Perhaps using VCS URIs rather than version numbers?
>
>That is, the test run would dump a list
On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:
>While we liked the "consistent calendar cadence that is some multiple
>of 6 months" idea, several of us thought 12 months was way too short
>as it makes for too many entries in third party support matrices.
18 months for a major release cadence s
On 05Jul2016 1028, Barry Warsaw wrote:
On Jul 03, 2016, at 04:21 PM, Steve Dower wrote:
A rough count of how I'd break up the current 3.5 Lib folder (which I
happened to have handy) suggests no more than 50 repos.
A concern with a highly split stdlib is local testing. I'm not worried about
p
On Jul 03, 2016, at 04:21 PM, Steve Dower wrote:
>A rough count of how I'd break up the current 3.5 Lib folder (which I
>happened to have handy) suggests no more than 50 repos.
A concern with a highly split stdlib is local testing. I'm not worried about
pull request testing, or after-the-fact bu
On 07/03/2016 09:39 AM, Guido van Rossum wrote:
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
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 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
;Paul Moore"
Sent: 7/3/2016 14:23
To: "Brett Cannon"
Cc: "Guido van Rossum" ; "Nick Coghlan" ;
"Python-Dev" ; "Steve Dower"
Subject: Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3
release)
On 3 July 2016 at 22:04, Brett Ca
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
26 matches
Mail list logo
