I plan to start prioritising the specs that are in the review queue,
not just post approve.
We should fast track those that have already been approved, and
particularly when code is ready to go.
My original plan was to propose a git move from juno to kilo, so its
easy to see its just a
On 27 September 2014 00:31, Joe Gordon joe.gord...@gmail.com wrote:
On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt j...@johngarbutt.com wrote:
On 25 September 2014 14:10, Daniel P. Berrange berra...@redhat.com
wrote:
The proposal is to keep kilo-1, kilo-2 much the same as juno. Except,
we
Hi,
Is the process documented anywhere? That is, if say for example I had a
spec approved in J and its code did not land, how do we go about kicking
the tires for K on that spec.
Thanks
Gary
On 9/29/14, 1:07 PM, John Garbutt j...@johngarbutt.com wrote:
On 27 September 2014 00:31, Joe Gordon
On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton gkot...@vmware.com wrote:
Hi,
Is the process documented anywhere? That is, if say for example I had a
spec approved in J and its code did not land, how do we go about kicking
the tires for K on that spec.
Specs will need be re-submitted once we
On Mon, 29 Sep 2014 13:32:57 -0700
Joe Gordon joe.gord...@gmail.com wrote:
On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton gkot...@vmware.com
wrote:
Hi,
Is the process documented anywhere? That is, if say for example I
had a spec approved in J and its code did not land, how do we go
On Mon, Sep 29, 2014 at 4:46 PM, Christopher Yeoh cbky...@gmail.com wrote:
On Mon, 29 Sep 2014 13:32:57 -0700
Joe Gordon joe.gord...@gmail.com wrote:
On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton gkot...@vmware.com
wrote:
Hi,
Is the process documented anywhere? That is, if say for
It seems like a no-brainer to me to prioritise people who have been patient
with us.
How about we tag these re-proposals with a commit message tag people can
search for when they review? Perhaps Previously-approved: Juno?
Michael
On Tue, Sep 30, 2014 at 11:06 AM, Joe Gordon
On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt j...@johngarbutt.com wrote:
On 25 September 2014 14:10, Daniel P. Berrange berra...@redhat.com
wrote:
The proposal is to keep kilo-1, kilo-2 much the same as juno. Except,
we work harder on getting people to buy into the priorities that are
Hi,
A big thank you to jogo who has done a great job writing up plans for
kilo blueprints and specs:
1) Allow more code that doesn't need a blueprint and spec:
https://review.openstack.org/#/c/116699/3
Specs are a heavy process, so hopefully this will strike a better
balance between process and
On Thu, Sep 25, 2014 at 11:27:09AM +0100, John Garbutt wrote:
Hi,
A big thank you to jogo who has done a great job writing up plans for
kilo blueprints and specs:
1) Allow more code that doesn't need a blueprint and spec:
https://review.openstack.org/#/c/116699/3
Specs are a heavy
On 25 September 2014 11:44, Daniel P. Berrange berra...@redhat.com wrote:
To use the runway system, we need to have a frequently updated list
of blueprints which are a priority to review / merge. Once we have
such a list, IMHO, adding the fixed runway slots around that does
not do anything
On Thu, Sep 25, 2014 at 01:52:48PM +0100, John Garbutt wrote:
On 25 September 2014 11:44, Daniel P. Berrange berra...@redhat.com wrote:
To use the runway system, we need to have a frequently updated list
of blueprints which are a priority to review / merge. Once we have
such a list, IMHO,
On 25 September 2014 14:10, Daniel P. Berrange berra...@redhat.com wrote:
The proposal is to keep kilo-1, kilo-2 much the same as juno. Except,
we work harder on getting people to buy into the priorities that are
set, and actively provoke more debate on their correctness, and we
reduce the bar
13 matches
Mail list logo
