Difference between revisions of "Planning Council/October 6 2010"

From Eclipsepedia

Jump to: navigation, search
(Helios SR1)
(Other business)
 
(12 intermediate revisions by one user not shown)
Line 24: Line 24:
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|  
+
| Y
 
|-
 
|-
 
| John Arthorne [and Paul Webster]
 
| John Arthorne [and Paul Webster]
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Oliver Cole  
 
| Oliver Cole  
Line 36: Line 36:
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Anthony Hunter  
 
| Anthony Hunter  
 
| Tools (PMC)  
 
| Tools (PMC)  
|  
+
| N
 
|-
 
|-
 
| 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)  
|  
+
| N
 
|}
 
|}
  
Line 69: Line 69:
 
| Cedric Brun  
 
| Cedric Brun  
 
| OBEO (Strategic Developer)  
 
| OBEO (Strategic Developer)  
|  
+
| N
 
|-
 
|-
 
| 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  
 
| SAP AG (Strategic Developer)  
 
| SAP AG (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Markus Knauer
 
| Markus Knauer
 
| Innoopract (Strategic Developer)  
 
| Innoopract (Strategic Developer)  
|  
+
| N
 
|-
 
|-
 
| Christian Kurzke  
 
| Christian Kurzke  
 
| Motorola (Strategic Developer)  
 
| Motorola (Strategic Developer)  
|  
+
| N
 
|}
 
|}
  
Line 98: Line 98:
 
| Wayne Beaton  
 
| Wayne Beaton  
 
| Eclipse Foundation (appointed)  
 
| Eclipse Foundation (appointed)  
|  
+
| Y
 
|}
 
|}
  
Line 141: Line 141:
 
* Any issues? complaints?
 
* Any issues? complaints?
  
One issue to document, as feedback (that I have heard about): EMF didn't deliver any maintenance until the day after RC4 +1 day (but, unclear to me is if that was just download zips or any form of delivered fixes, even in helios repo?) ... but, I think, it deserves repeating that communication is key. We all need to make an effort to keep others informed. The late (or last minute?) changes caused TPTP to have to do a lot of re-work and was made worse by there being no notice or announcement on cross-project list. I'm sure there's many things that could have been different, from many teams .. but just documenting this case as once example of the importance of keeping others informed. Not to mention, of course, that incremental delivery of fixes allows for better testing.  
+
* One issue to document as feedback (that I have heard about from TPTP PMC/Planning Council Rep): EMF didn't deliver any maintenance until the day after RC4 +1 day [but, unclear to me is if that was just download zips or any form of delivered fixes, even in helios repo?] I think, it deserves repeating that communication is key. We all need to make an effort to keep others informed. The late (or last minute?) changes caused TPTP to have to do a lot of re-work and was made worse by there being no notice or announcement on cross-project list. I'm sure there's many things that could have been different, from all teams involved ... but just documenting this case as once example of the importance of keeping others informed. Not to mention, of course, that incremental delivery of fixes allows for better testing. I also suggested the TPTP team communicate more directly with EMF team either through their mailing list or cross-project list, to let them know when impacted, but I think in this case, by the time it was discovered there wasn't much to do. Anything we, as Planning Council, can do to help situations like this? Foster timely communication?
  
 +
::''Ed said they will communicate better in future.''
 +
 +
* The build machine failure and slow recovery was nearly enough to derail the scheduled release. Not sure what more we can do, but glad to hear IT team will provide more support for build machine recovery (See {{bug|325969}}).
 +
 +
* The mirrors were a bit overloaded with our "outflow" the day or two before, and had trouble "catching up".
 +
: There is no longer any need to wait until "day before" for projects to put their artifacts in their final location, as long as leave "invisible" until the official release. Everyone waiting until the day before means the mirrors are very busy pulling content the day before, and have trouble getting caught up and in a steady state before the actual release. So, one action is to make sure everyone is properly educated about his. It might take some thing more formal ... some projects promote 5 days before, some 4 days before, some 3 days before, etc. Also, may need better directions on how to promote but leave invisible ... perhaps many projects wait and promote at last minute because they don't know how to do that?''
 
=== Maintenance Schedule ===
 
=== Maintenance Schedule ===
  
Line 152: Line 158:
 
== Helios Retrospective ==
 
== Helios Retrospective ==
  
Any additions?
+
Any additions? ''No additions. Move to reference section.''
  
 
[[Planning_Council/Helios_retrospective]]
 
[[Planning_Council/Helios_retrospective]]
Line 158: Line 164:
 
== Indigo Status ==
 
== Indigo Status ==
  
* M2 repo successfully created  
+
* M2 repo successfully created ''[discovered after meeting I forgot to promote! Done now]''
  
 
* No M2 EPP packages  
 
* No M2 EPP packages  
Line 169: Line 175:
 
:subversive  
 
:subversive  
  
: Do they really intend to drop out? Or does this violate "once in always in"?  
+
: Do they really intend to drop out? Or does this violate "once in always in"?
 
+
  
 +
:: ''Tom with discuss with jetty and riena, Wayne and/or Chris to discuss with subversive''
  
 
== Indigo Plan and Schedule ==
 
== Indigo Plan and Schedule ==
  
 
[http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php Indigo Requirements]  
 
[http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php Indigo Requirements]  
 +
 +
Suggestions during meeting:
 +
 +
* Make explicit that to be in repo, feature includes must be strict, so installs or builds are reproducible. (Even if there might eventually be improvements that allow additional features, with loose constraints ... but "minimum" requirement is the strict inclusion. Unclear what loose requirement solution will be. Note: the strict requirements are the way things are currently done ... just best to make explicit, since it has come up before.
 +
 +
* Move capabilities to "good citizen" section (and check wording to make clear that to document "not supported" is one option ... or, possibly "we don't know what this means" :).
 +
 +
* Consistent license. No real change to requirement, but should provide pointers to bugs where standard "user agreement" may change (to include EDL) and where p2 may be improved to allow pointer to URI ... or something.
 +
 +
* Add a "must do" to be in EPP package, must run on/test on Eclipse 3.7.
 +
 +
* Add a "should do" to have a 4.1 theme item in plan to describe what project is doing for 4.1 (and give some examples).
  
 
Tracking "setup" required from Foundation in {{bug|321522}}  
 
Tracking "setup" required from Foundation in {{bug|321522}}  
  
 
See initial [[indigo| Indigo Wiki page]]
 
See initial [[indigo| Indigo Wiki page]]
 +
 +
Review: There is a subtle implication of specifying Java 6 as "minimum runtime" requirement. Currently, we require contributors to use Java 5 when using pack200, since if not, and if involves a jar that contains no Java (e.g. source or documentation) then it can not be unpacked with Java 5, Java 6 would be required. This has been a headache for people since for many it means tweaking build scripts so an "old" (1.5) VM is used for that one step. During aggregation, we purposely use Java 5 to catch errors in this regard. For Indigo, I propose we not worry about being consistent here, and just use Java 6 during aggregation. Some projects may still want to use 1.5 VMs to do their pack200 ... if their adopters want it ... but I see no reason for mass consistency here ... if Java 6 is assumed to be minimum runtime VM. Any issues? Dissent?
 +
 +
:''Some concern expressed, but mostly a matter of letting people know and documenting options. For example, for projects that '''want''' compatibility with VMs less than 1.6, they still can, of course, but will no longer get "built in" test from aggregation. Plus, should make clear, even a VM less than 1.6 can still use a pack200 (or, an unpack200 executable) from another VM, such as a 1.6 distribution, and [[Pack200#Pack200_Executable_location| specify it on their command line]] using <code>-Dorg.eclipse.update.jarprocessor.pack200</code>.'' 
  
 
=== Issues and Proposal for 3.7 versus 4.1 ===
 
=== Issues and Proposal for 3.7 versus 4.1 ===
Line 187: Line 209:
 
== Other business  ==
 
== Other business  ==
  
* ?
+
* ''We were reminded Mylyn is Top Level project now, and we should be sure to invite rep to Planning Council. ''
 +
 
 +
* ''John mentioned Platform may drop Motif support from swt ... decision not final yet, and not sure if it effects any adapters or members ... just giving a heads up''
  
 
== ToDo Items ==
 
== ToDo Items ==
  
* ?
+
* ''Note from Wayne, to Wayne: (actually from last meeting) Remember to review plans starting after M4 (at latest) so questions can be clarified before "road map" produced.''
 +
 
 +
* ''Wayne teased us all with promise of new tools to check CQs against downloads, which we projects can use ourselves ... but he wasn't ready to tell us about them today and he'll be saying more over next few days or weeks.''
 +
 
 +
* ''dw to sort out tracking path.''
  
 
== Next Meeting ==
 
== Next Meeting ==

Latest revision as of 15:27, 6 October 2010

Contents

[edit] Logistics

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

[edit] Attendees

PMC (and Strategic) Reps

Chris Aniszczyk Technology (PMC) Y
John Arthorne [and Paul Webster] Eclipse (PMC) Y
Oliver Cole Tptp (PMC) X
Brian Payton Datatools (PMC) Y
Anthony Hunter Tools (PMC) N
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) N

Strategic Reps

Cedric Brun OBEO (Strategic Developer) N
Stefan Daume Cloudsmith Inc.(Strategic Developer) N
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer) N
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
X = not expected

[edit] 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.



[edit] Announcements

  •  ?

[edit] Helios SR1

  • Any issues? complaints?
  • One issue to document as feedback (that I have heard about from TPTP PMC/Planning Council Rep): EMF didn't deliver any maintenance until the day after RC4 +1 day [but, unclear to me is if that was just download zips or any form of delivered fixes, even in helios repo?] I think, it deserves repeating that communication is key. We all need to make an effort to keep others informed. The late (or last minute?) changes caused TPTP to have to do a lot of re-work and was made worse by there being no notice or announcement on cross-project list. I'm sure there's many things that could have been different, from all teams involved ... but just documenting this case as once example of the importance of keeping others informed. Not to mention, of course, that incremental delivery of fixes allows for better testing. I also suggested the TPTP team communicate more directly with EMF team either through their mailing list or cross-project list, to let them know when impacted, but I think in this case, by the time it was discovered there wasn't much to do. Anything we, as Planning Council, can do to help situations like this? Foster timely communication?
Ed said they will communicate better in future.
  • The build machine failure and slow recovery was nearly enough to derail the scheduled release. Not sure what more we can do, but glad to hear IT team will provide more support for build machine recovery (See bug 325969).
  • The mirrors were a bit overloaded with our "outflow" the day or two before, and had trouble "catching up".
There is no longer any need to wait until "day before" for projects to put their artifacts in their final location, as long as leave "invisible" until the official release. Everyone waiting until the day before means the mirrors are very busy pulling content the day before, and have trouble getting caught up and in a steady state before the actual release. So, one action is to make sure everyone is properly educated about his. It might take some thing more formal ... some projects promote 5 days before, some 4 days before, some 3 days before, etc. Also, may need better directions on how to promote but leave invisible ... perhaps many projects wait and promote at last minute because they don't know how to do that?

[edit] Maintenance Schedule

SR2 Fourth Friday of February 2/25/2011

For detailed RC schedules, see Service Release Schedule in master plan

[edit] Helios Retrospective

Any additions? No additions. Move to reference section.

Planning_Council/Helios_retrospective

[edit] Indigo Status

  • M2 repo successfully created [discovered after meeting I forgot to promote! Done now]
  • No M2 EPP packages
And I've pestered Markus enough he's stopped returning my emails? :(
  • 3 projects not in M2:
jetty
riena
subversive
Do they really intend to drop out? Or does this violate "once in always in"?
Tom with discuss with jetty and riena, Wayne and/or Chris to discuss with subversive

[edit] Indigo Plan and Schedule

Indigo Requirements

Suggestions during meeting:

  • Make explicit that to be in repo, feature includes must be strict, so installs or builds are reproducible. (Even if there might eventually be improvements that allow additional features, with loose constraints ... but "minimum" requirement is the strict inclusion. Unclear what loose requirement solution will be. Note: the strict requirements are the way things are currently done ... just best to make explicit, since it has come up before.
  • Move capabilities to "good citizen" section (and check wording to make clear that to document "not supported" is one option ... or, possibly "we don't know what this means" :).
  • Consistent license. No real change to requirement, but should provide pointers to bugs where standard "user agreement" may change (to include EDL) and where p2 may be improved to allow pointer to URI ... or something.
  • Add a "must do" to be in EPP package, must run on/test on Eclipse 3.7.
  • Add a "should do" to have a 4.1 theme item in plan to describe what project is doing for 4.1 (and give some examples).

Tracking "setup" required from Foundation in bug 321522

See initial Indigo Wiki page

Review: There is a subtle implication of specifying Java 6 as "minimum runtime" requirement. Currently, we require contributors to use Java 5 when using pack200, since if not, and if involves a jar that contains no Java (e.g. source or documentation) then it can not be unpacked with Java 5, Java 6 would be required. This has been a headache for people since for many it means tweaking build scripts so an "old" (1.5) VM is used for that one step. During aggregation, we purposely use Java 5 to catch errors in this regard. For Indigo, I propose we not worry about being consistent here, and just use Java 6 during aggregation. Some projects may still want to use 1.5 VMs to do their pack200 ... if their adopters want it ... but I see no reason for mass consistency here ... if Java 6 is assumed to be minimum runtime VM. Any issues? Dissent?

Some concern expressed, but mostly a matter of letting people know and documenting options. For example, for projects that want compatibility with VMs less than 1.6, they still can, of course, but will no longer get "built in" test from aggregation. Plus, should make clear, even a VM less than 1.6 can still use a pack200 (or, an unpack200 executable) from another VM, such as a 1.6 distribution, and specify it on their command line using -Dorg.eclipse.update.jarprocessor.pack200.

[edit] Issues and Proposal for 3.7 versus 4.1

[edit] Other business

  • We were reminded Mylyn is Top Level project now, and we should be sure to invite rep to Planning Council.
  • John mentioned Platform may drop Motif support from swt ... decision not final yet, and not sure if it effects any adapters or members ... just giving a heads up

[edit] ToDo Items

  • Note from Wayne, to Wayne: (actually from last meeting) Remember to review plans starting after M4 (at latest) so questions can be clarified before "road map" produced.
  • Wayne teased us all with promise of new tools to check CQs against downloads, which we projects can use ourselves ... but he wasn't ready to tell us about them today and he'll be saying more over next few days or weeks.
  • dw to sort out tracking path.

[edit] Next Meeting

November 3, 12 noon Eastern

[edit] Reference

Indigo Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO