Open Stack

This should be a critical issue for the distributions around
community collaboration on stable branches they must support for their
customers. E.g. Security bugs

The product wg has been focusing on a forward looking roadmap. Rocky has
made me aware that a backwards looking support focused roadmap is just as
important, if not more important.

On Thursday, November 19, 2015, Rochelle Grober <rochelle.grober at huawei.com>
wrote:

> I'd like the group to consider adding one more item to the agenda, or to
> the next meeting's agenda:
>
> Stable Releases and the newly proposed Stable Release Team
>
> Some background:
>
> Juno just had its final release today and is now EOL.  Juno is 13 months
> old. If the standard process happens, its repository will be removed from
> git.OpenStack.org  I have made a plea to leave the repo to allow grenade
> testing to continue while Kilo is still getting patches.  Parallel to a
> request to keep Juno alive longer (from Tony Breeds, Rackspace), a
> discussion has been percolating about creating a stable release team, with
> PTL and cores, that would own the stable releases and the processes around
> them.  My count puts the number of active Stable Release devs at 4-5
> people, and Huawei has agreed to put a dev on this issue also.  All of this
> dovetails into a previous discussion we had on this list about sustaining
> engineering efforts and how we might get that rolling.  I think think it is
> rolling, with the new project/team.  We  now need to support it.
>
> The developer community used to support stable releases for 18 months,
> then 15, now 13 months.  The reason for the shortening cycle is the lack of
> developers willing to work on bakcporting bugfixes and maintaining the gate
> jobs in working condition.  The gates for various stable releases have
> often been broken and stayed broken for weeks at a time.  The new stable
> team is being chartered to address these shortcoming, but if the team
> fails, release maintenance cycles will remain as is.  If the team manages
> to get dev resources to keep fixes being backported and the gates working,
> then the team will determine the stable release schedules/policies and
> could extend the life of stable releases if they feel they have the
> manpower to do so.  Or, still may not.
>
> From the user survey:  30% of production clouds are still on Icehouse.
> 39% are still on Juno.
>
> Companies who supply distros, or do not actively move customers to latest
> releases essentially have to fork OpenStack releases after 13 months to
> maintain them for their contractual length of time, usually between 3-5
> years, and the fixes each of the distros provide are divergent from each
> other after the 13 months of Cummunity support.
>
> Operators on the ops ML have stated it takes 3-5 months to qualify a new
> OpenStack release before most, if not all of their upgrade planning even
> begins.  With lead times this long, it means that most operators are
> upgrading more than one release at upgrade time, and once or less per year.
>
> DefCore requires testing against the current or past two releases, which
> means that Juno will still be acceptable as an OpenStack release for
> certification under the 2016.01 guidelines.
>
> Why we should know/care about this:
>
> We had a discussion about sustaining engineering efforts, and engineering
> resources from the Product WG companies just a short bit ago.  We did not
> come to any conclusions, but it appeared to be an important issue to the WG
> members.  We have a chance to demonstrate a number of thing if we decide to
> get involved with the Stable Release Team now:  that we care about
> longevity of release maintenance beyond where the developer community is
> willing to support it, that we can bring resources to bear to address the
> "gap," and that we have valuable experience in the area of Release
> maintenance.  There might be others.
>
> So, I'd like to get this on the agenda and ML before it goes stale and
> there is no maneuverability with regards to this issue.
>
> --Rocky
>
>
> > -----Original Message-----
> > From: Barrett, Carol L [mailto:carol.l.barrett at intel.com <javascript:;>]
> > Sent: Thursday, November 19, 2015 5:56 PM
> > To: Kenny Johnston
> > Cc: OpenStack Product Work Group
> > Subject: Re: [Product] [OpenStack][Product WG] 11/23 Team Meeting
> > Agenda and Logistics
> >
> > I think it's worth discussing this.
> > Thanks Kenny.
> >
> > Sent from my iPhone
> >
> > On Nov 19, 2015, at 10:19 AM, Kenny Johnston
> > <kencjohnston at gmail.com <javascript:;><mailto:kencjohnston at gmail.com
> <javascript:;>>> wrote:
> >
> > Should we consider having IRC only meeting? That way it
> > lightens/eliminates the scribing load and we increase transparency for
> > the rest of the community.
> >
> > As I'm sure a number of you saw, JJ recently published some tips and
> > tricks[1] for hosting good productive chatroom meetings.
> >
> > [1] http://jjasghar.github.io/blog/2015/11/18/characteristics-of-a-
> > successful-chatroom-meeting/
> >
> > On Thu, Nov 19, 2015 at 10:37 AM, Barrett, Carol L
> > <carol.l.barrett at intel.com <javascript:;><mailto:
> carol.l.barrett at intel.com <javascript:;>>> wrote:
> > Hi Folks - We're on for our regular team meeting on 11/23. Thanks Sean
> > for volunteering to lead the meeting this week! Details below.
> >
> > One more thing - The voice line allows us to have v productive
> > meetings, but in order to best support the Community we need to have a
> > parallel stream on the IRC channel. Moving forward, I think we should
> > have someone who is designated as the IRC scribe (it's hard for the
> > presenter to be the scribe too!), as well as ask everyone to add their
> > comments to the IRC. Pls respond if you have questions or other
> > thoughts on this.
> >
> > Logistics
> > IRC: #openstack-meeting-alt
> > Call in access: (888) 875-9370<tel:%28888%29%20875-9370>, Bridge: 3;
> > Passcode: 9518007#
> > Etherpad: https://etherpad.openstack.org/p/PWG_11_23_15
> >
> > Agenda
> > *       Recruit a volunteer to scribe discussion points into IRC
> > *       Mid-Cycle Planning - All
> > o       https://etherpad.openstack.org/p/PWG_Mitaka_Midcycle
> > *       User Story Updates -
> > http://specs.openstack.org/openstack/openstack-user-stories/
> > o       Leong & Kenny: Rolling Upgrades
> > o       Jay & Deric: Onboarding Hosts and VMs into OpenStack for
> > Management
> > o       Steve: Complex Instance Placement
> > *       Ops Feedback from Tokyo and Follow-up - Shamail (he will be on
> > IRC only)
> > *       Opens - All
> >
> > Happy Thanksgiving.
> > Carol
> >
> >
> > _______________________________________________
> > Product-wg mailing list
> > Product-wg at lists.openstack.org <javascript:;><mailto:
> Product-wg at lists.openstack.org <javascript:;>>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
> >
> >
> >
> > --
> > Kenny Johnston
> >
> > _______________________________________________
> > Product-wg mailing list
> > Product-wg at lists.openstack.org <javascript:;>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org <javascript:;>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>


-- 
~sean