+1 – that sounds like a really simple resolution to the problem: “Unless you’re on the release branch and the release runs are done using the branch, you cannot participate in the release”.
Frank From: Christopher Price [mailto:[email protected]] Sent: Dienstag, 13. September 2016 21:06 To: David McBride <[email protected]> Cc: Dave Neary <[email protected]>; Frank Brockners (fbrockne) <[email protected]>; [email protected]; TECH-DISCUSS OPNFV <[email protected]> Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule I would suggest a simple rule is that a release candidate can only be produced from the release branch. From: David McBride <[email protected]<mailto:[email protected]>> Date: Tuesday 13 September 2016 at 20:57 To: Christopher Price <[email protected]<mailto:[email protected]>> Cc: Dave Neary <[email protected]<mailto:[email protected]>>, "Frank Brockners (fbrockne)" <[email protected]<mailto:[email protected]>>, opnfv-project-leads <[email protected]<mailto:[email protected]>>, TECH-DISCUSS OPNFV <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> Skype: davidjmcbride1 IRC: dmcbride
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
