Open Stack

Hi Ivar, My personal preference is to see information related to a
particular feature in one place. So in cases like the ones you
describe, I would propose that we update the existing spec. Of course,
there is the problem of updating the same spec across different
releases (since we create a new directory for every release). Perhaps,
even in such cases we can start by copying over the original spec as
the first patch set, and then amend the specs to add the new changes
(thus making it clear as to what the delta is).

Definitely would like to hear what others think about this.

Thanks,
~Sumit.


On Wed, Mar 11, 2015 at 5:51 PM, Ivar Lazzaro <ivarlazzaro at gmail.com> wrote:
> Hello Folks,
>
> As a follow up of [0] I was working on a proposal for adding the same
> sharing capabilities to servicechain constructs. While thinking about the
> use cases for doing this, a question came to my mind: How should I deal with
> this improvement from  a process perspective?
>
> I'm not sure adding sharing capabilities to 2 more objects is exactly a new
> feature... It is more of a follow up of an existing one! What is the
> expected process in this case? Should I create a new spec? Modify the
> existing one? Create a detailed launchpad blueprint without a spec?
>
> Please provide guidance, thanks,
>
> Ivar.
>
> [0]
> https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/introduce-shared-attribute.rst
>
> __________________________________________________________________________
> 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
>