Open Stack

Hi,

I really like what Mike proposed. It will help us to keep milestone clean
and accurate.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser


On Wed, Aug 6, 2014 at 11:26 AM, Mike Scherbakov <mscherbakov at mirantis.com>
wrote:

> As we are before next milestone, let's get back to this excellent (in my
> opinion) proposal from Dmitry. Current situation is the following: there
> are 121 blueprints targeted for 6.0. Most of them miss a header with
> QA/reviewers/developers information, basically those are incomplete
> blueprints initially. Many of them have such a cryptic description, that it
> is impossible to understand the main idea.
>
> My suggestion for immediate actions, strictly following original email
> from Dmitry, is the following:
>
>    1. Move all 6.0 blueprints to "next" milestone and clear up assignee
>    (so others know that it's not taken by anyone)
>    2. Start adding blueprints to 6.0 only if they satisfy criteria of
>    clarity and filled information:
>
>    > Each blueprint in a milestone should contain information about
>    feature lead, design reviewers, developers, qa, acceptance criteria.
>
> Once we know who is going to work on the blueprint, who commit for it,
> then the blueprint can be added. We know that behind every engineer is the
> company, so feature lead should negotiate first with the management of the
> company to get allocated for the particular feature. Same applies to a team
> of developers working on a feature.
>
> Fuelers, any objections?
>
>
> On Fri, Jul 4, 2014 at 8:26 PM, Dmitry Pyzhov <dpyzhov at mirantis.com>
> wrote:
>
>> Do not cheat. If we need to add functionality after feature freeze, then
>> let add functionality after feature freeze. No reason for additional
>> obfuscation. It will make our workflow for blueprints harder, but it will
>> help us. We will see what we are really going to do and plan our work
>> better.
>>
>> Also we can create a beta iso with all features in 'beta available'
>> status. It will help to make sure that small improvements are not break
>> anything and can be merged without any fear.
>>
>>
>> On Tue, Jul 1, 2014 at 3:00 PM, Vladimir Kuklin <vkuklin at mirantis.com>
>> wrote:
>>
>>> I have some objections. We are trying to follow a strict development
>>> workflow with feature freeze stage. In this case we will have to miss small
>>> enhancements that can emerge after FF date and can bring essential benefits
>>> along with small risks of breaking anything (e.g. changing some config
>>> options for galera or other stuff). We maintained such small changes as
>>> bugs because of this FF rule. As our project is growing, these last minute
>>> calls for small changes are going to be more and more probable. My
>>> suggestion is that we somehow modify our workflow allowing these small
>>> features to get through FF stage or we are risking to have an endless queue
>>> of enhancements that users will never see in the release.
>>>
>>>
>>> On Thu, Jun 26, 2014 at 8:07 PM, Matthew Mosesohn <
>>> mmosesohn at mirantis.com> wrote:
>>>
>>>> +1
>>>>
>>>> Keeping features separate as blueprints (even tiny ones with no spec)
>>>> really will let us focus on the volume of real bugs.
>>>>
>>>> On Tue, Jun 24, 2014 at 5:14 PM, Dmitry Pyzhov <dpyzhov at mirantis.com>
>>>> wrote:
>>>> > Guys,
>>>> >
>>>> > We have a beautiful contribution guide:
>>>> > https://wiki.openstack.org/wiki/Fuel/How_to_contribute
>>>> >
>>>> > However, I would like to address several issues in our blueprints/bugs
>>>> > processes. Let's discuss and vote on my proposals.
>>>> >
>>>> > 1) First of all, the bug counter is an excellent metric for quality.
>>>> So
>>>> > let's use it only for bugs and track all feature requirement as
>>>> blueprints.
>>>> > Here is what it means:
>>>> >
>>>> > 1a) If a bug report does not describe a user’s pain, a blueprint
>>>> should be
>>>> > created and bug should be closed as invalid
>>>> > 1b) If a bug report does relate to a user’s pain, a blueprint should
>>>> be
>>>> > created and linked to the bug
>>>> > 1c) We have an excellent reporting tool, but it needs more metrics:
>>>> count of
>>>> > critical/high bugs, count of bugs assigned to each team. It will
>>>> require
>>>> > support of team members lists, but it seems that we really need it.
>>>> >
>>>> >
>>>> > 2) We have a huge amount of blueprints and it is hard to work with
>>>> this
>>>> > list. A good blueprint needs a fixed scope, spec review and acceptance
>>>> > criteria. It is obvious for me that we can not work on blueprints
>>>> that do
>>>> > not meet these requirements. Therefore:
>>>> >
>>>> > 2a) Let's copy the nova future series and create a fake milestone
>>>> 'next' as
>>>> > nova does. All unclear blueprints should be moved there. We will pick
>>>> > blueprints from there, add spec and other info and target them to a
>>>> > milestone when we are really ready to work on a particular blueprint.
>>>> Our
>>>> > release page will look much more close to reality and much more
>>>> readable in
>>>> > this case.
>>>> > 2b) Each blueprint in a milestone should contain information about
>>>> feature
>>>> > lead, design reviewers, developers, qa, acceptance criteria. Spec is
>>>> > optional for trivial blueprints. If a spec is created, the designated
>>>> > reviewer(s) should put (+1) right into the blueprint description.
>>>> > 2c) Every blueprint spec should be updated before feature freeze with
>>>> the
>>>> > latest actual information. Actually, I'm not sure if we care about
>>>> spec
>>>> > after feature development, but it seems to be logical to have correct
>>>> > information in specs.
>>>> > 2d) We should avoid creating interconnected blueprints wherever
>>>> possible. Of
>>>> > course we can have several blueprints for one big feature if it can
>>>> be split
>>>> > into several shippable blocks for several releases or for several
>>>> teams. In
>>>> > most cases, small parts should be tracked as work items of a single
>>>> > blueprint.
>>>> >
>>>> >
>>>> > 3) Every review request without a bug or blueprint link should be
>>>> checked
>>>> > carefully.
>>>> >
>>>> > 3a) It should contain a complete description of what is being done
>>>> and why
>>>> > 3b) It should not require backports to stable branches (backports are
>>>> > bugfixes only)
>>>> > 3c) It should not require changes to documentation or be mentioned in
>>>> > release notes
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > OpenStack-dev mailing list
>>>> > OpenStack-dev at lists.openstack.org
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 45bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com <http://www.mirantis.ru/>
>>> www.mirantis.ru
>>> vkuklin at mirantis.com
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/8b1e0913/attachment.html>