Hi Maryam,
MS3 simply requires that installers are able to successfully deploy non-SDN
scenarios and pass Functest smoke tests. MS5 requires that features have
finished implementation and that all scenarios are setup in Jenkins. Any
additional installer updates would need to be completed by
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: [op
lto:
> 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>
> *Cc:* opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV <
> opnfv-tech-discuss@lists.opnfv.org>
&
To: Christopher Price <chrispric...@gmail.com>
Cc: 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
I think that we've reduced the branch-related overhead in 'Danube
;
> *Cc: *Dave Neary <dne...@redhat.com>, "Frank Brockners (fbrockne)"
> <fbroc...@cisco.com>, opnfv-project-leads
> <opnfv-project-le...@lists.opnfv.org>, TECH-DISCUSS OPNFV
> <opnfv-tech-discuss@lists.opnfv.org>
> *Subject: *Re: [opnfv-tech-di
+1 for this simple solution.
On Wed, Sep 14, 2016 at 3:06 AM Christopher Price
wrote:
> I would suggest a simple rule is that a release candidate can only be
> produced from the release branch.
>
___
opnfv-tech-discuss mailing
...@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 th
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
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
id McBride
<dmcbr...@linuxfoundation.org>; 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
Hi Frank,
I’m not sure the release date is realistic.
Give
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
<dmcbr...@linuxfoundation.org>; 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
Hi Frank,
I’m not sure the release date is realistic.
Given the way we use stabl
@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release
schedule
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 o
Is it the same one from release D page?
https://wiki.opnfv.org/display/SWREL/D-Release
I assume I can track the update in the wiki page, can I?
--
Yujun
On Fri, Sep 9, 2016 at 6:46 AM David McBride
wrote:
> Team,
>
> I've posted an update to the schedule
>
14 matches
Mail list logo