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/October 6 2010"

(Other business)
(Helios SR1)
Line 142: Line 142:
  
 
* 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?  
 
* 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 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}}).

Revision as of 15:06, 6 October 2010

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.

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

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.



Announcements

  •  ?

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?

Maintenance Schedule

SR2 Fourth Friday of February 2/25/2011

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

Helios Retrospective

Any additions? No additions. Move to reference section.

Planning_Council/Helios_retrospective

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

Indigo Plan and Schedule

Indigo Requirements

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.

Issues and Proposal for 3.7 versus 4.1

Other business

  • I was reminded Mylyn is Top Level project now, and we should be sure to invite rep to Planning Council.

ToDo Items

  •  ?

Next Meeting

November 3, 12 noon Eastern

Reference

Indigo Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top