Hi Morgan, Coming back to this old thread after the TSC discussion today.
My feeling is that the argument that we have to do stress testing on the N-1 release because the installers are not available early in the cycle is an argument for changing the release process (or converting it to a continuous delivery model where the tip of master is always more or less releasable). Based on the conversation earlier, I think that we should not be attempting to backport fixes at all in OPNFV if we can avoid it - if operators and vendors want to fix issues that we have identified and fixed in the tip of master, then the back-porting is their job, not OPNFV's - and I do not think that this is a sufficient reason to break the "gold standard" of no fork, upstream first which has been the OPNFV mantra since its creation. If we can get towards a rolling release of tip-of-master in OPNFV, I think that this is what provides the greatest value to feature and testing projects, operators, and vendors. Features will be tested as integrated upstream, operators should get a higher cadence for new features, and in general we will not be expending extra effort in a community project back-porting fixes or features to N-1, or maintaining patches against N-1 to fix resiliency issues. Thanks, Dave. On 06/23/2017 02:39 AM, [email protected] wrote: > Hi > > as discussed yesterday during the weekly meeting, I prepared a slide > deck for the discussion with the TSC (I tried to summarize our > discussion and hope it reflects the wiki pages we created on the topic). > > Feel free to comment/complete/criticize/modify > @Gabriel: would you be OK to present the beginning? (stress tests > created for Danube + wiki page and email thread) > > I already booked a slot for the meeting next week > https://wiki.opnfv.org/display/meetings/TSC > the agenda looks already pretty busy not sure we will have time, we will > see > > /Morgan > > > > _________________________________________________________________________________________________________________________ > > > 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 > -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338 _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
