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 < pshchelokovs...@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 <dtant...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Anton Arefiev Mirantis, Inc.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
