[openstack-dev] [TripleO] spec-lite process for tripleo
shardy at redhat.com
Wed Mar 29 21:42:07 UTC 2017
On Tue, Mar 28, 2017 at 12:09:43PM -0400, Emilien Macchi wrote:
> 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.
+1 I for one have been burnt more than once spending significant time
on a spec only to find our collective understanding changes after actual
For things related to interfaces a spec can be helpful, but I think it's
often faster to raise a blueprint with relatively few details and work on a
prototype that clarifies the direction, particularly if such code patches
can be generated fairly quickly.
> 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.
I agree - I think a common mistake is to get bogged down in implementation
detail when writing (and reviewing) a spec, so I definitely favor a
clearly expressed summary of the problem, an overview of the proposed
direction (including any major interface changes), and clarification of any
user/dev visible impact. None of this requires much focus at all on the
details of the implementation IMO.
Thanks for raising this Emilien, hopefully this will help us move a little
faster in future!
More information about the OpenStack-dev