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/June 02 2010"

(Next Year's Name)
(Next Meeting)
 
(9 intermediate revisions by 3 users not shown)
Line 24: Line 24:
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|  
+
| N
 
|-
 
|-
 
| John Arthorne  
 
| John Arthorne  
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Oliver Cole  
 
| Oliver Cole  
 
| Tptp (PMC)  
 
| Tptp (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Brian Payton  
 
| Brian Payton  
Line 44: Line 44:
 
| Anthony Hunter  
 
| Anthony Hunter  
 
| Tools (PMC)  
 
| Tools (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Oisin Hurley  
 
| Oisin Hurley  
 
| Stp (PMC)  
 
| Stp (PMC)  
|  
+
| N
 
|-
 
|-
 
| Ed Merks  
 
| Ed Merks  
 
| Modeling (PMC)  
 
| Modeling (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Thomas Watson  
 
| Thomas Watson  
 
| Rt (PMC)  
 
| Rt (PMC)  
|  
+
| Y
 
|-
 
|-
 
| David Williams  
 
| David Williams  
 
| WTP (PMC) (appointed Chair)  
 
| WTP (PMC) (appointed Chair)  
|  
+
| Y
 
|-
 
|-
 
| Gary Xue  
 
| Gary Xue  
 
| Birt (PMC)  
 
| Birt (PMC)  
|  
+
| Y
 
|}
 
|}
  
Line 73: Line 73:
 
| Cedric Brun  
 
| Cedric Brun  
 
| OBEO (Strategic Developer)  
 
| OBEO (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Stefan Daume  
 
| Stefan Daume  
 
| Cloudsmith Inc.(Strategic Developer)  
 
| Cloudsmith Inc.(Strategic Developer)  
|  
+
| N
 
|-  
 
|-  
 
| Neil Hauge  
 
| Neil Hauge  
 
| Oracle (Strategic Developer)  
 
| Oracle (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Kaloyan Raev  
 
| Kaloyan Raev  
Line 89: Line 89:
 
| Markus Knauer  
 
| Markus Knauer  
 
| Innoopract (Strategic Developer)  
 
| Innoopract (Strategic Developer)  
|  
+
| R - travelling
 
|-
 
|-
 
| Christian Kurzke  
 
| Christian Kurzke  
 
| Motorola (Strategic Developer)  
 
| Motorola (Strategic Developer)  
|
+
| N
 
|}
 
|}
  
Line 102: Line 102:
 
| Wayne Beaton  
 
| Wayne Beaton  
 
| Eclipse Foundation (appointed)  
 
| Eclipse Foundation (appointed)  
|
+
| Y
 
|}
 
|}
  
Line 144: Line 144:
 
Should we do over? (Just kidding)
 
Should we do over? (Just kidding)
  
Indigo it is
+
[[Indigo]] it is
 
+
  
 
=== Who will lead the Planning Council next year? ===  
 
=== Who will lead the Planning Council next year? ===  
  
And the winner is ...
+
And the winner is ... myself (David Williams) to continue in this role.
  
 
=== Helios Release ===  
 
=== Helios Release ===  
Line 159: Line 158:
 
According to our schedule there is one more week of potential builds after RC4, labeled "Helios Final". I see on the planning wiki that it says, "only emergency fixes for very serious regressions will be considered."  I can't remember if we discussed this in the past, but what exactly does that mean? Does it mean the release train exception process should be used, with changes announced in advance and require approval from others? Or, will this be left to the discretion of each project?  Unless we've already covered this, we should probably decide on that soon. Note, the Eclipse TLP doesn't plan on any contributions after RC4 at the moment, but I just want to know the process in advance in case something comes up...  
 
According to our schedule there is one more week of potential builds after RC4, labeled "Helios Final". I see on the planning wiki that it says, "only emergency fixes for very serious regressions will be considered."  I can't remember if we discussed this in the past, but what exactly does that mean? Does it mean the release train exception process should be used, with changes announced in advance and require approval from others? Or, will this be left to the discretion of each project?  Unless we've already covered this, we should probably decide on that soon. Note, the Eclipse TLP doesn't plan on any contributions after RC4 at the moment, but I just want to know the process in advance in case something comes up...  
  
 
+
Decided:
 +
:Autobuilds turned off
 +
:Exceptions, requests for rebuilds can be made to cross-project-dev list (no need for Planning Council list).
 +
:: if fairly obvious, dw will trigger the rebuild (hm, can/should security be changed on that hudson job?)
 +
:: or if doubt, dw will ask for further review/discussion with PC or PMC
 +
:: there is a risk, since our setup depends on individual project repositories, that someone may "break the build", that is unrelated to original respin request
 +
::: so all projects need to use care, and make sure nothing changes during this time
  
 
: Let's review compliance:  
 
: Let's review compliance:  
Line 167: Line 172:
 
: Any to kick off the train?  
 
: Any to kick off the train?  
 
: Any gold stars to hand out?
 
: Any gold stars to hand out?
 +
:: Andrew Overholt and the Linux Tools Project is a shining example of joining the train well!
  
 
=== Maintenance Schedule ===
 
=== Maintenance Schedule ===
Line 191: Line 197:
 
[[Planning Council/Cross Project Teams/Aggregation]]
 
[[Planning Council/Cross Project Teams/Aggregation]]
  
 +
Any issues moving to new b3 Aggregator? {{bug|312645}}
  
 +
Should be produce hybrid p2/maven repo? {{bug|312656}}
  
 +
== Other business  ==
  
 +
* Process for exceptions like "breaking API change after M6"
 +
:: projects making the change should announce on cross-project
 +
:: the team that discovers it, has a responsibility to report is as a "breaking API change" (don't just swallow it)
 +
::: it might have been an accident or oversight and can be repaired for others
 +
::: even if not (even if it really is required) it is a good way to document the issue so others know about it.
  
== Other business  ==
+
* Should we have a combined/joint "migration guide" for all Helios projects? A central jump-off point?
 
+
*
+
  
 
== ToDo Items ==
 
== ToDo Items ==
Line 203: Line 215:
 
== Next Meeting ==
 
== Next Meeting ==
  
:[[Planning_Council/June_02_2010|June 2, Wednesday]], Noon Eastern Time.
 
  
 +
July 7. Have our yearly "feedback" session.
  
 
== Reference  ==
 
== Reference  ==

Latest revision as of 13:32, 2 June 2010

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, June 02, 2010, at 1600 UTC / 1200 Eastern
Dial-in: For the call-in numbers, see the "Project Review" number on Foundation Portal page.

Attendees

PMC (and Strategic) Reps

Chris Aniszczyk Technology (PMC) N
John Arthorne Eclipse (PMC) Y
Oliver Cole Tptp (PMC) Y
Brian Payton Datatools (PMC) R
Doug Gaff ??? Dsdp (PMC)
Anthony Hunter Tools (PMC) Y
Oisin Hurley Stp (PMC) N
Ed Merks Modeling (PMC) Y
Thomas Watson Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC) Y

Strategic Reps

Cedric Brun OBEO (Strategic Developer) Y
Stefan Daume Cloudsmith Inc.(Strategic Developer) N
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer) R
Markus Knauer Innoopract (Strategic Developer) R - travelling
Christian Kurzke Motorola (Strategic Developer) N

Appointed

Wayne Beaton Eclipse Foundation (appointed) Y


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

Inactive

 ? Nokia (Strategic Developer) X
 ? CA Inc. (Strategic Consumer) X
 ? brox IT-Solutions GmbH (Strategic Developer) X


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



Helios

Next Year's Name

Should we do over? (Just kidding)

Indigo it is

Who will lead the Planning Council next year?

And the winner is ... myself (David Williams) to continue in this role.

Helios Release

Post RC4 exception process?
Question from John:

According to our schedule there is one more week of potential builds after RC4, labeled "Helios Final". I see on the planning wiki that it says, "only emergency fixes for very serious regressions will be considered." I can't remember if we discussed this in the past, but what exactly does that mean? Does it mean the release train exception process should be used, with changes announced in advance and require approval from others? Or, will this be left to the discretion of each project? Unless we've already covered this, we should probably decide on that soon. Note, the Eclipse TLP doesn't plan on any contributions after RC4 at the moment, but I just want to know the process in advance in case something comes up...

Decided:

Autobuilds turned off
Exceptions, requests for rebuilds can be made to cross-project-dev list (no need for Planning Council list).
if fairly obvious, dw will trigger the rebuild (hm, can/should security be changed on that hudson job?)
or if doubt, dw will ask for further review/discussion with PC or PMC
there is a risk, since our setup depends on individual project repositories, that someone may "break the build", that is unrelated to original respin request
so all projects need to use care, and make sure nothing changes during this time
Let's review compliance:
Top Level
Flat view
Any to kick off the train?
Any gold stars to hand out?
Andrew Overholt and the Linux Tools Project is a shining example of joining the train well!

Maintenance Schedule

Fourth Friday of September? 9/24/2010

Fourth Friday of February? 2/25/2011

Next Year's Schedule

Not ready to discuss details, but the problems with +1, +2, +3 category (and short times) should be well discussed.

Similarly, Oliver brought up issue with need for better "warm-up" rhythm, especially if a prereq project is late. (EMF's "last minute" M6 delivery added pressure to TPTP's ability to build/test in time). No specific actions, process or remedies are known, but ... maybe a reminder to cross-project list that intermediate or warm-up builds are good (especially if going to be near deadline).

Cross-Project Teams

Aggregation

Planning Council/Cross Project Teams/Aggregation

Any issues moving to new b3 Aggregator? bug 312645

Should be produce hybrid p2/maven repo? bug 312656

Other business

  • Process for exceptions like "breaking API change after M6"
projects making the change should announce on cross-project
the team that discovers it, has a responsibility to report is as a "breaking API change" (don't just swallow it)
it might have been an accident or oversight and can be repaired for others
even if not (even if it really is required) it is a good way to document the issue so others know about it.
  • Should we have a combined/joint "migration guide" for all Helios projects? A central jump-off point?

ToDo Items

Next Meeting

July 7. Have our yearly "feedback" session.

Reference

Helios Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top