Open Stack

see inline below

On Tue, Mar 3, 2015 at 1:48 PM, Shamail Tahir <itzshamail at gmail.com> wrote:

> Hi Sean,
>
> I apologize for the late review...
>
> Can you please elaborate on the "DefCore spot check" in the process
> workflow?  Generally we will probably have capabilities (API introduction)
> and non-capabilities (e.g. fixes, enhancements, etc.) and, therefore, not
> all roadmap items may even qualify to be a capability in DefCore.
> Furthermore, DefCore will only account for API sets with broad adoption and
> new requirements from our output will probably not hit the required
> threshold for DefCore consideration until at least N+1 release cycle (at a
> minimum).
>
> the multi-release roadmap is forward looking. Defcore is a subset of
stable releases. I only wanted to have a placeholder to double check the
roadmap is not out of alignment with defcore.


> I agree that we do need alignment with DefCore but my suggestion would be
> to make it a consumer of the output and an advisor to the input as opposed
> to being in the roadmap process itself.  At the conclusion of each release
> cycle, and prior to starting the next iteration of the roadmap process, we
> should determine if any of our prior roadmap items have reached the "broad
> adoption" threshold (by reviewing collected data from RefStack) and, in
> that case, we should propose for them to be included as DefCore
> capabilities.  Likewise, if we find that certain capabilities are failing
> in a high percentage of deployments then we should be able to get that as
> input into the roadmap (e.g. fix a capability that is already deemed a part
> of the OpenStack brand).
>
i don't think the multi-release roadmap should have any input to defcore,
rather the other way around. What we think the future holds for features
and requirements, does not translate into interoperability and brand
support. OpenStack based products will develop new features making
OpenStack slightly less stable. DefCore will be the parts that are stable
and well used.


>
> Should requirements identified by other teams such as WTE or the API WG be
> called out as a specific item in the workflow so that we can establish what
> the interlock process would look like for this task?  I think item 1a
> currently covers the act of gathering requirements but does it make sense
> to break out requirements collected from users, projects teams, and other
> working groups independently in the process?
>
We should have a group like WTE focused on doing one thing really well,
like gathering user stories. The Product team can focus on doing the
multi-release roadmap really well.


>
> --
> Thanks,
> Shamail Tahir
> Cloud Architect, EMC
> t: @ShamailXD
> tz: Eastern Time
>
> On Tue, Feb 24, 2015 at 9:42 PM, sean roberts <seanroberts66 at gmail.com>
> wrote:
>
>> Now that DefCore is somewhat finished for the next board meeting, I have
>> cycles to focus on the product team.
>>
>> I have to point out that the more I discuss the product team with people
>> both within and without OpenStack, I get more interested in what we can
>> accomplish with this work. Getting down off my soapbox. I share the
>> product
>> team release process that was started at the last face to face meeting.
>>
>> https://docs.google.com/document/d/13JPDDiBGGXf5dtP0u8C-1So2Mjb3yEmGhv_ijVqyEf0/edit?usp=sharing
>> .
>> I have fleshed out some basics with a timeline and responsibilities. I am
>> creating the flowchart as I send this email.
>>
>> Win-the-enterprise, project tagging, incubation-lite, and DefCore will
>> overlap with what we are working on here. I will keep updating this ML as
>> I
>> figure out new information. Do the same as you hear new issues and
>> discussions that can effect our work.
>>
>>
>


-- 

~ sean