Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140701/2e801783/attachment.html>