OK but in this case we need to have CI for the release and CI for the master, which is not the case today for all the installers
As said, the only argument for me to branch is to be able to break master before going to release gate and then secure the release but today, in some cases we do not have the choice as there is only 1 gate, so if we want to test we need to cherry pick .. and hope it will not break the gate.... We should in the future clearly distinguish CI integration (master) and CI production (release) and have both up&running Le 13/09/2016 à 21:06, Christopher Price a écrit : > > I would suggest a simple rule is that a release candidate can only be > produced from the release branch. > > > > *From: *David McBride <[email protected]> > *Date: *Tuesday 13 September 2016 at 20:57 > *To: *Christopher Price <[email protected]> > *Cc: *Dave Neary <[email protected]>, "Frank Brockners (fbrockne)" > <[email protected]>, opnfv-project-leads > <[email protected]>, TECH-DISCUSS OPNFV > <[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 -- Morgan Richomme Orange/ IMT/ OLN/ CNC/ NCA/ SINA Network architect for innovative services Future of the Network community member Open source Orange community manager tel. +33 (0) 296 072 106 mob. +33 (0) 637 753 326 [email protected] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
