Open Stack

>> The spec doesn't have to be perfect, but it needs to be merged prior to
code describing it.

Currently the spec has to be perfect and detailed enough, otherwise you
will have
to merge the spec with -1 from reviewers, also if you postpone the details,
you won't be able to track, if these details were fixed.
Also with your approach the terminology is going to be changed, because
ready spec != merged spec anymore.

On Tue, Feb 3, 2015 at 9:46 PM, Andrew Woodward <xarses at gmail.com> wrote:

> Either we do specs, or we don't. Either every one has to land their specs
> before code or no one does. Its that simple.
>
> What should be sorted out? It is unavoidable that people will comment and
>> ask questions during development cycle.
>> I am not sure that merging spec as early as possible, and than add
>> comments and different fixes is good strategy.
>> On the other hand we need to eliminate risks.. but how merging spec can
>> help?
>
>
> The spec defining what has been committed already needs to be merged, and
> we can open another review to modify the spec into another direction if
> necessary.
>
> We can spend several month on polishing the spec, will it help
>> to release feature in time? I don't think so.
>
>
> The spec doesn't have to be perfect, but it needs to be merged prior to
> code describing it.
>
> I think the spec should be a synchronization point, where different
>> teams can discuss details and make sure that everything is correct.
>> The spec should represent the current state of the code which is
>> merged and which is going to be merged.
>
>
> This isn't the intent of the spec, its to document the extent, general
> direction, and impact of a feature. As a side effect, well defined specs
> can also serve as documentation for the feature. While the discussion is
> common on the spec, this should be done on a merged spec.
>
> On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L <eli at mirantis.com> wrote:
>
>> Hi,
>>
>> +1 to Dmitriy's comment.
>> We can spend several month on polishing the spec, will it help
>> to release feature in time? I don't think so.
>> Also with your suggestion we'll get a lot of patches over 2 thousands
>> lines of code, after spec is merged. Huge patches reduce quality,
>> because it's too hard to review, also such patches much harder
>> to get merged.
>> I think the spec should be a synchronization point, where different
>> teams can discuss details and make sure that everything is correct.
>> The spec should represent the current state of the code which is
>> merged and which is going to be merged.
>>
>> Thanks,
>>
>> On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
>> wrote:
>>
>>> Andrew,
>>> What should be sorted out? It is unavoidable that people will comment
>>> and ask questions during development cycle.
>>> I am not sure that merging spec as early as possible, and than add
>>> comments and different fixes is good strategy.
>>> On the other hand we need to eliminate risks.. but how merging spec can
>>> help?
>>>
>>> On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward <xarses at gmail.com>
>>> wrote:
>>>
>>>> Vova,
>>>>
>>>> Its great to see so much progress on this, however it appears that we
>>>> have started merging code prior to the spec landing [0] lets get it
>>>> sorted ASAP.
>>>>
>>>> [0] https://review.openstack.org/#/c/113491/
>>>>
>>>> On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin <vkuklin at mirantis.com>
>>>> wrote:
>>>> > Hi, Fuelers and Stackers
>>>> >
>>>> > I am glad to announce that we merged initial support for granular
>>>> deployment
>>>> > feature which is described here:
>>>> >
>>>> >
>>>> https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks
>>>> >
>>>> > This is an important milestone for our overall deployment and
>>>> operations
>>>> > architecture as well as it is going to significantly improve our
>>>> testing and
>>>> > engineering process.
>>>> >
>>>> > Starting from now we can start merging code for:
>>>> >
>>>> >
>>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
>>>> >
>>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing
>>>> >
>>>> > We are still working on documentation and QA stuff, but it should be
>>>> pretty
>>>> > simple for you to start trying it out. We would really appreciate your
>>>> > feedback.
>>>> >
>>>> > Existing issues are the following:
>>>> >
>>>> > 1) pre and post deployment hooks are still out of the scope of main
>>>> > deployment graph
>>>> > 2) there is currently only puppet task provider working reliably
>>>> > 3) no developer published documentation
>>>> > 4) acyclic graph testing not injected into CI
>>>> > 5) there is currently no opportunity to execute particular task -
>>>> only the
>>>> > whole deployment (code is being reviewed right now)
>>>> >
>>>> > --
>>>> > 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
>>>> > www.mirantis.ru
>>>> > vkuklin at mirantis.com
>>>> >
>>>> >
>>>> __________________________________________________________________________
>>>> > OpenStack Development Mailing List (not for usage questions)
>>>> > Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Andrew
>>>> Mirantis
>>>> Ceph community
>>>>
>>>> On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin <vkuklin at mirantis.com>
>>>> wrote:
>>>> > Hi, Fuelers and Stackers
>>>> >
>>>> > I am glad to announce that we merged initial support for granular
>>>> deployment
>>>> > feature which is described here:
>>>> >
>>>> >
>>>> https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks
>>>> >
>>>> > This is an important milestone for our overall deployment and
>>>> operations
>>>> > architecture as well as it is going to significantly improve our
>>>> testing and
>>>> > engineering process.
>>>> >
>>>> > Starting from now we can start merging code for:
>>>> >
>>>> >
>>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization
>>>> >
>>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing
>>>> >
>>>> > We are still working on documentation and QA stuff, but it should be
>>>> pretty
>>>> > simple for you to start trying it out. We would really appreciate your
>>>> > feedback.
>>>> >
>>>> > Existing issues are the following:
>>>> >
>>>> > 1) pre and post deployment hooks are still out of the scope of main
>>>> > deployment graph
>>>> > 2) there is currently only puppet task provider working reliably
>>>> > 3) no developer published documentation
>>>> > 4) acyclic graph testing not injected into CI
>>>> > 5) there is currently no opportunity to execute particular task -
>>>> only the
>>>> > whole deployment (code is being reviewed right now)
>>>> >
>>>> > --
>>>> > 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
>>>> > www.mirantis.ru
>>>> > vkuklin at mirantis.com
>>>> >
>>>> >
>>>> __________________________________________________________________________
>>>> > OpenStack Development Mailing List (not for usage questions)
>>>> > Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Andrew
>>>> Mirantis
>>>> Fuel community ambassador
>>>> Ceph community
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Andrew
> Mirantis
> Fuel community ambassador
> Ceph community
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150204/96311ab5/attachment.html>