On 11/6/2015 4:43 AM, Thierry Carrez wrote:
Tony Breeds wrote:[...] 1) Is it even possible to keep Juno alive (is the impact on the project as a whole acceptable)?It is *technically* possible, imho. The main cost to keep it is that the branches get regularly broken by various other changes, and those breaks are non-trivial to fix (we have taken steps to make branches more resilient, but those only started to appear in stable/liberty). The issues sometimes propagate (through upgrade testing) to master, at which point it becomes everyone's problem to fix it. The burden ends up falling on the usual gate fixers heroes, a rare resource we need to protect. So it's easy to say "we should keep the branch since so many people still use it", unless we have significantly more people working on (and capable of) fixing it when it's broken, the impact on the project is just not acceptable. It's not the first time this has been suggested, and every time our answer was "push more resources in fixing existing stable branches and we might reconsider it". We got promised lots of support. But I don't think we have yet seen real change in that area (I still see the same usual suspects fixing stable gates), and things can still barely keep afloat with our current end-of-life policy... Stable branches also come with security support, so keeping more branches opened mechanically adds to the work of the Vulnerability Management Team, another rare resource. There are other hidden costs on the infrastructure side (we can't get rid of a number of things that we have moved away from until the old branch still needing those things is around), but I'll let someone closer to the metal answer that one.Assuming a positive answer: 2) Who's going to do the work? - Me, who else? 3) What do we do if people don't actually do the work but we as a community have made a commitment?In the past, that generally meant people opposed to the idea of extending support periods having to stand up for the community promise and fix the mess in the end. PS: stable gates are currently broken for horizon/juno, trove/kilo, and neutron-lbaas/liberty. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
In general I'm in favor of trying to keep the stable branches available as long as possible because of (1) lots of production deployments not upgrading as fast as we (the dev team) assume they are and (2) backporting security fixes upstream is much nicer as a community than doing it out of tree when you support 5+ years of releases.
Having said that, the downside points above are very valid, i.e. not enough resources to help, we want to drop py26, things get wedged easily and there aren't people around to monitor or fix it, or understand how all of the stable branch + infra + QA stuff fits together.
It also extends the life and number of tests that need to be run against things in Tempest, which already runs several dozen jobs per change proposed today (since Tempest is branchless).
At this point stable/juno is pretty much a goner, IMO. The last few months of activity that I've been involved in have been dealing with requirements capping issues, which as we've seen you fix one issue to unwedge a project and with the g-r syncs we end up breaking 2 other projects, and the cycle never ends.
This is not as problematic in stable/kilo because we've done a better job of isolating versions in g-r from the start, but things won't get really good until stable/liberty when we've got upper-constraints in action.
So I'm optimistic that we can keep stable/kilo around and working longer than what we've normally done in the past, but I don't hold out much hope for stable/juno at this point given it's current state.
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
