Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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 >

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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 >

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

> 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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

> 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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

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