Hi +1 / Frank branching make sense for // development and probably for feature development but for integration/testing, we saw in Brahmaputra and in Colorado that we systematically cherry pick the only argument could be that we cherry pick with delay (1-2 days), so we check first on master then merge on colorado to avoid breaking the colorado gate but the effort in term of conflict merging is high and the gating problematic should be solved through resources allocation: CI production POD / CI integration POD/ Community POD, we could manage production/integration with tags which will be less painful than with branches
planning completion is also a bit early...I planned to organize a functest Meetup after the C release to validate Functest D roadmap 3 weeks is very short all the more as I planned a Face to face meeting during OpenStack Summit (end of October) on this topic moreover if the planning is complete, i assume the scenarios are defined..so at least align the 2 did you define success criteria per milestones? /Morgan Le 13/09/2016 à 12:42, Frank Brockners (fbrockne) a écrit : > > David, > > > > 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? > > > > Thanks, Frank > > > > *From:*[email protected] > [mailto:[email protected]] *On Behalf Of > *David McBride > *Sent:* Montag, 12. September 2016 23:52 > *To:* [email protected]; TECH-DISCUSS OPNFV > <[email protected]> > *Subject:* Re: [opnfv-project-leads] [release] D-release schedule > > > > Reminder... if you haven't yet reviewed the schedule, please do so > before the TSC and release meetings on Tuesday, where it will likely > be discussed. > > > > David > > > > On Thu, Sep 8, 2016 at 3:45 PM, David McBride > <[email protected] <mailto:[email protected]>> > wrote: > > Team, > > > > I've posted an update to the schedule > > <https://wiki.opnfv.org/download/attachments/6827418/OPNFV%20Release%20%2522D%2522%20r2.pdf?version=1&modificationDate=1473367413338&api=v2>. > > Please review and provide feedback. > > > > Note: during the release meeting on Tuesday, we discussed > removing the JIRA milestone, since it was not considered release > gating. Since then, I've changed my mind. For the D-release, I > expect that we will have implemented our JIRA processes > sufficiently that we will be able to rely on JIRA to understand > project status. Therefore, it is appropriate to believe that if > we still have unresolved JIRA issues assigned to the release, then > the release is not complete. We will be discussing exactly how > this will be accomplished in the coming weeks. > > > > David > > > > > -- > > *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 > > > > > > -- > > *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 > -- 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
