On Tue, May 12, 2015 at 8:04 PM, Larry Hastings wrote:
> What do you think? My votes are as follows:
>
> Workflow 0: -0.5
> Workflow 1: +1
> Workflow 2: +0.5
>
>
> Please cast your votes,
Workflow 0: -0
Workflow 1: +1
Workflow 2: +0
--Berker
___
pytho
On 05/12/2015 11:18 AM, Jesus Cea wrote:
Larry, could you comment about the impact in the buildbots?. I suppose
option #1 could allows us to test both 3.5 and 3.6 changes. Would you
confirm this?
Workflow #1 gets us automatic buildbot testing for the 3.5 branch (betas
and 3.5.1) and trunk (3.6
On 05/12/2015 05:11 PM, Dirkjan Ochtman wrote:
Couldn't you just keep this as a branch that you then keep rebasing
(without unlinking the original branch)? It doesn't seem like
something that needs a one-off script, to me.
Probably. It's water under the bridge now--that all happened last
Febr
On 13 May 2015 03:47, "Brett Cannon" wrote:
>
>
>
> On Tue, May 12, 2015 at 1:05 PM Larry Hastings wrote:
>>
>> [SNIP]
>>
>>
>> What do you think? My votes are as follows:
>>>
>>> Workflow 0: -0.5
>>> Workflow 1: +1
>>> Workflow 2: +0.5
>>
>>
>> Please cast your votes,
>
>
> Workflow 0: -0
> Wor
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings wrote:
> BTW, this workload was exacerbated by my foolish desire to keep the revision
> DAG nice and clean. So I was actually starting over from scratch and
> redoing all the cherry-picking every couple of days, just so I could get all
> the cherry-
On 05/12/2015 11:21 AM, Ned Deily wrote:
I like the idea of experimentally trying the push workflow but, if we are all
doing our jobs right, there should be very few changes going in after rc1 so
most committers won't need to push anything to the 3.5.0rc repo and, if for
some reason they aren'
On May 12, 2015, at 10:38 AM, Larry Hastings wrote:
>It doesn't. Workflows 0 and 2 mean no public development of 3.6 until after
>3.5.0 final ships, as per tradition.
I still think it's a good idea to focus primarily on 3.5 while it's in the
beta/rc period, but if you want to allow for landings
Larry, could you comment about the impact in the buildbots?. I suppose
option #1 could allows us to test both 3.5 and 3.6 changes. Would you
confirm this?
My votes:
Workflow #0: -0
Workflow #1: +1
Workflow #2: +0
Would be great if we could host the branch for 3.5 ourselves instead of
using BitBu
On May 12, 2015, at 10:38, Larry Hastings wrote:
> On 05/12/2015 10:23 AM, Ned Deily wrote:
>> One possible issue with Workflow 1 is that there would need to be an
>> additional set of buildbots (for 3.5, in addition to the existing 3.x (AKA
>> "trunk"), 3.4, and 2.7 ones) for the period from be
Larry,
On 2015-05-12 1:04 PM, Larry Hastings wrote:
Workflow 1
==
When I ship beta 1, we create the 3.5 branch. trunk become 3.6.
When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a
publically visible repo /on bitbucket/ for 3.5.0, and we use bitbucket
"pull requests" for
On Tue, May 12, 2015 at 1:05 PM Larry Hastings wrote:
> [SNIP]
>
> What do you think? My votes are as follows:
>
> Workflow 0: -0.5
> Workflow 1: +1
> Workflow 2: +0.5
>
>
> Please cast your votes,
>
Workflow 0: -0
Workflow 1: +1
Workflow 2: +0
___
p
On 05/12/2015 10:23 AM, Ned Deily wrote:
One possible issue with Workflow 1 is that there would need to be an additional set of
buildbots (for 3.5, in addition to the existing 3.x (AKA "trunk"), 3.4, and 2.7
ones) for the period from beta 1 until at least 3.5.0 is released and, ideally, until 3
On May 12, 2015, at 10:04, Larry Hastings wrote:
> Workflow 1
> ==
>
> When I ship beta 1, we create the 3.5 branch. trunk become 3.6.
>
> When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically
> visible repo on bitbucket for 3.5.0, and we use bitbucket "pull request
Python 3.5 beta 1 is coming up soon. After beta is rc; after rc is
3.5.0 final. During the beta and rc periods the Python developer
workflow changes a little--what sorts of checkins are permissible, and
how to get something accepted and merged generally becomes more complicated.
I was the
14 matches
Mail list logo
