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/September 02 2009"

(Attendees)
 
(37 intermediate revisions by 3 users not shown)
Line 16: Line 16:
 
|- valign="top"
 
|- valign="top"
 
| width="30%" |  
 
| width="30%" |  
{| border="1"
+
PMC (and Strategic) Reps
 +
 
 +
{| width="30%" border="1"
 
|-
 
|-
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|  
+
| Y
 
|-
 
|-
 
| John Arthorne  
 
| John Arthorne  
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|  
+
| Y
|-
+
| Wayne Beaton
+
| Eclipse Foundation (appointed)
+
|
+
|-
+
| Cedric Brun
+
| OBEO (Strategic Developer)
+
|
+
 
|-
 
|-
 
| Oliver Cole  
 
| Oliver Cole  
 
| Tptp (PMC)  
 
| Tptp (PMC)  
|  
+
| N
|-
+
| Stefan Daume
+
| Cloudsmith Inc.(Strategic Developer)
+
|
+
 
|-
 
|-
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Doug Gaff  
 
| Doug Gaff  
 
| Dsdp (PMC)  
 
| Dsdp (PMC)  
|  
+
| Y
|-
+
| Neil Hauge
+
| Oracle (Strategic Developer)
+
|
+
|-
+
| Mika Hoikkala
+
| Nokia (Strategic Developer)
+
|
+
 
|-
 
|-
 
| Anthony Hunter  
 
| Anthony Hunter  
 
| Tools (PMC)  
 
| Tools (PMC)  
|  
+
| N
 
|-
 
|-
 
| Oisin Hurley  
 
| Oisin Hurley  
 
| Stp (PMC)  
 
| Stp (PMC)  
|  
+
| Y
 +
|-
 +
| Ed Merks
 +
| Modeling (PMC)
 +
| Y
 +
|-
 +
| Thomas Watson
 +
| Rt (PMC)
 +
| Y
 +
|-
 +
| David Williams
 +
| WTP (PMC) (appointed Chair)
 +
| Y
 +
|-
 +
| Gary Xue
 +
| Birt (PMC)
 +
| N
 +
|}
 +
 
 +
Strategic Reps
 +
 
 +
{| width="30%" border="1"
 +
|-
 +
| Cedric Brun
 +
| OBEO (Strategic Developer)
 +
| Y
 +
|-
 +
| Stefan Daume
 +
| Cloudsmith Inc.(Strategic Developer)
 +
| Y
 +
|-
 +
| Neil Hauge
 +
| Oracle (Strategic Developer)
 +
| Y
 +
|-
 +
| Kaloyan Raev
 +
| SAP AG (Strategic Developer)
 +
| Y
 
|-
 
|-
 
| Markus Knauer  
 
| Markus Knauer  
 
| Innoopract (Strategic Developer)  
 
| Innoopract (Strategic Developer)  
|  
+
| R
 
|-
 
|-
 
| Christian Kurzke  
 
| Christian Kurzke  
 
| Motorola (Strategic Developer)  
 
| Motorola (Strategic Developer)  
|  
+
| N
 +
|}
 +
 
 +
Appointed
 +
 
 +
{| width="30%" border="1"
 
|-
 
|-
| Ed Merks
+
| Wayne Beaton
| Modeling (PMC)  
+
| Eclipse Foundation (appointed)  
|  
+
| Y
 
|-
 
|-
 
| Mike Milinkovich  
 
| Mike Milinkovich  
 
| Eclipse Foundation (appointed)  
 
| Eclipse Foundation (appointed)  
|  
+
| N
 +
|}
 +
 
 +
<br><small>Note: feel free to correct any errors/omissions in above attendance record.</small><br><small>Y = Yes, attended</small><br><small>N = No, did not</small><br><small>R = regrets sent ahead of time</small>
 +
 
 +
|}
 +
 
 +
== Inactive Members  ==
 +
 
 +
{| cellpadding="15" border="0"
 +
|- valign="top"
 +
| width="30%" |
 +
{| width="30%" border="1"
 
|-
 
|-
| Kaloyan Raev
+
| &nbsp;?
| SAP AG (Strategic Developer)  
+
| Nokia (Strategic Developer)  
|  
+
| X
 
|-
 
|-
| James Saliba
+
| &nbsp;?
| CA Inc. (Strategic Developer)  
+
| CA Inc. (Strategic Consumer)  
|  
+
| X
 
|-
 
|-
| Sebastian Voigt
+
| &nbsp;?
 
| brox IT-Solutions GmbH (Strategic Developer)  
 
| brox IT-Solutions GmbH (Strategic Developer)  
|  
+
| X
|-
+
| Thomas Watson
+
| Rt (PMC)
+
|
+
|-
+
| David Williams
+
| WTP (PMC) (appointed Chair)
+
|
+
|-
+
| Gary Xue
+
| Birt (PMC)
+
|
+
 
|}
 
|}
  
<br><small>Note: feel free to correct any errors/omissions in above attendance record.</small><br><small>Y = attended</small><br><small>R = regrets sent ahead of time</small>  
+
<br><small>Note: "Inactive" refers to [http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic 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.</small>  
  
 
|}
 
|}
  
== Topics  ==
+
== Galileo SR1 ==
 
+
=== SR1 ===  
+
  
 
Any issues?  
 
Any issues?  
  
=== Helios ===
+
''none report at meeting''
  
*Review [[Planning Council/Galileo postmortem]].
+
== Helios==
:: It was mentioned (from Eclipse Platform team) that they didn't participate in forming these notes, but that it corresponds to their own team-meeting notes, except they would have also added the "+1", "+2" categories of dependencies may be too simplified, since in reality, some projects need to deliver part of their components, say, at +0 or +1, but another leaf component at +2 or +3). They would also appreciate making sure that the simultaneous release criteria be better explained.
+
:: We'll continually review list to make sure issues addressed, action plans made, owners found, etc.
+
  
*Begin Helios Discussions
+
=== Goals  ===
  
:*similar process of having Common Discover Site
+
*Simultaneous Release of participating projects
:*similar criteria?
+
:::to be in Common Discover Site
+
:::to be in Release  
+
::But with graduated levels of achievement where appropriate (e.g. 5 levels from none to excellent)
+
::Instead of "pass/fail", require a "statement of intent" for each item as part of Project Plan.
+
:::For example, some projects might declare "no intent to support accessibility checklists".
+
:::Projects would still be excluded on a case by case bases, if felt they interfered with the process, or other projects functionality, but otherwise try to get more "consumer oriented".
+
::''It was thought the above ideas worth pursuing (at least to the point of making more concrete, for review). Nothing firm decided. ''
+
  
:*Hot Items? ''No time to discuss this topic.''
+
:*Includes Simultaneous Milestones and testing (within the defined windows)
::Granularity: sub-Projects vs. Top Level Project?
+
::capabilities definitions and process?
+
::others?
+
  
 +
*Improve Eclipse by having extra release criteria
  
*Helios Dates:
+
:*These criteria, as previous years, need general agreement, and buy-in from all projects represented by Planning Council.
 +
:*The criteria are primarily in the interest of Strategic Members to improve adoption, and in most cases benefits end-users as well.
  
''These dates were agreed to, with the change of using 4th Wednesday of June, instead of last Wednesday of June, for the release''.
+
*Provide a "Common Discovery" repository, primarily for end-users, so they can explore and discover interesting and useful function, without having to try so hard.
 +
 
 +
:*This improves "early testing" of Projects, and eases migration to the new release.
 +
 
 +
*<strike>(new?) Provide a single code repository for extenders and committers to ease their development.</strike>
 +
 
 +
:*<strike>Is this one we really want to support? As committers, we often lean this way ... but, it is more work to do right, and in some cases can be at odds with the "ease of use" goal of a repository for end-users.</strike>
 +
 
 +
:''At meeting, this last item raised little discussion. Someone will need to champion it for us to add as a goal. ''
 +
 
 +
=== Items to improve this year?  ===
 +
 
 +
*the aggregation process (previously misnamed "the build").
 +
*accessibility
 +
*capabilities: definitions, reuse, and contribution process?
 +
 
 +
:''Note: This item was questioned "is it really needed" ... "are any adopters making use of it". The answer from most on PC was "no, not using". One said "yes, but just rolls their own, just uses to run off some UI". One (ok, me) said "yes, we'd like to, for complicated, large installs of multiple products with optional pieces, but is currently unworkable". It appeared no one else on the call was aware of the "progressive discovery" aspect of capabilities (which would be the one requiring the most work from cooperating projects). ''
 +
 
 +
*Structure and content of Common Discovery Site (e.g. categories, classifications, allowable content)
 +
 
 +
:*minimal IDE runtimes vs. distributions for extenders
 +
:*how to distinguish and organize IDE functional tools from runtime targets
 +
:*four divisions required? code, source, end-user doc, extender (sdk) doc
 +
 
 +
*How to track compliance?
 +
 
 +
:*bugzilla vs. web app?
 +
:*Granularity of tracking (sub-Projects vs. Top Level Projects)?
 +
:''This last item (how to track) generated the most controversy. Several thought the bugzilla system wasn't great, but not sure bad enough to invest in improvements. But, several thought "was terrible" and unworkable. As someone who had to monitor all 33 "projects" I agree its unworkable and not very meaningful. Conclusion: needs work.''
 +
 
 +
* Quick notes of comments from others at meeting
 +
 
 +
:* Doug
 +
 
 +
::none, except that he didn't want to go first :)
 +
 
 +
:*Neil
 +
 
 +
::The "must do" issue, and noted there are some items already in the "feedback notes" from last year.
 +
 
 +
:*Tom Watson
 +
 
 +
::IP. How to avoid mistakes, like the "mis-release" of one project last year, which had to be removed.
 +
:: Wayne mentioned he knew this was an issue and he has an agreement with IP team to do more "manual" checking of IP logs compared to distributions. But more work needed to better automate. Also mentioned more could be done by mentors and PMC. ''wtb For completeness, when an IP Log is submitted, I download the latest milestone build from the submitting project and compare the contents of that file with the log. I work with the project to resolve any discrepancies before greenlighting the IP team to do their review. IMHO, this is very late in the process; we need to make sure that problems are resolved earlier in the process. Perhaps we can draw on the Architecture Council mentors, and/or the PMCs to help''
 +
 
 +
:*Brian Payton
 +
 
 +
::Was interested in marking bundles as 'code', 'source', 'documentation' to improve ease of installs.
 +
 
 +
::Most concerned with API compatibility and binary compatibility. I suggested adding a 'release criteria' that (at least) projects must document their policy.
 +
 
 +
:*John Arthorne
 +
 +
::bugzilla tracking was awkward
 +
::better document "why" important (John volunteered!), such as "here's why it is in your best interest".
 +
::We will need all projects to use some new "standard" license to property fit into new install dialogs (which groups items by license, to make that agreement step easier (or feasible?).
 +
 
 +
:*Chris
 +
 
 +
::API tools and usage scans should be a "must do" (boos broke out in the virtual room). :)
 +
::PDE team can help incorporate this in builds/tests (another volunteer!)
 +
 
 +
:*Kaloyan
 +
 
 +
::would like to see easier updates from one release to another.
 +
::p2 errors are obscure
 +
   
 +
:*Stefan
 +
 
 +
::Would like to see structure of common discovery site improved (was that another volunteer?)
 +
 
 +
:*Cedric
 +
 
 +
::Would like to see more testing of packages fitting together, such as ui consistency, functional testing, etc.
 +
 
 +
:*Oisin
 +
 
 +
::ease pain of 'compliance' of must do items
 +
::he would like building-in api and usage tools (as a should-do item)
 +
 
 +
:*Ed
 +
 
 +
::Can't burden projects with more 'must do' items (but ok to ask to document items).
 +
 
 +
:*Wayne
 +
 
 +
::Granularity is problematic. Last year, "number of" projects was 33 vs. 51 depending on how you counted.
 +
::IP compliance issues. Would be better if logs were earlier.
 +
:::My note after meeting: perhaps we could have more checking on a milestone-by-milestone basis? Especially if "diffs" could be generated automatically?
 +
 
 +
=== Proposed (initial) process ===
 +
 
 +
*Continuous Milestones (beginning with M1)
 +
*Form cross-project teams to come up with recommendations for Planning Council
 +
 
 +
:*Anyone can participate, but I'd like to be only on invitation from Planning Council, to be sure we have a balanced, but diverse representation that mirrors the composition of the Planning Council.
 +
:*Planning council to act on those recommendations (one way or another).
 +
 
 +
*Not only better document and clarify criteria, but also refine their measuremet when possible (so, not just "yes or no', but, when possible "poor, medium, excellent", for example).
 +
*<strike>Require a "planned compliance" statement as part of the "standard plan"?</strike> ''Not discussed at meeting. I doubt it would be useful wihtout a vastly improved "tracking" system, which will be hard enough to implement.&nbsp;''
 +
 
 +
===Proposed (initial) Cross-Project Teams===
 +
 
 +
====Aggregation====
 +
 
 +
:John Arthorne (Platform)
 +
:Thomas Hallgren (Buckminster)
 +
 
 +
====Accessibiity====
 +
 
 +
:Tammy Strum (IBM)
 +
:Neil Hauge (Oracle)
 +
:Kaloyan Raev (SAP)
 +
:ACTF (they will decide exactly who later this week)
 +
 
 +
 
 +
====Capabilities====
 +
 
 +
:Tim deBoer (IBM/WTP)
 +
:Oleg Besedin (Platform)
 +
 
 +
====Structure of Common Discovery Site====
 +
 
 +
:?
 +
 
 +
====How to track====
 +
 
 +
:?
 +
 
 +
===Helios Dates===
 +
 
 +
 
 +
''This info is here for reference. (It was previously approved by PC). Will be moved to 'release document' soon.''
  
 
::M1 8/7 - 8/21  
 
::M1 8/7 - 8/21  
Line 211: Line 354:
 
::*In general, teams often have complicated inter-dependencies which are not captured by the simple "+1", "+2" descriptions. In those cases, it is up to those projects to work out their detailed inter-dependencies and agree to a processes to satisfy what they need from each other. The dates and deadlines listed by Planning Council, apply only to the final deliverable to the common repository.
 
::*In general, teams often have complicated inter-dependencies which are not captured by the simple "+1", "+2" descriptions. In those cases, it is up to those projects to work out their detailed inter-dependencies and agree to a processes to satisfy what they need from each other. The dates and deadlines listed by Planning Council, apply only to the final deliverable to the common repository.
  
<br>
+
==Review Planning Council/Galileo postmortem==
 +
 
 +
:: We'll continually review [[Planning Council/Galileo postmortem| the list of comments]] to make sure issues are addressed, action plans made, owners found, etc.
 +
 
 +
==ToDo Items==
  
*Do we have the right members? What to do about those that are inactive?
+
(volunteers welcome)
  
::For reference, there are 14 [http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic Strategic Members]
+
* create (and update) [http://www.eclipse.org/projects/project-plan.php?projectid=helios helios container plan] (Wayne volunteered)
  
:''It was decided to form "inactive" list, and work with Strategic members and/or EMO to get someone who can be active. Also, to better document benefits of participation.''
+
* coordinate community input for next year's name
  
*Next Meeting
+
==Next Meeting==
  
:September 2, Wednesday, Noon Eastern Time.
+
:[[Planning_Council/October_07_2009|October 7, Wednesday]], Noon Eastern Time.
  
 
==Reference ==
 
==Reference ==
  
[[Galileo Simultaneous Release]]
+
[[Helios Simultaneous Release]]
  
 
[http://www.eclipse.org/org/foundation/council.php#planning Planning Council Members]
 
[http://www.eclipse.org/org/foundation/council.php#planning Planning Council Members]
  
 
[[Simultaneous_Release_Roles]] and [[Simultaneous_Release_Roles/EMO]]
 
[[Simultaneous_Release_Roles]] and [[Simultaneous_Release_Roles/EMO]]

Latest revision as of 09:20, 3 September 2009

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, September 02, 2009, at 1600 UTC / 0900 SFO / 1200 NYC / 1700 London / 1800 Berlin
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) Y
John Arthorne Eclipse (PMC) Y
Oliver Cole Tptp (PMC) N
Brian Payton Datatools (PMC) Y
Doug Gaff Dsdp (PMC) Y
Anthony Hunter Tools (PMC) N
Oisin Hurley Stp (PMC) Y
Ed Merks Modeling (PMC) Y
Thomas Watson Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC) N

Strategic Reps

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

Appointed

Wayne Beaton Eclipse Foundation (appointed) Y
Mike Milinkovich Eclipse Foundation (appointed) N


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 Members

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

Galileo SR1

Any issues?

none report at meeting

Helios

Goals

  • Simultaneous Release of participating projects
  • Includes Simultaneous Milestones and testing (within the defined windows)
  • Improve Eclipse by having extra release criteria
  • These criteria, as previous years, need general agreement, and buy-in from all projects represented by Planning Council.
  • The criteria are primarily in the interest of Strategic Members to improve adoption, and in most cases benefits end-users as well.
  • Provide a "Common Discovery" repository, primarily for end-users, so they can explore and discover interesting and useful function, without having to try so hard.
  • This improves "early testing" of Projects, and eases migration to the new release.
  • (new?) Provide a single code repository for extenders and committers to ease their development.
  • Is this one we really want to support? As committers, we often lean this way ... but, it is more work to do right, and in some cases can be at odds with the "ease of use" goal of a repository for end-users.
At meeting, this last item raised little discussion. Someone will need to champion it for us to add as a goal.

Items to improve this year?

  • the aggregation process (previously misnamed "the build").
  • accessibility
  • capabilities: definitions, reuse, and contribution process?
Note: This item was questioned "is it really needed" ... "are any adopters making use of it". The answer from most on PC was "no, not using". One said "yes, but just rolls their own, just uses to run off some UI". One (ok, me) said "yes, we'd like to, for complicated, large installs of multiple products with optional pieces, but is currently unworkable". It appeared no one else on the call was aware of the "progressive discovery" aspect of capabilities (which would be the one requiring the most work from cooperating projects).
  • Structure and content of Common Discovery Site (e.g. categories, classifications, allowable content)
  • minimal IDE runtimes vs. distributions for extenders
  • how to distinguish and organize IDE functional tools from runtime targets
  • four divisions required? code, source, end-user doc, extender (sdk) doc
  • How to track compliance?
  • bugzilla vs. web app?
  • Granularity of tracking (sub-Projects vs. Top Level Projects)?
This last item (how to track) generated the most controversy. Several thought the bugzilla system wasn't great, but not sure bad enough to invest in improvements. But, several thought "was terrible" and unworkable. As someone who had to monitor all 33 "projects" I agree its unworkable and not very meaningful. Conclusion: needs work.
  • Quick notes of comments from others at meeting
  • Doug
none, except that he didn't want to go first :)
  • Neil
The "must do" issue, and noted there are some items already in the "feedback notes" from last year.
  • Tom Watson
IP. How to avoid mistakes, like the "mis-release" of one project last year, which had to be removed.
Wayne mentioned he knew this was an issue and he has an agreement with IP team to do more "manual" checking of IP logs compared to distributions. But more work needed to better automate. Also mentioned more could be done by mentors and PMC. wtb For completeness, when an IP Log is submitted, I download the latest milestone build from the submitting project and compare the contents of that file with the log. I work with the project to resolve any discrepancies before greenlighting the IP team to do their review. IMHO, this is very late in the process; we need to make sure that problems are resolved earlier in the process. Perhaps we can draw on the Architecture Council mentors, and/or the PMCs to help
  • Brian Payton
Was interested in marking bundles as 'code', 'source', 'documentation' to improve ease of installs.
Most concerned with API compatibility and binary compatibility. I suggested adding a 'release criteria' that (at least) projects must document their policy.
  • John Arthorne
bugzilla tracking was awkward
better document "why" important (John volunteered!), such as "here's why it is in your best interest".
We will need all projects to use some new "standard" license to property fit into new install dialogs (which groups items by license, to make that agreement step easier (or feasible?).
  • Chris
API tools and usage scans should be a "must do" (boos broke out in the virtual room). :)
PDE team can help incorporate this in builds/tests (another volunteer!)
  • Kaloyan
would like to see easier updates from one release to another.
p2 errors are obscure
  • Stefan
Would like to see structure of common discovery site improved (was that another volunteer?)
  • Cedric
Would like to see more testing of packages fitting together, such as ui consistency, functional testing, etc.
  • Oisin
ease pain of 'compliance' of must do items
he would like building-in api and usage tools (as a should-do item)
  • Ed
Can't burden projects with more 'must do' items (but ok to ask to document items).
  • Wayne
Granularity is problematic. Last year, "number of" projects was 33 vs. 51 depending on how you counted.
IP compliance issues. Would be better if logs were earlier.
My note after meeting: perhaps we could have more checking on a milestone-by-milestone basis? Especially if "diffs" could be generated automatically?

Proposed (initial) process

  • Continuous Milestones (beginning with M1)
  • Form cross-project teams to come up with recommendations for Planning Council
  • Anyone can participate, but I'd like to be only on invitation from Planning Council, to be sure we have a balanced, but diverse representation that mirrors the composition of the Planning Council.
  • Planning council to act on those recommendations (one way or another).
  • Not only better document and clarify criteria, but also refine their measuremet when possible (so, not just "yes or no', but, when possible "poor, medium, excellent", for example).
  • Require a "planned compliance" statement as part of the "standard plan"? Not discussed at meeting. I doubt it would be useful wihtout a vastly improved "tracking" system, which will be hard enough to implement. 

Proposed (initial) Cross-Project Teams

Aggregation

John Arthorne (Platform)
Thomas Hallgren (Buckminster)

Accessibiity

Tammy Strum (IBM)
Neil Hauge (Oracle)
Kaloyan Raev (SAP)
ACTF (they will decide exactly who later this week)


Capabilities

Tim deBoer (IBM/WTP)
Oleg Besedin (Platform)

Structure of Common Discovery Site

?

How to track

?

Helios Dates

This info is here for reference. (It was previously approved by PC). Will be moved to 'release document' soon.

M1 8/7 - 8/21
M2 9/18 - 10/2
Initial standard-format plans due 10/2
M3 10/30 - 11/13
M4 12/11 - 12/18 [note: beginning of 1 week windows]
M5 1/29 - 2/5 [seven week span from M4, to account for end-of-year holidays]
M6 3/12 - 3/19
EclipseCon 3/22 - 3/25
M7 4/30 - 5/7 [seven week span from M6, to account for EclipseCon]
Release: 6/23/2010 (4th Wednesday of June)
Notes regarding the +0, +1, +2, +3, EPP, and 'available' days
  • The first three milestones use a two-week window and the remaining milestones use 1-week windows.
  • The sub-deadline patterns within the windows are as follows:
2-week window pattern
+0   +1 +2 +3 EPP Available
Friday Sat Sun Mon Tue Wed Thur Fri Mon Tue Wed Thur Fri

1-week window pattern
+0 +1 +2 +3 EPP Available
Friday Monday Tuesday Wednesday Thursday Friday
  • This pattern was arrived at with a couple of considerations: a) it is very important that teams have a consistent rhythm (so, for example, easier for a team to "always deliver on Tuesday" rather than Monday's some milestones, Thursdays other milestones, etc. b) it represents the latest possible time to produce common-discovery site ... teams can, still, either on their own or work with other projects to do their final builds earlier, making their delivery available earlier to specific teams or test groups.
  • Remember, the +n categories represent latest possible time to complete what is required of common discovery site (generally, at noon, Eastern time, of the day). Teams have to do their builds and testing before these common-site deadlines.
  • In general, teams often have complicated inter-dependencies which are not captured by the simple "+1", "+2" descriptions. In those cases, it is up to those projects to work out their detailed inter-dependencies and agree to a processes to satisfy what they need from each other. The dates and deadlines listed by Planning Council, apply only to the final deliverable to the common repository.

Review Planning Council/Galileo postmortem

We'll continually review the list of comments to make sure issues are addressed, action plans made, owners found, etc.

ToDo Items

(volunteers welcome)

  • coordinate community input for next year's name

Next Meeting

October 7, Wednesday, Noon Eastern Time.

Reference

Helios Simultaneous Release

Planning Council Members

Simultaneous_Release_Roles and Simultaneous_Release_Roles/EMO

Back to the top