Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Yujun Zhang]

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
> .
> 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
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
> ___
> opnfv-project-leads mailing list
> opnfv-project-le...@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Brady Allen Johnson]

David,

One thing to keep in mind, there are at least 2 major events that could 
affect the "Planning Complete" and "Scenarios Defined" milestones, which 
are the ODL summit, the week of September 25th and the OpenStack summit 
in Barcelona, the week of October 25th.


Regards,

Brady


On 09/09/16 00:45, David McBride wrote:

Team,

I've posted an update to the schedule 
.  
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 
Email/Google Talk: dmcbr...@linuxfoundation.org 


Skype: davidjmcbride1
IRC: dmcbride


___
opnfv-project-leads mailing list
opnfv-project-le...@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads


___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Frank Brockners (fbrockne)]

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: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 23:52
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Team,

I've posted an update to the 
schedule.
  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
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Christopher Price]

Hi Frank,

 

I’m not sure the release date is realistic.

Given the way we use stable branch in our CI and release processes it has been 
apparent that it takes around a week or more for the labels and artefacts to be 
generated from stable.

 

I do think using a “window” for projects to progress to D release or not is 
valuable.

I would suggest having the CI team provide guidance on the latest possible date 
to branch to stable for any release.  (This depends on project adherence to CI 
processes and the processes themselves.)

 

/ Chris

 

From:  on behalf of "Frank 
Brockners (fbrockne)" 
Date: Tuesday 13 September 2016 at 12:42
To: David McBride , opnfv-project-leads 
, TECH-DISCUSS OPNFV 

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 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: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 23:52
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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  
wrote:

Team,

 

I've posted an update to the schedule.  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

Email/Google Talk: dmcbr...@linuxfoundation.org

Skype: davidjmcbride1

IRC: dmcbride



 

-- 

David McBride

Release Manager, OPNFV

Mobile: +1.805.276.8018

Email/Google Talk: dmcbr...@linuxfoundation.org

Skype: davidjmcbride1

IRC: dmcbride

___ opnfv-tech-discuss mailing list 
opnfv-tech-discuss@lists.opnfv.org 
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss 

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Frank Brockners (fbrockne)]

Hi Chris,

we can pull stable once projects are done with the work on the release (i.e. 
release criteria is met) – i.e. it does not have to be the release date itself, 
but whenever a project feels like “ready”. One week prior to the release sounds 
reasonable – assuming you know when you’ll release ;-).

BTW/ - Releng already adopts this “don’t branch” principle – they didn’t even 
branch for Colorado.

Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Dienstag, 13. September 2016 13:19
To: Frank Brockners (fbrockne) ; David McBride 
; opnfv-project-le...@lists.opnfv.org; 
TECH-DISCUSS OPNFV 
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 stable branch in our CI and release processes it has been 
apparent that it takes around a week or more for the labels and artefacts to be 
generated from stable.

I do think using a “window” for projects to progress to D release or not is 
valuable.
I would suggest having the CI team provide guidance on the latest possible date 
to branch to stable for any release.  (This depends on project adherence to CI 
processes and the processes themselves.)

/ Chris

From: 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of "Frank Brockners (fbrockne)" 
mailto:fbroc...@cisco.com>>
Date: Tuesday 13 September 2016 at 12:42
To: David McBride 
mailto:dmcbr...@linuxfoundation.org>>, 
opnfv-project-leads 
mailto:opnfv-project-le...@lists.opnfv.org>>,
 TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@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 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: 
opnfv-project-leads-boun...@lists.opnfv.org<mailto:opnfv-project-leads-boun...@lists.opnfv.org>
 [mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 23:52
To: 
opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>;
 TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
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 
mailto:dmcbr...@linuxfoundation.org>> 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
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride
___ opnfv-tech-discuss mailing list 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> 
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[morgan.richomme]

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:*opnfv-project-leads-boun...@lists.opnfv.org
> [mailto:opnfv-project-leads-boun...@lists.opnfv.org] *On Behalf Of
> *David McBride
> *Sent:* Montag, 12. September 2016 23:52
> *To:* opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV
> 
> *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
> mailto:dmcbr...@linuxfoundation.org>>
> wrote:
>
> Team,
>
>  
>
> I've posted an update to the schedule
> 
> .
>  
> 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 
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
> 
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>
>
>
>  
>
> -- 
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018 
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
> 
>
> 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
morgan.richo...@orange.com


_

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.

__

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Fatih Degirmenci]

Hi,


There are different reasons why releng doesn't branch off. But one of the most 
important reasons is that branching off releng will cause having multiple 
versions of CI (jenkins jobs, associated scripts, and so on) which will greatly 
increase the complexity of the machinery we have and increase the maintenance 
effort.


If I'm not looking into wrong place, ODL releng doesn't branch off either: 
https://git.opendaylight.org/gerrit/gitweb?p=releng%2Fbuilder.git;a=summary


/Fatih


From: opnfv-project-leads-boun...@lists.opnfv.org 
 on behalf of Frank Brockners 
(fbrockne) 
Sent: 13 September 2016 13:55:35
To: Christopher Price; David McBride; opnfv-project-le...@lists.opnfv.org; 
TECH-DISCUSS OPNFV
Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release] D-release 
schedule


Hi Chris,



we can pull stable once projects are done with the work on the release (i.e. 
release criteria is met) – i.e. it does not have to be the release date itself, 
but whenever a project feels like “ready”. One week prior to the release sounds 
reasonable – assuming you know when you’ll release ;-).



BTW/ - Releng already adopts this “don’t branch” principle – they didn’t even 
branch for Colorado.



Frank



From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Dienstag, 13. September 2016 13:19
To: Frank Brockners (fbrockne) ; David McBride 
; opnfv-project-le...@lists.opnfv.org; 
TECH-DISCUSS OPNFV 
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 stable branch in our CI and release processes it has been 
apparent that it takes around a week or more for the labels and artefacts to be 
generated from stable.



I do think using a “window” for projects to progress to D release or not is 
valuable.

I would suggest having the CI team provide guidance on the latest possible date 
to branch to stable for any release.  (This depends on project adherence to CI 
processes and the processes themselves.)



/ Chris



From: 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of "Frank Brockners (fbrockne)" 
mailto:fbroc...@cisco.com>>
Date: Tuesday 13 September 2016 at 12:42
To: David McBride 
mailto:dmcbr...@linuxfoundation.org>>, 
opnfv-project-leads 
mailto:opnfv-project-le...@lists.opnfv.org>>,
 TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@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 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: 
opnfv-project-leads-boun...@lists.opnfv.org<mailto:opnfv-project-leads-boun...@lists.opnfv.org>
 [mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 23:52
To: 
opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>;
 TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
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 
mailto:dmcbr...@linuxfoundation.org>> 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

Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>

Skype: davidjmcbride1

IRC: dmcbride





--

David McBride

Release Manager, OPNFV

Mobile: +1.805.276.8018

Email/Goo

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Dave Neary]

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 / Cell: +1-978-799-3338
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Christopher Price]

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"  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 / Cell: +1-978-799-3338
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss




___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[David McBride]

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 
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"  lists.opnfv.org on behalf of dne...@redhat.com> 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 / Cell: +1-978-799-3338
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
>


-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Christopher Price]

I would suggest a simple rule is that a release candidate can only be produced 
from the release branch.

 

From: David McBride 
Date: Tuesday 13 September 2016 at 20:57
To: Christopher Price 
Cc: Dave Neary , "Frank Brockners (fbrockne)" 
, opnfv-project-leads 
, TECH-DISCUSS OPNFV 

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  
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"  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 / Cell: +1-978-799-3338

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss






 

-- 

David McBride

Release Manager, OPNFV

Mobile: +1.805.276.8018

Email/Google Talk: dmcbr...@linuxfoundation.org

Skype: davidjmcbride1

IRC: dmcbride

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Frank Brockners (fbrockne)]

+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:chrispric...@gmail.com]
Sent: Dienstag, 13. September 2016 21:06
To: David McBride 
Cc: Dave Neary ; Frank Brockners (fbrockne) 
; opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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 
mailto:dmcbr...@linuxfoundation.org>>
Date: Tuesday 13 September 2016 at 20:57
To: Christopher Price mailto:chrispric...@gmail.com>>
Cc: Dave Neary mailto:dne...@redhat.com>>, "Frank Brockners 
(fbrockne)" mailto:fbroc...@cisco.com>>, 
opnfv-project-leads 
mailto:opnfv-project-le...@lists.opnfv.org>>,
 TECH-DISCUSS OPNFV 
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 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 
mailto:chrispric...@gmail.com>> 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" 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 on behalf of dne...@redhat.com<mailto:dne...@redhat.com>> 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 / Cell: 
+1-978-799-3338
___
opnfv-tech-discuss mailing list

opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss





--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Yujun Zhang]

+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 list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[morgan.richomme]

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 
> *Date: *Tuesday 13 September 2016 at 20:57
> *To: *Christopher Price 
> *Cc: *Dave Neary , "Frank Brockners (fbrockne)"
> , opnfv-project-leads
> , TECH-DISCUSS OPNFV
> 
> *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
> mailto:chrispric...@gmail.com>> 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"
>  <mailto:opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of
> dne...@redhat.com <mailto:dne...@redhat.com>> 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  / Cell:
> +1-978-799-3338 
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> <mailto:opnfv-tech-discuss@lists.opnfv.org>
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
>
>  
>
> -- 
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018 
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
> <mailto:dmcbr...@linuxfoundation.org>
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>
>
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> 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
morgan.richo...@orange.com


_

Ce message et ses pieces jointes peuvent contenir des inf

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Jonas Bjurel]

I don’t see why we need a OPNFV policy on when earliest a stable branch could 
happen – please explain!
BR/Jonas

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Tuesday, September 13, 2016 8:58 PM
To: Christopher Price 
Cc: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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 
mailto:chrispric...@gmail.com>> 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" 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 on behalf of dne...@redhat.com<mailto:dne...@redhat.com>> 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 / Cell: 
+1-978-799-3338
___
opnfv-tech-discuss mailing list

opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss






--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[David McBride]

Jonas,

There may not be sufficient resources available prior to the opening of the
window.  So, this is a signal to the infra/CI team to be prepared to
support CI on both master and stable branch.  However, perhaps we could
consider expanding the window from 1 week to, say 2 weeks.

David

On Tue, Sep 20, 2016 at 3:13 PM, Jonas Bjurel 
wrote:

> I don’t see why we need a OPNFV policy on when earliest a stable branch
> could happen – please explain!
>
> BR/Jonas
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *David McBride
> *Sent:* Tuesday, September 13, 2016 8:58 PM
> *To:* Christopher Price 
> *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' 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 
> 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"  lists.opnfv.org on behalf of dne...@redhat.com> 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 / Cell: +1-978-799-3338
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
>
>
>
>
> --
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>



-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Christopher Price]

Is there a constraint on CI here?  I am not so sure.

 

I think we have an opportunity to set the time that best suites our community 
needs, both the need for autonomy and the need to coalesce together toward a 
release.  These last few days trying to tie up loose ends for Colorado have 
demonstrated to me that complete autonomy is not necessary the right approach 
for us yet.

 

Maybe we could have a month window closing 10 days before release.   There 
should be milestones associated with that which guide the decisions.

 

/ Chris

 

From: David McBride 
Date: Wednesday 21 September 2016 at 19:24
To: Jonas Bjurel 
Cc: Christopher Price , opnfv-project-leads 
, TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

 

Jonas,

 

There may not be sufficient resources available prior to the opening of the 
window.  So, this is a signal to the infra/CI team to be prepared to support CI 
on both master and stable branch.  However, perhaps we could consider expanding 
the window from 1 week to, say 2 weeks.

 

David

 

On Tue, Sep 20, 2016 at 3:13 PM, Jonas Bjurel  wrote:

I don’t see why we need a OPNFV policy on when earliest a stable branch could 
happen – please explain!

BR/Jonas

 

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Tuesday, September 13, 2016 8:58 PM
To: Christopher Price 
Cc: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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  
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"  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 / Cell: +1-978-799-3338

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss





 

-- 

David McBride

Release Manager, OPNFV

Mobile: +1.805.276.8018

Email/Google Talk: dmcbr...@linuxfoundation.org

Skype: davidjmcbride1

IRC: dmcbride



 

-- 

David McBride

Release Manager, OPNFV

Mobile: +1.805.276.8018

Email/Google Talk: dmcbr...@linuxfoundation.org

Skype: davidjmcbride1

IRC: dmcbride

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Jonas Bjurel]

I really think this is unnecessary governance from the release projects, if a 
project secure resources them self and push relevant patches to releng to 
enable branch verification I have very hard time to see that anyone else should 
bother.
I also don’t see the point with the resources, I do understand that there is 
less resources need when only verifying master, but where does the resources 
come from when we eventually branch and do both master and stable verification, 
they just don’t pop up, infact they come from the pool of HW resources that has 
largely been unutilized during the early project cycle!
In the way proposed we will not utilize the human resources in an optimal way, 
as they will idle at the end of the project, not being allowed to move forward. 
Infact this already happened in Colorado, we could have pushed much harder!
BR/Jonas

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Wednesday, September 21, 2016 7:25 PM
To: Jonas Bjurel 
Cc: Christopher Price ; 
opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

Jonas,

There may not be sufficient resources available prior to the opening of the 
window.  So, this is a signal to the infra/CI team to be prepared to support CI 
on both master and stable branch.  However, perhaps we could consider expanding 
the window from 1 week to, say 2 weeks.

David

On Tue, Sep 20, 2016 at 3:13 PM, Jonas Bjurel 
mailto:jonas.bju...@ericsson.com>> wrote:
I don’t see why we need a OPNFV policy on when earliest a stable branch could 
happen – please explain!
BR/Jonas

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 On Behalf Of David McBride
Sent: Tuesday, September 13, 2016 8:58 PM
To: Christopher Price mailto:chrispric...@gmail.com>>
Cc: 
opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>;
 TECH-DISCUSS OPNFV 
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 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 
mailto:chrispric...@gmail.com>> 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" 
mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 on behalf of dne...@redhat.com<mailto:dne...@redhat.com>> 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 / Cell: 
+1-978-799-3338
___
opnfv-tech-discuss mailing list

opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss





--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundatio

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Tahhan, Maryam]

Hi David
Can you please clarify Milestone 3 (Installer integration with OpenStack)  in 
the context of Milestone 5 (Scenario integration and Feature Freeze).
 Milestone 3  is just an installer update with existing plugins (c plugins)? Is 
this correct? In which case when do installer updates occur for features 
included in Milestone 5?

Thanks in advance
Maryam

From: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Monday, September 12, 2016 10:52 PM
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

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 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Team,

I've posted an update to the 
schedule.
  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
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[David McBride]

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 MS6.

David

On Wed, Sep 28, 2016 at 4:01 AM, Tahhan, Maryam 
wrote:

> Hi David
>
> Can you please clarify Milestone 3 (Installer integration with OpenStack)
>  in the context of Milestone 5 (Scenario integration and Feature Freeze).
>
>  Milestone 3  is just an installer update with existing plugins (c
> plugins)? Is this correct? In which case when do installer updates occur
> for features included in Milestone 5?
>
>
>
> Thanks in advance
>
> Maryam
>
>
>
> *From:* opnfv-project-leads-boun...@lists.opnfv.org [mailto:
> opnfv-project-leads-boun...@lists.opnfv.org] *On Behalf Of *David McBride
> *Sent:* Monday, September 12, 2016 10:52 PM
> *To:* opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV <
> opnfv-tech-discuss@lists.opnfv.org>
> *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 <
> dmcbr...@linuxfoundation.org> wrote:
>
> Team,
>
>
>
> I've posted an update to the schedule
> .
> 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
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>
>
>
>
>
> --
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>



-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

[Tahhan, Maryam]

Thanks David

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Tuesday, October 4, 2016 5:25 AM
To: Tahhan, Maryam 
Cc: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 
; Power, Damien ; 
Mcmahon, Tony B 
Subject: Re: [opnfv-project-leads] [release] D-release schedule

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 MS6.

David

On Wed, Sep 28, 2016 at 4:01 AM, Tahhan, Maryam 
mailto:maryam.tah...@intel.com>> wrote:
Hi David
Can you please clarify Milestone 3 (Installer integration with OpenStack)  in 
the context of Milestone 5 (Scenario integration and Feature Freeze).
 Milestone 3  is just an installer update with existing plugins (c plugins)? Is 
this correct? In which case when do installer updates occur for features 
included in Milestone 5?

Thanks in advance
Maryam

From: 
opnfv-project-leads-boun...@lists.opnfv.org
 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org]
 On Behalf Of David McBride
Sent: Monday, September 12, 2016 10:52 PM
To: 
opnfv-project-le...@lists.opnfv.org;
 TECH-DISCUSS OPNFV 
mailto:opnfv-tech-discuss@lists.opnfv.org>>
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 
mailto:dmcbr...@linuxfoundation.org>> wrote:
Team,

I've posted an update to the 
schedule.
  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
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss