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

From Eclipsepedia

Jump to: navigation, search
(Juno Dates)
(Plan roll-out and point of no return)
 
(15 intermediate revisions by one user not shown)
Line 1: Line 1:
== Introduction and Introductions  ==
 
 
This is one of our regularly scheduled "first Wednesday" monthly meetings.
 
 
 
 
== Logistics ==
 
== Logistics ==
  
Line 28: Line 23:
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|
+
| Y
 
|-
 
|-
 
| John Arthorne  
 
| John Arthorne  
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|
+
| R
 
|-
 
|-
 
| Oliver Cole  
 
| Oliver Cole  
 
| Tptp (PMC)  
 
| Tptp (PMC)  
|
+
| X
 
|-
 
|-
 
| Mik Kersten  
 
| Mik Kersten  
 
| Mylyn (ALM) PMC  
 
| Mylyn (ALM) PMC  
|
+
| Y
 
|-
 
|-
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|
+
| Y
 
|-
 
|-
 
| Doug Schaefer
 
| Doug Schaefer
Line 56: Line 51:
 
| 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  
Line 84: Line 79:
 
| Neil Hauge  
 
| Neil Hauge  
 
| Oracle (Strategic Developer)  
 
| Oracle (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Kaloyan Raev  
 
| Kaloyan Raev  
 
| SAP AG (Strategic Developer)  
 
| SAP AG (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Pascal Rapicault  
 
| Pascal Rapicault  
Line 104: Line 99:
 
| Achim Loerke  
 
| Achim Loerke  
 
| BREDEX (Strategic Developer)  
 
| BREDEX (Strategic Developer)  
|
+
| Y
 
|}
 
|}
 
|- ||width="100%" valign="top" ||
 
|- ||width="100%" valign="top" ||
Line 139: Line 134:
 
== Announcements  ==
 
== Announcements  ==
  
* Welcome "new" member Doug Schaefer, at least new representative of Tools PMC.  
+
* Welcome "new" member Doug Schaefer ... new representative of Tools PMC.
  
 
== Indigo Status  ==
 
== Indigo Status  ==
Line 149: Line 144:
 
* Name that release; Indigo+1. And [http://www.eclipse.org/indigo/planning/poll2012name.php the winner is] ... ''Juno. Pending EMO Review.''
 
* Name that release; Indigo+1. And [http://www.eclipse.org/indigo/planning/poll2012name.php the winner is] ... ''Juno. Pending EMO Review.''
  
And, as of Tuesday, April 5, it is still "pending review".  
+
: And, as of Tuesday, April 5, it is still "pending review".
  
== CVS and GIT ==
+
== Eclipse 4.2 vs. 3.8 for Juno ==
  
* Status, plans, and urgency of moving from CVS to GIT. Why it is required, again? (Denis, Wayne?)
+
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.
  
''Wayne presented the current plan. After Indigo, begin to more actively move projects to GIT. Assuming, EGit 1.0, released with Indigo, will be "good enough" to support Eclipse Committers. By Fall 2012 (after Juno) "turn off" CVS. Primary reason is that CVS is no longer actively supported; no new releases planned. That is partially because it is so stable, but it also means if an important bug or security vulnerability was desired to be fixed, we'd be "on our own" ... have to patch and rebuild ourselves. [Wayne says Denis can point us at some bugs of concern]. Less tangible reasons involve simply moving to what people want, what's modern, easier to use, especially for "new comers". While there's some concern about having just one "solution" that everyone has to use, there's some benefit to using just one repo at Eclipse, since then if users learn how to use one project at Eclipse, provide patch, etc., then they could more easily do so for another project, if same repo used by the projects. [There is so proposal to "turn off" SVN, but, not widely used.] It was also mentioned that one goal is to "save IT effort" but a) not clear how much effort CVS takes, and b) its not clear CVS can literally be turned off, or even made "read only" (since many projects need ability to do patch builds, etc., on old system with old code). It is a different impact if literally turned off, done away with, since then some long established projects would have to figure out how to replicate old builds with new repository. Unclear how much effort that would take. (Or, an alternative is that companies/committers that need to do a patch build, can simply do on their own systems, duplicating the cvs repos, etc., but that has obvious disadvantages too.)''
+
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.  
  
''Some issues with GIT were briefly mentioned: a) it is still not clear what the right granularity is for a repo (that is, no one even knows what to recommend as a best practice). b) some delay in using Gerrit at Eclipse, c) some confusion about if contributors can supply a patch to bugzilla, or simply supply a reference link to a another repo that has the updated code committed to it (Wayne said he thought he'd sent a not clarifying that, perhaps only to Architecture list?)''
+
(See also [[Planning_Council/March_20_2011#Eclipse_4.2_vs._3.8| notes from previous meeting]].)
  
''Would moving to GIT after Indigo mean some projects are doing Indigo maintenance from CVS? And Juno from GIT? Or, would Indigo maintenance be moved to GIT as well? If CVS and GIT, it would be lots more work for committers to keep streams in sync ... is there anything that could be done to improve this?''
+
=== Proposal ===
  
== Misc. References ==
+
For Juno, Eclipse 4.2 will be the primary workbench, but all (participating) projects will support and maintain a 3.8 based deliverable.  
  
* Any discussion of these documents ...  
+
'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.  
  
:*[http://www.eclipse.org/org/councils/roadmap_v6_0/| V6 of the Eclipse Road Map] ... mostly here for reference. Any feedback should have already been given ... board review is next day.
+
'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.
  
:*[http://wiki.eclipse.org/RequirementsCouncilThemesAndPriorities| Themes and Priorities]. (Again, here for reference, may be discussed at joint meeting.)
+
=== Assumptions ===
  
''These specific documents were not discussed, but the general issue of "inadequate plans" was mentioned ... that is, some projects have no plans, essentially ... so some attention, changes or improvement in process may be needed in future. It was mentioned (in following, joint meeting, that plans would always be required, that they were an essential part of being "open", and "transparent". Also from joint meeting, if bylaws changed as expected, and no longer a req. council, then in addition to "plans" projects may be expected to name their own themes and priorities.''
+
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.  
  
== Eclipse 4.2 vs. 3.8  ==
+
=== Plan roll-out and point of no return ===  
  
Next year, what's primary, what's secondary? Do we buy-in to the [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05597.html Eclipse Project's (implied) proposal]?
+
We need to follow a process of evaluating this proposal, making sure there are no "blockers" that prevent it becoming our final plan.  
  
How important is it to your project or to your strategic member company, that you represent, to use Eclipse 3.8 or Eclipse 4.2 as primary? Think of it on a 10 point scale (for discussion):  1 is very important to stay on 3.8 as primary, 5 is don't care, happy to go along with what others want/need, and 10 is very important to use 4.2 as the primary?
+
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".  
  
''There was a general sense that if 4.x was ever going to be "real", we needed to make it primary. One project (besides Platform) was looking forward to it, and has (loose, informal) plans to exploit it, once primary. One member expressed concerned that since they depend on bundles/tools/add-ins that are not part of Eclipse (and not part of their company) that they have no control over ... so they might need to be on 3.x for that reason, and they wondered if we could have "both streams be primary". This wasn't thought to be realistic, since means "double the work" for everyone (to test both, if nothing else) but it was acknowledged that 3.x would remain to be very important. This called for a definition of "primary": a) EPP packages are built with it; b) projects build and test with it. It was mentioned that 4.x may not be getting much use by general population of Eclipse IDE users since most simply download EPP Packages.''
+
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.
  
''While no final decision was made, my impression (or proposal) is that the plan should be to have 4.x be primary, and go down that path for Juno, unless or until some substantial reason is found not to. This would still allow 3.x to get as much or as little attention as desired, but we would not build EPP packages with it. It was asked, hypothetically, why couldn't we have both streams for EPP packages ... but, general fear was this would be confusing to community/users and more work for committers to "fully" support both, etc.).''
+
=== ''Discussion during meeting'' ===
  
''It was also asked, "when would compatibility layer be removed, or no longer supported", and the answer was "never, it will always be there, always supported". That is, there is no expectation that Projects move to "native" 4.x APIs.''
+
''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 some thought the "message" needs work ... that the details in  [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg05597.html cross project note] sounded "scary"?''
+
''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".''
  
== Juno Dates ==
+
''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. ''
  
These are our proposed dates for Juno deliverables. They follow same "pattern" as previous years. Any issues? Discussion?
+
''Ed didn't know if "EMF Edit UI" needed to be split stream, or not ... will have to investigate''.  
If not, the milestone dates will be forthcoming, also following pattern from previous years.  
+
  
:Release: June 27, 2012 (fourth Wednesday)
+
''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.''
:SR1: September 28, 2012 (fourth Friday)
+
:SR2: February 22, 2013 (fourth Friday)
+
  
== Long Term Planning discussion  ==
+
''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).''
  
''Note to self ... next year allow for two hour meeting :). We did not have time to chat about any of these longer term issues ... and will address them at our regular monthly meetings''.
+
''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. ''  
  
EclipseCon face-to-face is good time to discuss high level or long term issues. The following items are potential items to discuss ... please add any of your own. They can range from a thought or question, to a specific proposal. The purpose of this part of the meeting is not necessarily to decide or resolve any specific issues (there likely would not be time) but to make sure we are all, as a council, in agreement on our general course, what are most important issues to address, etc.  
+
''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.''
  
*Review our [[Planning_Council#Planning_Council_Mission| Mission]] and recent [[Planning_Council/Helios_retrospective| retrospectives]]. In addition to the formal, documented mission, several other motivations tend to influence our efforts:
+
''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.''
:* improve quality and consistency of Eclipse as a whole,
+
:* make things as easy as possible for committers (while meeting other goals),
+
:* improve "value" of Eclipse, by improving what adopters can adopt and providing what strategic members need.
+
:* Others ...?
+
  
*How are we doing? Beside 'being on time' are we achieving the right quality? By helping projects focus on "minimum set" of items that are important for Eclipse as a whole?
+
== Juno Dates ==
  
*Should we have "must do" items at all? Or, are they just recommendations?
+
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.
  
*Are the requirements about right? Too many? Too few?
+
:Release: June 27, 2012 (fourth Wednesday)
 
+
:SR1: September 28, 2012 (fourth Friday)  
*Should we have requirement related to bug fix rate? Backlog reduction? unit test coverage?
+
:SR2: February 22, 2013 (fourth Friday)
 
+
*How's the aggregation process? Would it be fair to ask for zipped p2 repositories for aggregation input?
+
 
+
*Is the release tracking checklist on Portal worthwhile? Should we do away with it? Should we make it better? (Such as, there could be more "auto fill-in" ... such as from other portal data, more "testing" results would provide the main data for forms while projects would provide the documentation for deviations or exceptions).
+
 
+
*Who is the audience(s)? (Projects, PMCs, Planning Council, Adopters).
+
 
+
*Is yearly release (with two service releases) the right interval? Should maintenance be quarterly? Should releases be every other year? Or, perhaps, every other year be a LTS releases with "off" year having less maintenance emphasis?
+
 
+
*Is there too much "pressure" or emphasis that everyone should be part of Simultaneous Release? Or, should it be one of our goals, that every project should be part of the Simultaneous Release? How would we describe or define who should, or who shouldn't?
+
  
*Terminology improvements:
+
''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''
:* "Tracker" --> "Checklist"?
+
:* "Exceptions" --> "Deviations"?
+
  
 
== Next Meeting  ==
 
== Next Meeting  ==

Latest revision as of 13:23, 6 April 2011

Contents

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

[edit] Members and Attendees

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

[edit] Announcements

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

[edit] Indigo Status

  • On track for M7?

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

[edit] Eclipse 4.2 vs. 3.8 for Juno

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.

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.

(See also notes from previous meeting.)

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

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

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

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

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

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

[edit] Next Meeting

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

[edit] Reference

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