Open Stack

Bringing an old topic on the table.

We might have noticed:

1. Some tripleo-specs take huge amount of time before getting merged
(or even reviewed). We have been asking folks to review them every
week but unfortunately they don't get much attraction (# of core
reviewers versus # of folks actually reviewing specs).
2. Some folks spend a lot of time writing TripleO specs and wait for
feedback before starting some implementation (like proof of concept).

Because TripleO like innovation and also moving fast, I think it's
time to bring the tripleo-specs topic on the table:

1. If you have an idea, don't feel obliged to write a specs. Create a
blueprint on launchpad, announce it on the ML and start writing code
(can be real implementation or just a simple PoC). Feedback will be
given in the classic code review.
2. If you still want to write a spec, please make it readable and
communicate about it. If your spec is 900 lines long and not announced
anywhere, there is an high change that it will never been reviewed.
3. If you still want to write a spec, please don't stop your work
after the specs. Please engage some PoC and prototypes to get feedback
directly on the implementation.

I think these proposals are realistic with the regard of how TripleO
project works now.
Please bring any feedback or question.

Thanks,

On Fri, Jan 29, 2016 at 3:26 AM, Dougal Matthews <dougal at redhat.com> wrote:
>
>
> On 27 January 2016 at 16:21, Derek Higgins <derekh at redhat.com> wrote:
>>
>> Hi All,
>>
>> We briefly discussed feature tracking in this weeks tripleo meeting. I
>> would like to provide a way for downstream consumers (and ourselves) to
>> track new features as they get implemented. The main things that came out of
>> the discussion is that people liked the spec-lite process that the glance
>> team are using.
>>
>> I'm proposing we would start to use the same process, essentially small
>> features that don't warrant a blueprint would instead have a wishlist bug
>> opened against them and get marked with the spec-lite tag. This bug could
>> then be referenced in the commit messages. For larger features blueprints
>> can still be used. I think the process documented by glance[1] is a good
>> model to follow so go read that and see what you think
>>
>> The general feeling at the meeting was +1 to doing this[2] so I hope we
>> can soon start enforcing it, assuming people are still happy to proceed?
>
>
> +1 sounds good.
>
>>
>>
>> thanks,
>> Derek.
>>
>> [1]
>> http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite
>> [2]
>> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.html
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi