Excerpts from Chris Dent's message of 2015-11-19 20:55:15 +:
> On Thu, 19 Nov 2015, Julien Danjou wrote:
>
> > It would be good to support that as being *normal*, not "potentially
> > incorrect and random"!
>
> Yes.
>
> The underlying issue in this thread is the dominance of the six month
>
Jesse Pretorius wrote:
> [...]
> The deployment projects, and probably packaging projects too, are faced
> with the same issue. There's no guarantee that their x release will be
> done on the same day as the OpenStack services release their x branches
> as the deployment projects still need some t
On Fri, Nov 20, 2015, at 04:32 AM, Julien Danjou wrote:
> On Fri, Nov 20 2015, Clark Boylan wrote:
>
> > If you have a stable/X.Y branch or stable/foo but are still wanting to
> > map onto the 6 month release cycle (we know this because you are running
> > devstack-gate) how do we make that mappin
On Fri, Nov 20 2015, Clark Boylan wrote:
> If you have a stable/X.Y branch or stable/foo but are still wanting to
> map onto the 6 month release cycle (we know this because you are running
> devstack-gate) how do we make that mapping? is it arbitrary? is there
> some deterministic method? Things l
On Thu, Nov 19, 2015, at 12:55 PM, Chris Dent wrote:
> On Thu, 19 Nov 2015, Julien Danjou wrote:
>
> > It would be good to support that as being *normal*, not "potentially
> > incorrect and random"!
>
> Yes.
>
> The underlying issue in this thread is the dominance of the six month
> cycle and
On 19 November 2015 at 09:43, Thierry Carrez wrote:
>
> So we have three models. The release:independent model is for projects
> that don't follow the common development cycle, and therefore won't make
> a "liberty" release. The release:cycle-with-milestones model is the
> traditional "one releas
Julien Danjou wrote:
> On Thu, Nov 19 2015, Doug Hellmann wrote:
>
>> In my mind the “independent” release model was originally meant to mean that
>> the project was completely on their own, doing potentially incorrect and
>> random
>> releases. It wasn’t something I anticipated projects *wanting
On Thu, 19 Nov 2015, Julien Danjou wrote:
It would be good to support that as being *normal*, not "potentially
incorrect and random"!
Yes.
The underlying issue in this thread is the dominance of the six month
cycle and the way this is perceived to be (any may actually be) a
benefit for distri
Doug :
[snip]
I get your point. This would indeed correctly model intermediate releases.
But since no other project in Openstack depends on networking-bgpvpn, what is
the value of forcing a release of the project synched at the end of a cycle ?
It raises your chances of having your project pack
On Thu, Nov 19 2015, Jim Rollenhagen wrote:
> This is actually the idea of the cycle-with-intermediary model. Projects
> following this model may release as early and often as they like, and
> choose a release near the same time as the coordinated release, to be
> the "cycle" release and the base
On Thu, Nov 19, 2015 at 04:35:24PM +0100, Julien Danjou wrote:
> On Thu, Nov 19 2015, Doug Hellmann wrote:
>
> > In my mind the “independent” release model was originally meant to mean that
> > the project was completely on their own, doing potentially incorrect and
> > random
> > releases. It wa
Hi Neil,
Neil Jerram :
[snip]
I've since realised that my initial statement above wasn't quite right.
In fact, because networking-calico uses Neutron interfaces that are
pretty stable (ML2 mech driver, DHCP interface driver, etc.) we have
found it manageable until now to develop a single (master
On Thu, Nov 19 2015, Doug Hellmann wrote:
> In my mind the “independent” release model was originally meant to mean that
> the project was completely on their own, doing potentially incorrect and
> random
> releases. It wasn’t something I anticipated projects *wanting* to use. It
> evolved to mea
> On Nov 19, 2015, at 9:28 AM, Thomas Morin wrote:
>
> Hi Thierry,
>
> Thanks for you answers, more below.
>
> Thierry Carrez :
>> Thomas Morin wrote:
>>> The starting point for this post is a specific Neutron sub-project
>>> (networking-bgpvpn) but I believe the issues raised are shared with
> On Nov 19, 2015, at 4:43 AM, Thierry Carrez wrote:
>
> Thomas Morin wrote:
>> The starting point for this post is a specific Neutron sub-project
>> (networking-bgpvpn) but I believe the issues raised are shared with
>> other neutron stadium project and possibly relevant beyond Neutron, to
>> p
Thomas Morin wrote:
> [...]
> But still...one last, very practical, question: until the framework is
> adjusted, can we pursue our liberty-targeted work in our master branch,
> and our backport work in our backport/kilo and backport/juno branches ?
> (of course, we will accept the inconvenience of
Hi Thierry,
Thanks for you answers, more below.
Thierry Carrez :
Thomas Morin wrote:
The starting point for this post is a specific Neutron sub-project
(networking-bgpvpn) but I believe the issues raised are shared with
other neutron stadium project and possibly relevant beyond Neutron, to
pro
Thanks to Thomas for continuing this discussion about networking-*
projects, and to Thierry for his responses below, and Ihar for his
earlier guidance. I have a couple further points that I hope may
contribute...
On 19/11/15 09:46, Thierry Carrez wrote:
> Thomas Morin wrote:
>> The starting point
Thomas Morin wrote:
> The starting point for this post is a specific Neutron sub-project
> (networking-bgpvpn) but I believe the issues raised are shared with
> other neutron stadium project and possibly relevant beyond Neutron, to
> projects tagged release-independent in general.
>
> In the conte
Hi everyone,
The starting point for this post is a specific Neutron sub-project
(networking-bgpvpn) but I believe the issues raised are shared with
other neutron stadium project and possibly relevant beyond Neutron, to
projects tagged release-independent in general.
In the context of the net
20 matches
Mail list logo