Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Planning Council/December 02 2015"

m (Added "pattern")
m (/* New Business)
 
(9 intermediate revisions by one other user not shown)
Line 44: Line 44:
 
| Dani Megert  
 
| Dani Megert  
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Sam Davis
 
| Sam Davis
 
| Mylyn (ALM) PMC  
 
| Mylyn (ALM) PMC  
|    
+
| Y   
 
|-
 
|-
 
| Brian Payton  
 
| Brian Payton  
Line 56: Line 56:
 
| Doug Schaefer
 
| Doug Schaefer
 
| Tools (PMC)  
 
| Tools (PMC)  
|
+
| Y
 
|-
 
|-
 
| Adrian Mos (Marc Dutoo )
 
| Adrian Mos (Marc Dutoo )
 
| SOA (PMC)  
 
| SOA (PMC)  
|  
+
| R
 
|-
 
|-
 
| Ed Merks  
 
| Ed Merks  
Line 68: Line 68:
 
| Ian Bull
 
| Ian Bull
 
| Rt (PMC)  
 
| Rt (PMC)  
|
+
| Y
 
|-
 
|-
 
| Chuck Bridgham  
 
| Chuck Bridgham  
Line 76: Line 76:
 
| Wayne Beaton  
 
| Wayne Beaton  
 
| Eclipse Foundation (appointed)  
 
| Eclipse Foundation (appointed)  
|      
+
| Y   
 
|-
 
|-
 
| David Williams  
 
| David Williams  
 
| (appointed Chair)
 
| (appointed Chair)
|      
+
| Y     
 
|}
 
|}
 
|
 
|
Line 88: Line 88:
 
| Nick Boldt
 
| Nick Boldt
 
| Redhat (Strategic Developer)  
 
| Redhat (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Remi Schnekenburger
 
| Remi Schnekenburger
Line 104: Line 104:
 
| Stephan Merker
 
| Stephan Merker
 
| SAP AG (Strategic Developer)  
 
| SAP AG (Strategic Developer)  
|  
+
|
 
|-
 
|-
 
| Markus Knauer  
 
| Markus Knauer  
Line 143: Line 143:
 
== Announcements ==
 
== Announcements ==
  
* ?
+
* Not official yet, but has been proposed to slip Java 9 about 6 months, to March 2017. That will be near our Neon.3 release so may have to adjust?
  
 
== Previous meeting minutes ==
 
== Previous meeting minutes ==
Line 166: Line 166:
 
:: - ''There was a general agreement this seemed reasonable, but, some wanted more detail, such as how "test time" would line up, for the milestone vs. update releases. So that will be the next step, for me to map our some detail, and show both milestones and update releases on same schedule or calendar.''   
 
:: - ''There was a general agreement this seemed reasonable, but, some wanted more detail, such as how "test time" would line up, for the milestone vs. update releases. So that will be the next step, for me to map our some detail, and show both milestones and update releases on same schedule or calendar.''   
  
:: - The "two milestone pattern"
+
:: - The "two milestone pattern" (one-week-window period)
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 173: Line 173:
 
| master || dev || dev || dev || dev || dev || stabilize/+0 || +1 to release || Odd Milestone || dev || dev || dev || dev || dev || stabilize/+0 || +1 to release || Even Milestone
 
| master || dev || dev || dev || dev || dev || stabilize/+0 || +1 to release || Odd Milestone || dev || dev || dev || dev || dev || stabilize/+0 || +1 to release || Even Milestone
 
|-
 
|-
| maint. || dev || dev || dev || dev || dev || dev || dev || dev || dev || dev || RC1 || RC2 || RC3 || RC4 || Quiet Week || Maint.X
+
| maint. || dev || dev || dev || dev || dev || dev || dev || dev || dev || RC1 || dev || RC2 || RC3 || RC4 || Quiet Week || Maint.X
 
|}
 
|}
 +
 +
:: - The "two milestone pattern" (two-week-window period)
 +
{| class="wikitable"
 +
|-
 +
| Stream/Week || 0 || 1 || 2 || 3 || 4 || 5 || 6 || release day || 0 || 1 || 2 || 3 || 4 || 5 || 6 || release day
 +
|-
 +
| master || dev || dev || dev || dev || stabilize/+0 || dev|| +1 to release || Odd Milestone || dev || dev || dev || dev || stabilize/+0  || dev || +1 to release || Even Milestone
 +
|-
 +
| maint. || dev || dev || dev || dev || dev || dev || dev || dev || dev || RC1 || dev || RC2 || RC3 || RC4 || Quiet Week || Maint.X
 +
|}
 +
 +
::* Questions on patterns:
 +
::: Do we still need the RC1 "warmup" to be two weeks "early"? I think nearly all projects are so good at this, we no longer need a "warmup" and could jump right into "real" RCs.
 +
::: Do we still need the "two-week-window pattern? Or, is one week always enough? Again, I think it speaks to the skill of the projects that we may no longer need it.
 +
 +
:::: -''There was agreement on this proposed plan, as well as agreement that we no longer need a 2 week RC1 warm up, and that we no longer need a two week window for 3 milestones.''
 +
:::: -''We were reminded -- and reminded to remind our projects! -- that one implication of the change is that the last service release will be AFTER EclipseCon NA.''
 +
 +
 
::: - This has one obvious advantage: for projects that are essentially working on one stream only (such as fixes-only, especially for first Update Release), they can submit same content to the Update Release, and the Milestones stream.  
 
::: - This has one obvious advantage: for projects that are essentially working on one stream only (such as fixes-only, especially for first Update Release), they can submit same content to the Update Release, and the Milestones stream.  
  
Line 191: Line 210:
 
* Off-cycle "hot fix" releases/patches. This is being tracked in {{bug|483322}}.  
 
* Off-cycle "hot fix" releases/patches. This is being tracked in {{bug|483322}}.  
  
: - ''We did not discuss this topic much, at 10/7 meeting.''
+
: - ''We did not discuss this topic much, at this meeting.''
  
 
: One proposal: have all features in EPP packages be "root features" and establish a procedure of adding new code to the Sim. Release repository "at any time" -- for "hot fixes" only ... after review/approval by Planning Council?  
 
: One proposal: have all features in EPP packages be "root features" and establish a procedure of adding new code to the Sim. Release repository "at any time" -- for "hot fixes" only ... after review/approval by Planning Council?  
Line 203: Line 222:
 
* Rolling "release" issue
 
* Rolling "release" issue
  
: - ''We did not discuss this topic much, at 10/7 meeting.''
+
: - ''We did not discuss this topic much, at this meeting.''
  
 
:* Upon re-reading, that was another topic discussed at Arch. Council.  
 
:* Upon re-reading, that was another topic discussed at Arch. Council.  
 
:* Probably several ways to solve ... if it is a real issue? ... and, if I understood what the "end goal" was better?
 
:* Probably several ways to solve ... if it is a real issue? ... and, if I understood what the "end goal" was better?
 +
 +
=== Neon new requirements ===
 +
 +
* If a bundle is already signed by "Eclipse" it must not be re-signed.
 +
 +
* Projects must provide b3aggrcon file change for every new contribution. Either change exact feature versions if pointing to a composite or change URL if pointing to a simple repository. (i.e. No more "set it and forget it" practice of pointing to a composite, and hoping the correct "latest version" gets picked).
 +
 +
* others?
 +
 +
:: -''No other requirements were named, and these two new ones were thought reasonable, and agreement "we were ready (and capable) of more rigor".''
 +
:: -''DW to update plan and requirement document, notify PC and allow a few days for comments, and then notify cross-project list.''
  
 
== New Business ==
 
== New Business ==
  
* ''It was mentioned it would be nice if not important, to "rekindle" the face-face meetings at EclipseCon NA ... or, some other form of more active Planning Council participation.
+
* Any volunteers to drive the naming of "Neon + 1"? We normally start this process in December or January.
 +
:: - ''No volunteers, so far. But it was suggested I send Chris a note (which I have done).''
 +
 
 +
* TODO: It was mentioned at a previous meeting it would be nice if not important to "rekindle" the face-face meetings at EclipseCon NA ... or, some other form of more active Planning Council participation, such "meeting your Planning Council Rep Hour"? (or BOF?)
 +
:: - ''Wayne took the action of creating [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02542.html a doodle poll] and coming up with 'topics' for a face-to-face meeting. Such as "how can we be more "product like".''
  
 
== Next Meeting  ==
 
== Next Meeting  ==

Latest revision as of 14:42, 3 December 2015

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, December 2, 2015, at 1200 Noon Eastern
Dial in: (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

Phone Numbers: (Check Asterisk/Numbers for more or current phone numbers.)

For all phone lines: Participant conference extension: 710 then enter pin 35498
  • Ottawa (local call in Ottawa) 1-613-454-1403
  • North America (toll free) 1-866-569-4992
  • Germany (local call anywhere in Germany) +49-692-2224-6059
  • France (local call anywhere in France) +33-17-070-8535
  • UK (toll free) 0800-033-7806
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
  • SIP clients:
call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
John Arthorne (occasional) Cloud (PMC)
Chris Aniszczyk Technology (PMC)
Dani Megert Eclipse (PMC) Y
Sam Davis Mylyn (ALM) PMC Y
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC) Y
Adrian Mos (Marc Dutoo ) SOA (PMC) R
Ed Merks Modeling (PMC)
Ian Bull Rt (PMC) Y
Chuck Bridgham WTP (PMC)
Wayne Beaton Eclipse Foundation (appointed) Y
David Williams (appointed Chair) Y
Strategic Reps
Nick Boldt Redhat (Strategic Developer) Y
Remi Schnekenburger CEA List (Strategic Developer)
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Stephan Merker SAP AG (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer)
Rajeev Dayal Google (Strategic Developer)
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
Inactive
[no name] CA Inc. (Strategic Consumer) X
[no name] Birt (PMC) X

Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.

Note: feel free to correct any errors/omissions in above attendance record.
Y = Yes, attended
N = No, did not
R = regrets sent ahead of time
D = delegated
X = not expected

Announcements

  • Not official yet, but has been proposed to slip Java 9 about 6 months, to March 2017. That will be near our Neon.3 release so may have to adjust?

Previous meeting minutes

  • Review previous meeting minutes if you'd like. That is review them before the meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.

Mars Planning

  • Mars.2 issues?
  • Remember Mars.2 RCs begin Jan 15 to Jan 22.

Neon Planning

  • - Neon's Update Release Dates
At our previous meeting it was decided to have 3 update releases (instead of current 2), and have them approximately equally spaced:
June (3) September (3) December (3) March [(3) June]
* I propose we plan the availability of Update Releases to be the same as the end of specific Neon+1 milestones.
- That would be M2, M4, and M6. (See Neon's schedule, for a rough idea of when Neon+1 milestones would be.
- There was a general agreement this seemed reasonable, but, some wanted more detail, such as how "test time" would line up, for the milestone vs. update releases. So that will be the next step, for me to map our some detail, and show both milestones and update releases on same schedule or calendar.
- The "two milestone pattern" (one-week-window period)
Stream/Week 0 1 2 3 4 5 6 release day 0 1 2 3 4 5 6 release day
master dev dev dev dev dev stabilize/+0 +1 to release Odd Milestone dev dev dev dev dev stabilize/+0 +1 to release Even Milestone
maint. dev dev dev dev dev dev dev dev dev RC1 dev RC2 RC3 RC4 Quiet Week Maint.X
- The "two milestone pattern" (two-week-window period)
Stream/Week 0 1 2 3 4 5 6 release day 0 1 2 3 4 5 6 release day
master dev dev dev dev stabilize/+0 dev +1 to release Odd Milestone dev dev dev dev stabilize/+0 dev +1 to release Even Milestone
maint. dev dev dev dev dev dev dev dev dev RC1 dev RC2 RC3 RC4 Quiet Week Maint.X
  • Questions on patterns:
Do we still need the RC1 "warmup" to be two weeks "early"? I think nearly all projects are so good at this, we no longer need a "warmup" and could jump right into "real" RCs.
Do we still need the "two-week-window pattern? Or, is one week always enough? Again, I think it speaks to the skill of the projects that we may no longer need it.
-There was agreement on this proposed plan, as well as agreement that we no longer need a 2 week RC1 warm up, and that we no longer need a two week window for 3 milestones.
-We were reminded -- and reminded to remind our projects! -- that one implication of the change is that the last service release will be AFTER EclipseCon NA.


- This has one obvious advantage: for projects that are essentially working on one stream only (such as fixes-only, especially for first Update Release), they can submit same content to the Update Release, and the Milestones stream.
- Nick suggested: Would this be a good time to look at changing the /staging/ and /maintenance/ URLs so they're *release-specific*?
Will track with bug 483475


- Also, looking at the schedule, the December "match up" seems a no brainer ... not much other time to do it?
- M6 matching the last Update Release is nice since gives "clear focus" for M7 and the end-game of Neon+1.
- And Neon.1 matching M2 completes the rhythm.
- From those "end dates" we would count backward, to establish the same RC pattern we have now.
- I've not looked closely, but believe the first "warmup" RC, would be same or near the previous Neon+1 milestone. (one quiet week, plus 3 one week RCs, plus 1 two week RC equals 6 weeks) [Is that good or bad? Do we still need that early warm up RC? (I'm inclined to say yes, if for nothing else, "new projects" joining the train, and for those adding minor feature updates -- we still want a relatively early warm-up for them, similar to an update release milestone).
  • Can we say now we all agree with these dates? (I suggest "official vote" for next meeting, but if disagreement or concerns speak up now!)
  • Has everyone had a chance to talk to their PMCs, Projects, or Strategic Members they represent? (Please do, we need, and want, complete buy-in from all stack holders -- that is, not so much what we dictate, as it is what they want ... or, at least tolerate).
  • Off-cycle "hot fix" releases/patches. This is being tracked in bug 483322.
- We did not discuss this topic much, at this meeting.
One proposal: have all features in EPP packages be "root features" and establish a procedure of adding new code to the Sim. Release repository "at any time" -- for "hot fixes" only ... after review/approval by Planning Council?
AND, change p2? to "not allow" addition of reference repositories during feature installs.
(Would likely have to be a "product preference" since some adopters may depend on that feature, but EPP could "set" the preference).
Easy for me to say "change p2" :) but ... who would do the work?
This "reference repositories issue" was a discussed as a concern at Architecture Council
Apparently there have been cases of users getting "mixed" installs because reference repositories are sometimes very broad. [I hope I've captured that issue correctly, I was not there, so please correct if I read it wrong.]
Does Oomph solve this problem at all? Does it have a possible solution?
  • Rolling "release" issue
- We did not discuss this topic much, at this meeting.
  • Upon re-reading, that was another topic discussed at Arch. Council.
  • Probably several ways to solve ... if it is a real issue? ... and, if I understood what the "end goal" was better?

Neon new requirements

  • If a bundle is already signed by "Eclipse" it must not be re-signed.
  • Projects must provide b3aggrcon file change for every new contribution. Either change exact feature versions if pointing to a composite or change URL if pointing to a simple repository. (i.e. No more "set it and forget it" practice of pointing to a composite, and hoping the correct "latest version" gets picked).
  • others?
-No other requirements were named, and these two new ones were thought reasonable, and agreement "we were ready (and capable) of more rigor".
-DW to update plan and requirement document, notify PC and allow a few days for comments, and then notify cross-project list.

New Business

  • Any volunteers to drive the naming of "Neon + 1"? We normally start this process in December or January.
- No volunteers, so far. But it was suggested I send Chris a note (which I have done).
  • TODO: It was mentioned at a previous meeting it would be nice if not important to "rekindle" the face-face meetings at EclipseCon NA ... or, some other form of more active Planning Council participation, such "meeting your Planning Council Rep Hour"? (or BOF?)
- Wayne took the action of creating a doodle poll and coming up with 'topics' for a face-to-face meeting. Such as "how can we be more "product like".

Next Meeting

  • January 6, 2016 - Regular First Wednesday Meeting

Reference

Neon Wiki page
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top