Hi Michael, just a quick note to let you know I saw your tweet. The community is heads-down for tomorrow’s go/no-go decision right now. I’d hazard a guess that you are not the only person looking for clarification on these points, and expect that your email weill be the jumping off pointy for that discussion once everyone comes up for air. Best Regards, -kenny
Kenny Paul, Technical Program Manager [email protected] 510.766.5945 > On Nov 14, 2017, at 9:24 PM, Michael Still <[email protected]> wrote: > > Hi, > > so I've been watching the video of the 9 November TSC meeting, and find the > discussion of the branching model for Amsterdam quite interesting. Is this > documented anywhere on the wiki? I ask because I have a couple of questions: > > - my understanding of the stated plan is that Amsterdam will be a stable > branch off master at release time > - that branch will receive back ported bug fixes and security fixes from > master > - _all_ bug fixes will be back ported, not just high priority changes > - features added in master will _not_ be back ported to the Amsterdam stable > branch > > I'm a bit confused about the discussion of a one month maintenance release > for Amsterdam. Does that imply back ports stop after that maintenance > release? Or is that just the timeline for the _first_ maintenance release? > > What about when Beijing is released? Is it another stable branch off master? > When Beijing is released, will that cause maintenance back ports to the > Amsterdam stable branch to cease? > > For reference, I am quite familiar with the OpenStack stable branch model, > which is quite similar in some respects. The OpenStack community has a > sliding window for what gets back ported, as documented at > https://docs.openstack.org/project-team-guide/stable-branches.html > <https://docs.openstack.org/project-team-guide/stable-branches.html> . > OpenStack supports two previous releases as stable branches, but the > consistent feedback from the operator community is that they'd like to see > that period extended. The reason this hasn't happened is mainly developer > resources (but also some technical limitations around gating). > > Another interesting difference is that OpenStack has a policy of only back > porting to stable branches, they never write new code directly against a > stable branch. Does the TSC have a read on what they want to do there? > > As ONAP becomes more widely adopted there will be pressure from operators to > provide supported releases for longer periods, so being clear on all this > from the outset seems wise. > > Thanks, > Michael > _______________________________________________ > onap-discuss mailing list > [email protected] > https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
