Jump to: navigation, search

Difference between revisions of "Planning Council/April 06 2011"

(Members and Attendees)
(Proposal)
Line 159: Line 159:
 
For Juno, Eclipse 4.2 will be the primary workbench, but all (participating) projects will support and maintain a 3.8 based deliverable.  
 
For Juno, Eclipse 4.2 will be the primary workbench, but all (participating) projects will support and maintain a 3.8 based deliverable.  
  
'Primary workbench' means Eclipse 4.2 will be the primary workbench that (participating) projects build against, and test, and will be provided in the common repository, and EPP packages. In all cases, "4.2" means "4.2 plus compatibility layer". That is, no one is expected to split streams, use 4.2 workbench "native" or exploit anything specific to 4.2. Of course, projects can if they want to (within the '''Assumptions''', below) but there is no requirement to exploit 4.2 directly and probably better if low level projects do not.  
+
'Primary workbench' means Eclipse 4.2 will be the primary workbench that (participating) projects build against, and test, and will be provided in the common repository, and EPP packages. In all cases, "4.2" means "4.2 plus compatibility layer". That is, no one is expected to split streams, use 4.2 workbench "native" or exploit anything specific to 4.2. Of course, projects can if they want to (within the [[Planning_Council/April_06_2011#Assumptions| ''Assumptions'']], below) but there is no requirement to exploit 4.2 directly and probably better if low level projects do not.  
  
'Support and maintain a 3.8 based deliverables' means that (participating) projects, at a minimum, agree to continue to provide a deliverable that can be used with 3.8 workbench. In most cases, we hope, this is the exact same deliverable used for the 4.2 based deliverable. This would be true for projects that do not use 4.2 specific API and simply rely on the compatibility layer. But for projects that want to exploit something new in 4.2 workbench ... that is split streams and have one specific to the 4.2 workbench prereq ... then they would still be expected to provide something adopters or upstream projects could use for 3.8-based installs. When there are two separate deliverables, the 3.8-based maintenance version might simply be Indigo SR2, at a minimum.  But, even then, there might be cases where versions ranges have to be adjusted, or bugs fixed due to changes in 3.8 (since Indigo SR2 will be built and tested with Eclipse 3.7.2). Those are the minimum assumed deliverables. Naturally, projects may do more if they have desire or reason to, but the goal is to allow adopters an extended "transition" period to 4.x, if needed, where things will still work, in some form, using 3.8 based prereqs. For projects that do have "two deliverables", the 3.8 based one would be available on their own download sites and their own project's software site repositories, not the common repository.
+
'Support and maintain a 3.8 based deliverables' means that (participating) projects, at a minimum, agree to continue to provide a deliverable that can be used with 3.8 workbench. In most cases, we hope, this is the exact same deliverable used for the 4.2 based deliverable. This would be true for projects that do not use 4.2 specific API and simply rely on the compatibility layer. But for projects that want to exploit something new in 4.2 workbench ... that is split streams and have one specific to the 4.2 workbench prereq ... then they would still be expected to provide something adopters or upstream projects could use for 3.8-based installs. When there are two separate deliverables, the 3.8-based maintenance version might simply be Indigo SR2, at a minimum.  But, even then, there might be cases where versions ranges have to be adjusted, or bugs fixed due to changes in 3.8 (since Indigo SR2 will be built and tested with Eclipse 3.7.2). Those are the minimum assumed deliverables. Naturally, projects may do more if they have desire or reason to, but the goal is to allow adopters an extended "transition" period to 4.x, if needed, where things will still work, in some form, using 3.8 based prereqs. For projects that do have "two deliverables", the 3.8 based one would be available on their own download sites and their own project's software site repositories, not the common repository.
  
 
=== Assumptions ===
 
=== Assumptions ===

Revision as of 12:13, 5 April 2011

Introduction and Introductions

This is one of our regularly scheduled "first Wednesday" monthly meetings.


Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, April 06, 2011, at 1200 Eastern
Dial-in: For the call-in numbers, see the "Project Review" number on Foundation Portal page.

Members and Attendees

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC)
John Arthorne Eclipse (PMC)
Oliver Cole Tptp (PMC)  ?
Mik Kersten Mylyn (ALM) PMC
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC)
Adrian Mos SOA (PMC)
Ed Merks Modeling (PMC)
Thomas Watson Rt (PMC)
David Williams WTP (PMC) (appointed Chair)
Gary Xue Birt (PMC)
Strategic Reps
Cedric Brun OBEO (Strategic Developer)
Stefan Daume Cloudsmith Inc.(Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Kaloyan Raev SAP AG (Strategic Developer)
Pascal Rapicault Sonatype (Strategic Developer)
Markus Knauer Innoopract (Strategic Developer)
Christian Kurzke Motorola (Strategic Developer)
Achim Loerke BREDEX (Strategic Developer)
Appointed
Wayne Beaton Eclipse Foundation (appointed)
Inactive
[no name] Nokia (Strategic Developer) X
[no name] CA Inc. (Strategic Consumer) X
[no name] 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.

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

Announcements

  • Welcome "new" member Doug Schaefer ... new representative of Tools PMC.

Indigo Status

  • On track for M7?

Name Indigo +1

  • Name that release; Indigo+1. And the winner is ... Juno. Pending EMO Review.

And, as of Tuesday, April 5, it is still "pending review".

Eclipse 4.2 vs. 3.8 for Juno

(See also notes from previous meeting.)

Proposal

For Juno, Eclipse 4.2 will be the primary workbench, but all (participating) projects will support and maintain a 3.8 based deliverable.

'Primary workbench' means Eclipse 4.2 will be the primary workbench that (participating) projects build against, and test, and will be provided in the common repository, and EPP packages. In all cases, "4.2" means "4.2 plus compatibility layer". That is, no one is expected to split streams, use 4.2 workbench "native" or exploit anything specific to 4.2. Of course, projects can if they want to (within the Assumptions, below) but there is no requirement to exploit 4.2 directly and probably better if low level projects do not.

'Support and maintain a 3.8 based deliverables' means that (participating) projects, at a minimum, agree to continue to provide a deliverable that can be used with 3.8 workbench. In most cases, we hope, this is the exact same deliverable used for the 4.2 based deliverable. This would be true for projects that do not use 4.2 specific API and simply rely on the compatibility layer. But for projects that want to exploit something new in 4.2 workbench ... that is split streams and have one specific to the 4.2 workbench prereq ... then they would still be expected to provide something adopters or upstream projects could use for 3.8-based installs. When there are two separate deliverables, the 3.8-based maintenance version might simply be Indigo SR2, at a minimum. But, even then, there might be cases where versions ranges have to be adjusted, or bugs fixed due to changes in 3.8 (since Indigo SR2 will be built and tested with Eclipse 3.7.2). Those are the minimum assumed deliverables. Naturally, projects may do more if they have desire or reason to, but the goal is to allow adopters an extended "transition" period to 4.x, if needed, where things will still work, in some form, using 3.8 based prereqs. For projects that do have "two deliverables", the 3.8 based one would be available on their own download sites and their own project's software site repositories, not the common repository.

Assumptions

While we want to allow projects to split streams, if they need to do so to exploit some new feature in Eclipse 4.x, we assume no "low level" projects introduce split streams that would require all dependent projects above them to also split streams. This could easily lead to "double work" for many people, which is not practical.

Point of no return

We need to follow a process of evaluating this proposal, making sure there are no "blockers" that prevent adopting it as the final plan. We will do this by following this plan for Juno M1, M2, M3, and M4. M4 is mid-December and it will be assumed that is the point of no return. If no blockers or issues are found that prohibit this plan, then it will be considered final after M4, mid-December, 2011 (which is the normal time for the "final plans" for our yearly June releases). This cycle differs from previous cycles, though, since it assumes projects and adopters do plenty of early testing with those early milestones (and/or 3.8 based installs) to make sure it is a valid plan. Typically, many projects will be busy with Indigo maintenance during this same period of time, so it does take some commitment to also do the early Juno work if there are any concerns about following this plan.

Juno Dates

These are our proposed dates for Juno deliverables. They follow same "pattern" as previous years. Any issues? Discussion? If not, the milestone dates will be forthcoming, also following pattern from previous years.

Release: June 27, 2012 (fourth Wednesday)
SR1: September 28, 2012 (fourth Friday)
SR2: February 22, 2013 (fourth Friday)


Next Meeting

  • May 4, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).

Reference

Indigo Requirements
Indigo Wiki page
Planning Council/Helios retrospective
Indigo Simultaneous Release
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO