I really think this is unnecessary governance from the release projects, if a project secure resources them self and push relevant patches to releng to enable branch verification I have very hard time to see that anyone else should bother. I also don’t see the point with the resources, I do understand that there is less resources need when only verifying master, but where does the resources come from when we eventually branch and do both master and stable verification, they just don’t pop up, infact they come from the pool of HW resources that has largely been unutilized during the early project cycle! In the way proposed we will not utilize the human resources in an optimal way, as they will idle at the end of the project, not being allowed to move forward. Infact this already happened in Colorado, we could have pushed much harder! BR/Jonas
From: David McBride [mailto:dmcbr...@linuxfoundation.org] Sent: Wednesday, September 21, 2016 7:25 PM To: Jonas Bjurel <jonas.bju...@ericsson.com> Cc: Christopher Price <chrispric...@gmail.com>; opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule Jonas, There may not be sufficient resources available prior to the opening of the window. So, this is a signal to the infra/CI team to be prepared to support CI on both master and stable branch. However, perhaps we could consider expanding the window from 1 week to, say 2 weeks. David On Tue, Sep 20, 2016 at 3:13 PM, Jonas Bjurel <jonas.bju...@ericsson.com<mailto:jonas.bju...@ericsson.com>> wrote: I don’t see why we need a OPNFV policy on when earliest a stable branch could happen – please explain! BR/Jonas From: opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org> [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>] On Behalf Of David McBride Sent: Tuesday, September 13, 2016 8:58 PM To: Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>> Cc: opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>; TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>> Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule I think that we've reduced the branch-related overhead in 'Danube' by closing the stable branch window just 10 days before the release, as opposed to about a month with Colorado. My concern about individual projects deciding whether to branch is that I think that it creates some confusion about the location of the candidate release. I think it's simpler and more predictable if we have a common process for all projects participating in the release. David On Tue, Sep 13, 2016 at 8:21 AM, Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>> wrote: We are making some progress. While I do agree with this: “I think projects should have autonomy over when branches are created.”. I also think it is up to the release project to set the projects with the latest date to do it if they want to participate in any given release. I think that’s essentially what we are trying to tune and optimize for everyone in this dialog. / Chris On 13/09/16 16:10, "Dave Neary" <opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of dne...@redhat.com<mailto:dne...@redhat.com>> wrote: Hi, On 09/13/2016 06:42 AM, Frank Brockners (fbrockne) wrote: > one thing that we’ve not closed on in the discussion last Tuesday is the > stable-branching milestone. Per what Morgan and I elaborated on: > Branching occurs a lot of unnecessary overhead for projects which have a > single development stream only. Hence I’d like to propose that > > · the branching milestones **prior** to the release should > **only** be applied to projects which do parallel development. > > · All other projects would branch on the release date – so that we > have a proper maintenance branch. > > Thoughts? I'm in favour of anything that removes process overhead from projects - I think projects should have autonomy over when branches are created. Thanks, Dave. -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182<tel:%2B1-978-399-2182> / Cell: +1-978-799-3338<tel:%2B1-978-799-3338> _______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss -- David McBride Release Manager, OPNFV Mobile: +1.805.276.8018<tel:%2B1.805.276.8018> Email/Google Talk: dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org> Skype: davidjmcbride1 IRC: dmcbride -- David McBride Release Manager, OPNFV Mobile: +1.805.276.8018<tel:%2B1.805.276.8018> Email/Google Talk: dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org> Skype: davidjmcbride1 IRC: dmcbride
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
