Re: [openstack-dev] [all] Switching to longer development cycles
Excerpts from Thomas Goirand's message of 2017-12-15 16:15:04 +0100: > On 12/14/2017 12:44 AM, Clint Byrum wrote: > > We can take stock of the intermediate releases over the last year, and make > > sure they all work together once a year. Chris Jones mentioned that we > > should > > give users time between milestones and release. I suggest we release an > > intermediary and _support it_. Let distros pick those up when they need to > > ship > > new features. > > I don't think this will happen. > > > Let users jump ahead for a few projects when they need the bug fixes. > > And that, I don't agree. New releases aren't to fix bugs, bugs should be > fixed in stable too, otherwise you face new issues trying to get a > bugfix. And that's why we have stable. > We have stable for critical bug fixes. However, performance enhancements, scalability improvements, API weirdness, are not backported. In general, most of what arrives in each commit is good for most users. Bug fixes are not all backported. If a regression happens, it happens because it leverages a scenario we don't properly test. > > I understand the belief that nobody will run the intermediaries. > > Not only that. Everyone is lagging a few release behind, and currently, > upstream OpenStack don't care backporting to older releases. > Right but if you de-couple projects a bit, folks can upgrade the stuff that they need to when they need to. As Matt R. says, this kinda works today. I suggest we start testing it more and asserting that it works. __ 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
Re: [openstack-dev] [all] Switching to longer development cycles
On 12/16/2017 5:51 AM, Kashyap Chamarthy wrote: Thinking a bit more, the above reminds of this[*] by DanPB a couple of years ago, where Dan's 'Modest Proposal' was: "switch to a development cycle that is exactly 2 months". But one pontential question that comes to mind from that old thread is how is this new proposal of 'one coordinated release per year' going to address the following: If your spec didn't make into this year's coordiated release, then does it have to 'sit out' for one whole year? The shorter release cycle argument addresses that by not coupling specs to a single release -- where specs can be submitted regardless of a release in question. Meanwhile, code development of the feature can happen over several cycles. And periodically re-evaluate it in light of new evidence and design discussions. As it stands[2], this problem seems mitgated by moving specs across releases and re-approving them (insofar as they make sense). Maybe in current times, the above specs issue is 'non-problem'. Happy to be corrected. Each project would have to decide what works for them, which might mean one or two intermediate releases within the 1 year coordinated release where we have a freeze period for new features, and then open up again for new spec reviews after the intermediate release to allow new content in again. If no one is picking up the intermediate release, then it's just self-imposed to force us to (1) work toward a deadline and not let things drag on for a year and (2) allow in new specs more than once a year so the above problem doesn't happen, or is at least mitigated. There are also comments elsewhere in this thread about extending the stability period, but again, that's per-project at this point. The proposal says nothing about a coordinated stability period. In the last few cycles we've had I think 2 weeks between the global feature freeze and RC1, which isn't much time for stability and flushing out last minute bugs. If we tried to incorporate both multiple freezes and stability periods, we might have something like: * 3 months of new dev (maybe freeze specs after a month?) * 1 month of no new feature work, only bugs, docs, testing * intermediate release * That would give you a shorter dev cycle than what we do today (at least in nova), and do it three times in a year. The only contributor problem this solves is people have more opportunities to get their spec/new feature considered, at least more than once in a year. It does not, however, automatically make those specs/new features a priority to get review and help from the core team to shepherd them through the pipeline. There was some discussion about the priority issue during the TC office hours a few days ago, and Dan Smith has said it elsewhere in this thread. The chances of getting work done is proportional to the shared understanding and value of the thing being proposed, including risk/size/complexity etc. Here are two concrete examples from part time contributors for nova: 1. https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/rebuild-keypair-reset.html 2. https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/scaleio-ephemeral-storage-backend.html #1 is already merged for queens (has been for awhile now). It's a global feature (not vendor backend specific) and not very complicated. The only downside is it's an API change so we're stuck supporting it forever if it turns out to be a bad idea. #2 has been getting re-proposed for several cycles now (even before it was eventually approved in Pike). It's a large single-vendor change which piles onto existing technical debt. There is really only motivation from anyone at Dell/EMC to get this done and therefore it doesn't get much review so it continues to trudge forward. This isn't because we don't like those people (Feodor has done a lot of great work in nova over the years, and Eric has been very patiently rebasing this change and requesting review without being pushy). It's because we only have so many people doing reviews and we have higher priorities to spend our review time on - or we have other low priority blueprints which simply have higher shared value. How do we solve that problem? Get someone from Dell/EMC to be full time active in Nova for a year or more and build the trust of the core team to want to review this change, and trust that the contributors will be around to maintain it after it's merged? That's not a realistic solution. We could dig up the slots/runways idea where we essentially do Kanban and this gets queued up and the core team must get it in eventually to start new work, regardless of priority. I don't have an answer. There are options. The 1 year release idea doesn't magically solve this problem. And arguably doing 3 intermediate releases per year, if we did that to solve the "missed the 1 year boat" issue, would add stress to the core
Re: [openstack-dev] [all] Switching to longer development cycles
On Thu, Dec 14, 2017 at 12:02:13PM +0100, Kashyap Chamarthy wrote: > On Wed, Dec 13, 2017 at 05:17:26PM +0100, Thierry Carrez wrote: [...] > > What it means: > > > > - We'd only do one *coordinated* release of the OpenStack components > > per year, and maintain one stable branch per year Thinking a bit more, the above reminds of this[*] by DanPB a couple of years ago, where Dan's 'Modest Proposal' was: "switch to a development cycle that is exactly 2 months". But one pontential question that comes to mind from that old thread is how is this new proposal of 'one coordinated release per year' going to address the following: If your spec didn't make into this year's coordiated release, then does it have to 'sit out' for one whole year? The shorter release cycle argument addresses that by not coupling specs to a single release -- where specs can be submitted regardless of a release in question. Meanwhile, code development of the feature can happen over several cycles. And periodically re-evaluate it in light of new evidence and design discussions. As it stands[2], this problem seems mitgated by moving specs across releases and re-approving them (insofar as they make sense). Maybe in current times, the above specs issue is 'non-problem'. Happy to be corrected. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html -- Re-evaluating the suitability of the 6 month release cycle [2] https://specs.openstack.org/openstack/nova-specs/readme.html -- /kashyap __ 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
Re: [openstack-dev] [all] Switching to longer development cycles
On Fri, Dec 15, 2017 at 10:11:24AM +0800, Zhenyu Zheng wrote: > On Thu, Dec 14, 2017 at 7:02 PM, Kashyap Chamarthy > wrote: [...] > > For a relatively mature (~7 years; and ~5 years if we count from the > > time governance changed to OpenStack Foudation) project, one official > > contributor gathering per year sounds fine. And for those that need > > more face time, people would continue to organize informal meetups. But > > admittedly, this shifts the logistics apsect onto contributors -- that's > > probably okay, many other contributor communities self-organize meetups. [...] > The contributors in APAC are growing and wish to be more involved in > OpenStack, it will be really hard for us to join informal meetups( VISA > Invitation letters, company support etc.) > So I really hope the current official technical gathering remains, so that > we can be more involved with the community. Hi, we both agree. I empathize with the Visa troubles. I actually said that the main official contributor gathering (PTG) should remain. Didn't mean to imply that the informal meetups MUST be held; it's only optional. -- /kashyap __ 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
