Re: [openstack-dev] [Fuel] Review blueprint specs on gerrit

[Mike Scherbakov]

Thanks Dmitry.
I'm walking through one of the proposed designs:
https://review.openstack.org/#/c/96429/,
http://docs-draft.openstack.org/29/96429/4/check/gate-fuel-specs-docs/4590dac/doc/build/html/specs/5.1/access-control-master-node.html

I've noticed a few things in the process which I'd propose for changing
(let's keep this email thread to discuss process itself, and not the
content of the blueprint, which I'll comment in a separate thread):

   1. It is unclear who are mandatory people to review the blueprint.
   For example, we have two +1th in the review, can I merge it now?
   Probably not... I think core developers need to come up with ideas who is
   mandatory to review a design, and put their names into changeset. For any
   feature, we must have QA lead approving it (whether QA lead reviews it
   itself, or puts +1 on behalf of other QA team expert. In the latter case,
   that person has to be in a list of reviewers.)
   2. As we want to have more agile-like model with 2 week iterations, in
   order to get feedback sooner on where we are in the release cycle and keep
   some teams working on stuff which will come up in the release after current
   one, then it makes sense to split the work onto iterations. It is great to
   see that this design reflects multiple stages, which can be considered as
   iterations. I'm not sure that every stage can fit into 2 week cycle, but
   that's what I would love to achieve - when we have a clear scope for every
   iteration, and ability to re-arrange things after every iteration. See
   proposed schedule with iterations at
   https://wiki.openstack.org/wiki/Fuel/5.1_Release_Schedule
   3. While I'm Ok with anyone ++ing review request while it's not yet
   completed, I don't think mandatory core reviewer should do that - and I'd
   suggest that core reviewer should rather -1 it, providing comments and
   marking areas which are not yet complete. In this particular review we have
   few sections empty.

Anyone has an opinion on this?

Thanks,


On Wed, May 28, 2014 at 5:35 AM, Dmitry Pyzhov  wrote:

> Guys,
>
> from now on we should keep all our 5.1 blueprint specs in one place: 
> fuel-specs
> repo . We do it same way as
> nova, so you can use their instruction
>  as a guideline.
>
> Once again. All specifications for 5.1 blueprints need to be moved to
> stackforge. Here is example link:
> https://github.com/stackforge/fuel-specs/blob/master/specs/template.rst.
>
> Jenkins builds every request and adds link to html docs to the comments.
> For example: https://review.openstack.org/#/c/96145/.
>
> I propose to send feedback for this workflow into this mailing thread.
>
> Also, take a look on review guidelines
> .
> It contains some useful information, you know.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Review blueprint specs on gerrit

[Dmitry Pyzhov]

Guys,

from now on we should keep all our 5.1 blueprint specs in one place: fuel-specs
repo . We do it same way as nova,
so you can use their
instructionas a
guideline.

Once again. All specifications for 5.1 blueprints need to be moved to
stackforge. Here is example link:
https://github.com/stackforge/fuel-specs/blob/master/specs/template.rst.

Jenkins builds every request and adds link to html docs to the comments.
For example: https://review.openstack.org/#/c/96145/.

I propose to send feedback for this workflow into this mailing thread.

Also, take a look on review
guidelines.
It contains some useful information, you know.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev