Re: [openstack-dev] [tripleo] Ocata specs

[Steven Hardy]

On Tue, Nov 01, 2016 at 05:46:48PM -0400, Zane Bitter wrote:
> On 01/11/16 15:13, James Slagle wrote:
> > On Tue, Nov 1, 2016 at 7:21 PM, Emilien Macchi  wrote:
> > > Hi,
> > > 
> > > TripleO (like some other projects in OpenStack) have not always done
> > > good job in merging specs on time during a cycle.
> > > I would like to make progress on this topic and for that, I propose we
> > > set a deadline to get a spec approved for Ocata release.
> > > This deadline would be Ocata-1 which is week of November 14th.
> > > 
> > > So if you have a specs under review, please make sure it's well
> > > communicated to our team (IRC, mailing-list, etc); comments are
> > > addressed.
> > > 
> > > Also, I would ask our team to spend some time to review them when they
> > > have time. Here is the link:
> > > https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open
> > 
> > Given that we don't always require specs, should we make the same
> > deadline for blueprints to get approved for Ocata as well?
> > 
> > In fact, we haven't even always required blueprints for all features.
> > In order to avoid any surprise FFE's towards the end of the cycle, I
> > think it might be wise to start doing so. The overhead of creating a
> > blueprint is very small, and it actually works to the implementer's
> > advantage as it helps to focus review attention at the various
> > milestones.
> > 
> > So, we could say:
> > - All features require a blueprint
> > - They may require a spec if we need to reach concensus about the feature 
> > first
> > - All Blueprints and Specs for Ocata not approved by November 14th
> > will be deferred to Pike.
> > 
> > Given we reviewed all the blueprints at the summit, and discussed all
> > the features we plan to implement for Ocata, I think it would be
> > reasonable to go with the above. However, 'm interested in any
> > feedback or if anyone feels that requiring a blueprint for features is
> > undesirable.
> 
> The blueprint interface in Launchpad is kind of horrible for our purposes
> (too many irrelevant fields to fill out). For features that aren't
> big/controversial enough to require a spec, some projects have adopted a
> 'spec-lite' process. Basically you raise a *bug* in Launchpad, give it
> 'Wishlist' priority and tag it with 'spec-lite'.

I think either approach is fine and IIRC we did previously discuss the
spec-lite process and agree it was acceptable for tracking smaller
features for TripleO.

The point is we absolutely need some way to track stuff that isn't yet
landed - and I think folks probably don't care much re (Bug|Blueprint)
provided it's correctly targetted.

We had a very rough time at the end of Newton because $many folks showed up
late with features we didn't know about and/or weren't correctly tracked,
so I think a feature proposal freeze is reasonable.  Given the number of
BPs targetted at Ocata is already prety high I think Nov 14th probably
justifiable but it is on the more conservative side relative to other
projects[2].

Regarding the specs process - tbh I feel like that hasn't been working well
for a while (for all the same reasons John referenced in [1]).

So I've been leaning towards not requiring (or writing) specs in the
majority of cases, instead often we've just linked an etherpad with notes
or had a ML discussion to gain consensus on direction. (This seems pretty
similar to the wiki based approach adopted by the swift team).

Thanks,

Steve

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/094026.html
[2] https://releases.openstack.org/ocata/schedule.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Ocata specs

[John Dickinson]

On 1 Nov 2016, at 14:46, Zane Bitter wrote:

> On 01/11/16 15:13, James Slagle wrote:
>> On Tue, Nov 1, 2016 at 7:21 PM, Emilien Macchi  wrote:
>>> Hi,
>>>
>>> TripleO (like some other projects in OpenStack) have not always done
>>> good job in merging specs on time during a cycle.
>>> I would like to make progress on this topic and for that, I propose we
>>> set a deadline to get a spec approved for Ocata release.
>>> This deadline would be Ocata-1 which is week of November 14th.
>>>
>>> So if you have a specs under review, please make sure it's well
>>> communicated to our team (IRC, mailing-list, etc); comments are
>>> addressed.
>>>
>>> Also, I would ask our team to spend some time to review them when they
>>> have time. Here is the link:
>>> https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open
>>
>> Given that we don't always require specs, should we make the same
>> deadline for blueprints to get approved for Ocata as well?
>>
>> In fact, we haven't even always required blueprints for all features.
>> In order to avoid any surprise FFE's towards the end of the cycle, I
>> think it might be wise to start doing so. The overhead of creating a
>> blueprint is very small, and it actually works to the implementer's
>> advantage as it helps to focus review attention at the various
>> milestones.
>>
>> So, we could say:
>> - All features require a blueprint
>> - They may require a spec if we need to reach concensus about the feature 
>> first
>> - All Blueprints and Specs for Ocata not approved by November 14th
>> will be deferred to Pike.
>>
>> Given we reviewed all the blueprints at the summit, and discussed all
>> the features we plan to implement for Ocata, I think it would be
>> reasonable to go with the above. However, 'm interested in any
>> feedback or if anyone feels that requiring a blueprint for features is
>> undesirable.
>
> The blueprint interface in Launchpad is kind of horrible for our purposes 
> (too many irrelevant fields to fill out). For features that aren't 
> big/controversial enough to require a spec, some projects have adopted a 
> 'spec-lite' process. Basically you raise a *bug* in Launchpad, give it 
> 'Wishlist' priority and tag it with 'spec-lite'.
>
> Sometimes a blueprint is the right answer (e.g. if it's high-priority and you 
> want to track it), but it's good to have the option.
>

Back in the Newton summit (in Austin), the Swift team spent quite a while 
discussing specs and blueprints and other ideas we'd used to organize what's 
being worked on. We concluded that specs weren't working (for some of the same 
reasons mentioned in this thread), so we decided to try something new. Our 
current process is described in the email I sent out last May: 
http://lists.openstack.org/pipermail/openstack-dev/2016-May/094026.html. So 
far, it's working pretty well.

--John




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Ocata specs

[Zane Bitter]

On 01/11/16 15:13, James Slagle wrote:

On Tue, Nov 1, 2016 at 7:21 PM, Emilien Macchi  wrote:

Hi,

TripleO (like some other projects in OpenStack) have not always done
good job in merging specs on time during a cycle.
I would like to make progress on this topic and for that, I propose we
set a deadline to get a spec approved for Ocata release.
This deadline would be Ocata-1 which is week of November 14th.

So if you have a specs under review, please make sure it's well
communicated to our team (IRC, mailing-list, etc); comments are
addressed.

Also, I would ask our team to spend some time to review them when they
have time. Here is the link:
https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open


Given that we don't always require specs, should we make the same
deadline for blueprints to get approved for Ocata as well?

In fact, we haven't even always required blueprints for all features.
In order to avoid any surprise FFE's towards the end of the cycle, I
think it might be wise to start doing so. The overhead of creating a
blueprint is very small, and it actually works to the implementer's
advantage as it helps to focus review attention at the various
milestones.

So, we could say:
- All features require a blueprint
- They may require a spec if we need to reach concensus about the feature first
- All Blueprints and Specs for Ocata not approved by November 14th
will be deferred to Pike.

Given we reviewed all the blueprints at the summit, and discussed all
the features we plan to implement for Ocata, I think it would be
reasonable to go with the above. However, 'm interested in any
feedback or if anyone feels that requiring a blueprint for features is
undesirable.


The blueprint interface in Launchpad is kind of horrible for our 
purposes (too many irrelevant fields to fill out). For features that 
aren't big/controversial enough to require a spec, some projects have 
adopted a 'spec-lite' process. Basically you raise a *bug* in Launchpad, 
give it 'Wishlist' priority and tag it with 'spec-lite'.


Sometimes a blueprint is the right answer (e.g. if it's high-priority 
and you want to track it), but it's good to have the option.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Ocata specs

[James Slagle]

On Tue, Nov 1, 2016 at 7:21 PM, Emilien Macchi  wrote:
> Hi,
>
> TripleO (like some other projects in OpenStack) have not always done
> good job in merging specs on time during a cycle.
> I would like to make progress on this topic and for that, I propose we
> set a deadline to get a spec approved for Ocata release.
> This deadline would be Ocata-1 which is week of November 14th.
>
> So if you have a specs under review, please make sure it's well
> communicated to our team (IRC, mailing-list, etc); comments are
> addressed.
>
> Also, I would ask our team to spend some time to review them when they
> have time. Here is the link:
> https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open

Given that we don't always require specs, should we make the same
deadline for blueprints to get approved for Ocata as well?

In fact, we haven't even always required blueprints for all features.
In order to avoid any surprise FFE's towards the end of the cycle, I
think it might be wise to start doing so. The overhead of creating a
blueprint is very small, and it actually works to the implementer's
advantage as it helps to focus review attention at the various
milestones.

So, we could say:
- All features require a blueprint
- They may require a spec if we need to reach concensus about the feature first
- All Blueprints and Specs for Ocata not approved by November 14th
will be deferred to Pike.

Given we reviewed all the blueprints at the summit, and discussed all
the features we plan to implement for Ocata, I think it would be
reasonable to go with the above. However, 'm interested in any
feedback or if anyone feels that requiring a blueprint for features is
undesirable.

-- 
-- James Slagle
--

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Ocata specs

[Emilien Macchi]

Hi,

TripleO (like some other projects in OpenStack) have not always done
good job in merging specs on time during a cycle.
I would like to make progress on this topic and for that, I propose we
set a deadline to get a spec approved for Ocata release.
This deadline would be Ocata-1 which is week of November 14th.

So if you have a specs under review, please make sure it's well
communicated to our team (IRC, mailing-list, etc); comments are
addressed.

Also, I would ask our team to spend some time to review them when they
have time. Here is the link:
https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open

Thanks a lot,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev