Open Stack

Agree, we certainly need specs for discussing big feature, it would more
effective than ml;
not sure about for best place for it, probably we can start from
ironic-specs, and then decide do we need separate repo or not.

On Thu, Nov 19, 2015 at 3:39 PM, Pavlo Shchelokovskyy <
pshchelokovskyy at mirantis.com> wrote:

> Hi all,
>
> +1 for specs in general, big features require a proper review and
> discussion for which LP is not a good choice.
>
> +1 for not requiring a spec for small features, LP BP is enough for just
> time/release tracking, but of course cores can request a proper spec to be
> proposed if feeling feature is worth discussion.
>
> 0 for using ironic-specs. It will increase visibility to wider ironic
> community, sure. But it seems ironic-inspector has to decide how integrated
> it should be with the other ironic project infra pieces as well. For
> example, there is now a patch on review to build a proper sphinx docs for
> ironic-inspector. Should those then be published and where? Should
> ironic-inspector have own doc site e.g.
> http://docs.openstack.org/developer/ironic-inspector/, or somehow be
> incorporated in ironic doc site? IMO decision on specs and docs should be
> consistent.
>
> Best regards,
>
> On Thu, Nov 19, 2015 at 3:20 PM Dmitry Tantsur <dtantsur at redhat.com>
> wrote:
>
>> Hi folks!
>>
>> I've been dodging subj for some time (mostly due to my laziness), but
>> now it seems like the time has come. We're discussing 2 big features:
>> autodiscovery and HA that I would like us to have a proper consensus on.
>>
>> I'd like to get your opinion on one of the options:
>> 1. Do not have specs, only blueprints are enough for us.
>> 2. Reuse ironic-specs repo, create our own subdirectory with our own
>> template
>> 3. Create a new ironic-inspector-specs repo.
>>
>> I vote for #2, as sharing a repo with the remaining ironic would
>> increase visibility of large inspector changes (i.e. those deserving a
>> spec). We would probably use [inspector] tag in the commit summary, so
>> that people explicitly NOT wanting to review them can quickly ignore.
>>
>> Also note that I still see #1 (use only blueprints) as a way to go for
>> simple features.
>>
>> WDYT?
>>
>> __________________________________________________________________________
>> 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
>>
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.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
>
>


-- 
Best regards,
Anton Arefiev
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/ca370226/attachment.html>