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

Mike Scherbakov mscherbakov at mirantis.com
Tue Jun 3 06:28:15 UTC 2014


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 <dpyzhov at mirantis.com> wrote:

> Guys,
>
> from now on we should keep all our 5.1 blueprint specs in one place: fuel-specs
> repo <https://github.com/stackforge/fuel-specs>. We do it same way as
> nova, so you can use their instruction
> <https://wiki.openstack.org/wiki/Blueprints#Nova> 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
> <https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria>.
> It contains some useful information, you know.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140602/dbfb9a2f/attachment.html>


More information about the OpenStack-dev mailing list