<div dir="ltr"><div>Hi all,</div><div><br></div>+1 for specs in general, big features require a proper review and discussion for which LP is not a good choice.<div><br><div>+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.<br></div><div><br></div><div>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. <a href="http://docs.openstack.org/developer/ironic-inspector/">http://docs.openstack.org/developer/ironic-inspector/</a>, or somehow be incorporated in ironic doc site? IMO decision on specs and docs should be consistent.</div><div><br></div><div>Best regards,</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 19, 2015 at 3:20 PM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks!<br>
<br>
I've been dodging subj for some time (mostly due to my laziness), but<br>
now it seems like the time has come. We're discussing 2 big features:<br>
autodiscovery and HA that I would like us to have a proper consensus on.<br>
<br>
I'd like to get your opinion on one of the options:<br>
1. Do not have specs, only blueprints are enough for us.<br>
2. Reuse ironic-specs repo, create our own subdirectory with our own<br>
template<br>
3. Create a new ironic-inspector-specs repo.<br>
<br>
I vote for #2, as sharing a repo with the remaining ironic would<br>
increase visibility of large inspector changes (i.e. those deserving a<br>
spec). We would probably use [inspector] tag in the commit summary, so<br>
that people explicitly NOT wanting to review them can quickly ignore.<br>
<br>
Also note that I still see #1 (use only blueprints) as a way to go for<br>
simple features.<br>
<br>
WDYT?<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div><div dir="ltr">-- <br></div><div dir="ltr"><span>Dr. Pavlo Shchelokovskyy</span><div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a>www.mirantis.com</a></div></div>