Jump to: navigation, search

Difference between revisions of "Planning Council/May 04 2011"

(5/4)
 
(Members and Attendees)
 
(9 intermediate revisions by 2 users not shown)
Line 23: Line 23:
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|  
+
| R (can't make it, on airplane)
 
|-
 
|-
 
| John Arthorne  
 
| John Arthorne  
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Oliver Cole  
 
| Oliver Cole  
Line 35: Line 35:
 
| Mik Kersten  
 
| Mik Kersten  
 
| Mylyn (ALM) PMC  
 
| Mylyn (ALM) PMC  
|  
+
| R
 
|-
 
|-
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|  
+
| Y
 
|-
 
|-
 
| Doug Schaefer
 
| Doug Schaefer
 
| Tools (PMC)  
 
| Tools (PMC)  
|
+
| Y
 
|-
 
|-
 
| Adrian Mos  
 
| Adrian Mos  
Line 55: Line 55:
 
| 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 79: Line 79:
 
| Neil Hauge  
 
| Neil Hauge  
 
| Oracle (Strategic Developer)  
 
| Oracle (Strategic Developer)  
|  
+
| R
 
|-
 
|-
 
| Kaloyan Raev  
 
| Kaloyan Raev  
 
| SAP AG (Strategic Developer)  
 
| SAP AG (Strategic Developer)  
|  
+
| Y
 
|-
 
|-
 
| Pascal Rapicault  
 
| Pascal Rapicault  
 
| Sonatype (Strategic Developer)  
 
| Sonatype (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Markus Knauer  
 
| Markus Knauer  
Line 99: Line 99:
 
| Achim Loerke  
 
| Achim Loerke  
 
| BREDEX (Strategic Developer)  
 
| BREDEX (Strategic Developer)  
|
+
| Y
 
|}
 
|}
 
|- ||width="100%" valign="top" ||
 
|- ||width="100%" valign="top" ||
Line 108: Line 108:
 
| Wayne Beaton  
 
| Wayne Beaton  
 
| Eclipse Foundation (appointed)  
 
| Eclipse Foundation (appointed)  
|
+
| R
 
|}
 
|}
 
|  
 
|  
Line 138: Line 138:
 
== Indigo Status  ==
 
== Indigo Status  ==
  
* On track for M7? and beyond?
+
* On track for M7? and beyond?
 +
 
 +
: ''No issues raised''
  
 
== Name Indigo +1  ==
 
== Name Indigo +1  ==
  
* FWIW, "Juno" has passed EMO sanity check/review, so its official.  
+
* FWIW, "Juno" has passed EMO sanity check and review, so its official.
  
== Eclipse 4.2 vs. 3.8 for Juno ==
+
== Juno Release Planning ==
  
We need to come up with a "proposed plan" for Eclipse Projects and members to evaluate. With their feedback, our proposed plan can become our initial plan, and it, in turn, become our final plan.  
+
(See also [[Planning_Council/April_06_2011| notes from previous meeting]].)
  
During this meeting, I'd like to get feedback on this proposal, to see if it is ready to "publish" for further feedback from the community. I realize that many of you will need more detailed meetings with the projects you represent and/or member companies to see if this plan is reasonable. It will help those discussions if there is a concrete proposal.  
+
I've moved "working plan" to [[Juno/Initial_Working_Plan]] for more public readings.
  
(See also [[Planning_Council/March_20_2011#Eclipse_4.2_vs._3.8| notes from previous meeting]].)
+
:''Good discussion with good feedback (positive and constructive), though still not much known in terms of concrete plans of (sub) projects, so would be good to get that, if possible, by June. But, others were quick to point out, probably won't know much about Juno plans for months to come, not by next month.''
  
=== Proposal ===
+
:''Concern was mentioned the proposed plan still reads with a little too much emphasis on 3.8, as though 4.2 wasn't ready yet.''
  
For Juno, Eclipse 4.2 will be the primary workbench, but all (participating) projects will support and maintain a 3.8 based deliverable.  
+
:''Perhaps wording could be improved ... perhaps to change emphasis to "state concrete plans for 3.8 early", supported or not, tested or not, respond to bugs or not, same function or not in both streams, etc., so adopters and downstream projects know what to expect? And to include better wording as to the purpose ... "The Planning Council encourages, as good Eclipse citizens, we should support adopters that can not make the transition completely to 4.x stream yet". Or similar (that is, explicitly, it is not because 4.2 is not ready). ''
  
'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.  
+
:''It was mentioned, that some projects, such as the Platform's JDT, might end up "splitting streams", not even necessarily because of the split workbench, but they might tie down 3.8 as a maintenance-only stream, and put new feature/functions in 4.x only. They haven't decided that yet, just mentioned it as a possibility. [And, if anyone is wondering, the 3.x stream would contain the Java 7 support, since that's largely done already in 3.x stream.] It was pointed out this might have big impact on downstream projects, such as Web Tools ... unclear if downstream projects would have to split streams in such cases, or double-up on testing two version of JDT, as one example, and those downstream projects might have to pick one or the other to focus on (and it might not be 4.x). Put another way, if there is a potential split stream for every project, then the complexity would grow quite large. Maybe too large and complex to cover in our Simultaneous Release Plan? At some point, we might have to say, we as the Planning Council are only concerned with one stream, and only those that want to participate on that stream, ... and any other configuration is outside the scope of Planning Council's yearly release. Just a possibility.''
  
'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.
+
:''It was also mentioned that early testing, of Indigo stream and "a large IBM adopter product" has gone well on 4.x stream so the Platform team has high confidence in compatibility layer.''
  
=== Assumptions ===
+
:''There was, still, a general feeling that "4.2 as primary platform" would be a fine to great plan. More a question of what to do/say about 3.8. The council was reminded that 3.8 was deemed important by some members, not even necessarily for their own stuff, but sometimes there are dependencies or add-on tools that are outside Eclipse and outside members control that they still want to support or work with. I'm not sure we'll ever know concretely the degree of that? And, it is even unclear if that's a theoretical concern, or if there are already specific, known cases?''
 
+
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.
+
 
+
=== Plan roll-out and point of no return ===
+
 
+
We need to follow a process of evaluating this proposal, making sure there are no "blockers" that prevent it becoming our final plan.
+
 
+
The first step will be to "publish" this plan for feedback. If, or once, we agree on wording, I'll send note to cross-project list and remind people to talk to their Planning Council representative if they have comments or suggestions on the plan. We'll incorporate feedback received, from projects, or adopters, in our May meeting and then again in our June meeting. At that point, we'll consider our "proposed plan" to be our "initial plan".
+
 
+
To move from "initial plan" to "final plan", we will simply follow our plan and re-evaluate each milestone of Juno, that is for M1, M2, M3, and M4. Naturally, we expect confidence to grow incrementally each milestone, but M4 (in mid-December) will be assumed to be the point of no return. If no issues are found that prohibit this "4.2 is primary" 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 a little from previous cycles, since it assumes projects and adopters do plenty of early testing with those early milestones (and/or early 3.8 based installs) to make sure it is a valid plan fulfilling their needs. 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 implementing this plan.
+
 
+
=== ''Discussion during meeting'' ===
+
 
+
''It was acknowledge that we don't necessarily know how to tell project the best way to accomplish the goals of "joint support" ... for example, some might want to build against 3.8 to make sure they do not accidentally pull in 4.2 APIs, for example. It (probably) depends on where each project wants to put the focus, but it is mostly up to the project ... that is, we do not want to dictate how to do things, just what the goals are ... but, if we come up with better suggestions, or concrete how-to advise, we should mentor the projects if it would make things easier.''
+
 
+
''It was mentioned that projects '''can''' split streams, without requiring dependent projects to split streams (that is, their API would stay the same). This might increase testing use-cases but would not "double" the work. I'll reword "assumptions".''
+
 
+
''It was mentioned the proposal seems to say "4.2 is primary" but "we discourage taking advantage 4.2's new capabilities". Especially in light of "split streams do not necessarily propagate", I'll reword. ''
+
 
+
''Ed didn't know if "EMF Edit UI" needed to be split stream, or not ... will have to investigate''.
+
 
+
''Mic reports that Mylyn will have to split stream for some of their bundles, since they use UI internals, but this would not effect their APIs, so would not mean adopters, that use Mylyn APIs, would have to split streams.''
+
 
+
''Given that 4.2 is "primary" and used in repository and EPP packages, what is the nature of the "support 3.8" requirement? It would not make sense to say "ok, you can not be in 4.2 based repository, since you do not support 3.8". Hence, 3.8 support is a "should do" ... a strongly suggested should-do. With strong emphasis on "tell us explicitly if you can not". While adopters could always (probably) simply use Helios SR2 based bundles in their adopting project or products ... but,, the expectation would be that any bugs open preventing that kind of use would be accepted as valid. (For examples, if someone has an overly narrow version pre-req version range).''
+
 
+
''Put another way, since 3.8 not used in repo, or EPP packages, it would be hard to know if someone was not maintaining 3.8 compatibility ... would only show up from adopters or users that were "building their own" 3.8 based installs. That might be a reason or advantage of setting up some "test builds" to produce a 3.8 based repository ... even if not "delivered" or formally used, it would spot incompatibility issues early, at least. This would also be a value-add service to those adopters that needed 3.8 based builds, since then there would exist a "specification" of what goes into a 3.8 based build. Hopefully could be done with some sort of "incremental" build files, so only differences would have to be listed. ''
+
 
+
''One request for May or June PC meetings is to list known cases, of who plans to split stream, or knows they'd have to. Many projects should already be known, since preliminary work with 4.1 has been going on.''
+
 
+
''There as a general consensus on the importance of the objectives, that is, the importance of supporting both streams, but at the same time a general feeling that "it sure seems complicated" and is unknown what issues might arise.''
+
  
 
== Juno Dates ==  
 
== 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)
 
:Release: June 27, 2012 (fourth Wednesday)
Line 201: Line 170:
 
:SR2: February 22, 2013 (fourth Friday)
 
:SR2: February 22, 2013 (fourth Friday)
  
''These dates were agreed to. It was pointed out that this is what the community would expect, and since one of the oft mentioned strong points of Eclipse is its predictability, we would want a really important reason to deviate''
+
TODO: compute milestone dates, similar to previous years.
  
 
== Next Meeting  ==
 
== Next Meeting  ==

Latest revision as of 13:17, 4 May 2011

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, May 04, 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) R (can't make it, on airplane)
John Arthorne Eclipse (PMC) Y
Oliver Cole Tptp (PMC) X
Mik Kersten Mylyn (ALM) PMC R
Brian Payton Datatools (PMC) Y
Doug Schaefer Tools (PMC) Y
Adrian Mos SOA (PMC)
Ed Merks Modeling (PMC)
Thomas Watson Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC) Y
Strategic Reps
Cedric Brun OBEO (Strategic Developer)
Stefan Daume Cloudsmith Inc.(Strategic Developer)
Neil Hauge Oracle (Strategic Developer) R
Kaloyan Raev SAP AG (Strategic Developer) Y
Pascal Rapicault Sonatype (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer)
Christian Kurzke Motorola (Strategic Developer)
Achim Loerke BREDEX (Strategic Developer) Y
Appointed
Wayne Beaton Eclipse Foundation (appointed) R
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

  •  ?

Indigo Status

  • On track for M7? and beyond?
No issues raised

Name Indigo +1

  • FWIW, "Juno" has passed EMO sanity check and review, so its official.

Juno Release Planning

(See also notes from previous meeting.)

I've moved "working plan" to Juno/Initial_Working_Plan for more public readings.

Good discussion with good feedback (positive and constructive), though still not much known in terms of concrete plans of (sub) projects, so would be good to get that, if possible, by June. But, others were quick to point out, probably won't know much about Juno plans for months to come, not by next month.
Concern was mentioned the proposed plan still reads with a little too much emphasis on 3.8, as though 4.2 wasn't ready yet.
Perhaps wording could be improved ... perhaps to change emphasis to "state concrete plans for 3.8 early", supported or not, tested or not, respond to bugs or not, same function or not in both streams, etc., so adopters and downstream projects know what to expect? And to include better wording as to the purpose ... "The Planning Council encourages, as good Eclipse citizens, we should support adopters that can not make the transition completely to 4.x stream yet". Or similar (that is, explicitly, it is not because 4.2 is not ready).
It was mentioned, that some projects, such as the Platform's JDT, might end up "splitting streams", not even necessarily because of the split workbench, but they might tie down 3.8 as a maintenance-only stream, and put new feature/functions in 4.x only. They haven't decided that yet, just mentioned it as a possibility. [And, if anyone is wondering, the 3.x stream would contain the Java 7 support, since that's largely done already in 3.x stream.] It was pointed out this might have big impact on downstream projects, such as Web Tools ... unclear if downstream projects would have to split streams in such cases, or double-up on testing two version of JDT, as one example, and those downstream projects might have to pick one or the other to focus on (and it might not be 4.x). Put another way, if there is a potential split stream for every project, then the complexity would grow quite large. Maybe too large and complex to cover in our Simultaneous Release Plan? At some point, we might have to say, we as the Planning Council are only concerned with one stream, and only those that want to participate on that stream, ... and any other configuration is outside the scope of Planning Council's yearly release. Just a possibility.
It was also mentioned that early testing, of Indigo stream and "a large IBM adopter product" has gone well on 4.x stream so the Platform team has high confidence in compatibility layer.
There was, still, a general feeling that "4.2 as primary platform" would be a fine to great plan. More a question of what to do/say about 3.8. The council was reminded that 3.8 was deemed important by some members, not even necessarily for their own stuff, but sometimes there are dependencies or add-on tools that are outside Eclipse and outside members control that they still want to support or work with. I'm not sure we'll ever know concretely the degree of that? And, it is even unclear if that's a theoretical concern, or if there are already specific, known cases?

Juno Dates

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

TODO: compute milestone dates, similar to previous years.

Next Meeting

  • June 1, 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