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/March 20 2011"

(Inactive)
(Eclipse 4.2 vs. 3.8)
 
(37 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Introduction and Introductions ==  
+
== Introduction and Introductions ==
  
 +
This is our annual, traditional EclipseCon Face-Face Meetings, Sunday, March 20, At Hyatt, Napa Room.
  
This is our annual, traditional EclipseCon Face-Face Meetings, Sunday, March 20, At Hyatt, Napa Room.
+
::3-4 (Pacific Time) PC face-to-face meeting, followed by
::3-4 (Pacific Time) PC face-to-face meeting  
+
 
::4-5 (Pacific Time) Joint Councils Meeting (See [http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01858.html Donald's note to list]).
 
::4-5 (Pacific Time) Joint Councils Meeting (See [http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01858.html Donald's note to list]).
  
== Logistics ==
+
== Logistics ==
  
 
{| cellspacing="0" cellpadding="4" border="1"
 
{| cellspacing="0" cellpadding="4" border="1"
Line 16: Line 16:
 
| Wednesday, March 20, 2011, at [http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=03&day=20&hour=19&min=0&sec=0&p1=179 3:00 PMC Pacific time. Napa Room]
 
| Wednesday, March 20, 2011, at [http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=03&day=20&hour=19&min=0&sec=0&p1=179 3:00 PMC Pacific time. Napa Room]
 
|-
 
|-
| <del>Dial-in: </del> No dial in.
+
| <del>Dial-in: </del> No dial in.  
| <del>For the call-in numbers, see the "Project Review" number on [https://dev.eclipse.org/portal/myfoundation/portal/portal.php Foundation Portal] page.</del>  
+
| <del>For the call-in numbers, see the "Project Review" number on [https://dev.eclipse.org/portal/myfoundation/portal/portal.php Foundation Portal] page.</del>
 
|}
 
|}
  
== Attendees  ==
+
== Members and Attendees  ==
  
{| cellpadding="15" border="0"
+
{| width="90%" cellspacing="15" cellpadding="5" border="0" align="center"
|- valign="top"
+
|- ||width="100%" valign="top" ||
| width="30%" |
+
|
PMC (and Strategic) Reps  
+
{| width="100%" cellspacing="1" cellpadding="1" border="1" align="top"
 
+
|+ '''PMC (and Strategic) Reps'''
{| border="1"
+
 
|-
 
|-
 
| Chris Aniszczyk  
 
| Chris Aniszczyk  
 
| Technology (PMC)  
 
| Technology (PMC)  
|
+
| ?
 
|-
 
|-
| John Arthorne
+
| John Arthorne  
 
| Eclipse (PMC)  
 
| Eclipse (PMC)  
|
+
| Y
 
|-
 
|-
 
| Oliver Cole  
 
| Oliver Cole  
 
| Tptp (PMC)  
 
| Tptp (PMC)  
| X  
+
| X
 
|-
 
|-
| Mik Kersten
+
| Mik Kersten  
| Mylyn (ALM) PMC
+
| Mylyn (ALM) PMC  
|  
+
| ?
 
|-
 
|-
 
| Brian Payton  
 
| Brian Payton  
 
| Datatools (PMC)  
 
| Datatools (PMC)  
|
+
| ?
 
|-
 
|-
 
| Anthony Hunter  
 
| Anthony Hunter  
 
| Tools (PMC)  
 
| Tools (PMC)  
|
+
| R
 
|-
 
|-
 
| Adrian Mos  
 
| Adrian Mos  
 
| SOA (PMC)  
 
| SOA (PMC)  
|
+
| ?
 
|-
 
|-
 
| Ed Merks  
 
| Ed Merks  
 
| Modeling (PMC)  
 
| Modeling (PMC)  
|
+
| ?
 
|-
 
|-
 
| Thomas Watson  
 
| Thomas Watson  
 
| Rt (PMC)  
 
| Rt (PMC)  
|
+
| ?
 
|-
 
|-
 
| David Williams  
 
| David Williams  
 
| WTP (PMC) (appointed Chair)  
 
| WTP (PMC) (appointed Chair)  
|
+
| Y
 
|-
 
|-
 
| Gary Xue  
 
| Gary Xue  
 
| Birt (PMC)  
 
| Birt (PMC)  
|
+
| Y
 
|}
 
|}
 
+
|
Strategic Reps
+
{| width="100%" cellspacing="1" cellpadding="1" border="1" align="top"
 
+
|+ '''Strategic Reps'''
{| width="30%" border="1"
+
 
|-
 
|-
 
| Cedric Brun  
 
| Cedric Brun  
 
| OBEO (Strategic Developer)  
 
| OBEO (Strategic Developer)  
|
+
| ?
 
|-
 
|-
 
| Stefan Daume  
 
| Stefan Daume  
 
| Cloudsmith Inc.(Strategic Developer)  
 
| Cloudsmith Inc.(Strategic Developer)  
|
+
| ?
|-  
+
|-
 
| 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  
 
| Sonatype (Strategic Developer)  
 
| Sonatype (Strategic Developer)  
|
+
| Y
 
|-
 
|-
| Markus Knauer
+
| Markus Knauer  
 
| Innoopract (Strategic Developer)  
 
| Innoopract (Strategic Developer)  
|
+
| Y
 
|-
 
|-
 
| Christian Kurzke  
 
| Christian Kurzke  
 
| Motorola (Strategic Developer)  
 
| Motorola (Strategic Developer)  
|
+
| ?
 
|-
 
|-
| Achim Loerke
+
| Achim Loerke  
| BREDEX (Strategic Developer)
+
| BREDEX (Strategic Developer)  
|
+
| Y
 
|}
 
|}
 
+
|- ||width="100%" valign="top" ||
Appointed
+
|
 
+
{| width="100%" cellspacing="1" cellpadding="1" border="1" align="top"
{| width="30%" border="1"
+
|+ '''Appointed'''
 
|-
 
|-
 
| Wayne Beaton  
 
| Wayne Beaton  
 
| Eclipse Foundation (appointed)  
 
| Eclipse Foundation (appointed)  
|
+
| Y
 
|}
 
|}
 
+
|  
<br><small>Note: feel free to correct any errors/omissions in above attendance record.</small><br><small>Y = Yes, attended</small><br><small>N = No, did not</small><br><small>R = regrets sent ahead of time</small><br><small>X = not expected</small>
+
{| width="100%" cellspacing="1" cellpadding="1" border="1" align="top"
 
+
|+ '''Inactive'''
|}
+
 
+
== Inactive  ==
+
 
+
{| cellpadding="15" border="0"
+
|- valign="top"
+
| width="30%" |
+
{| border="1"
+
 
|-
 
|-
| &nbsp;?
+
| [no name]
 
| Nokia (Strategic Developer)  
 
| Nokia (Strategic Developer)  
 
| X
 
| X
 
|-
 
|-
| &nbsp;?
+
| [no name]
 
| CA Inc. (Strategic Consumer)  
 
| CA Inc. (Strategic Consumer)  
 
| X
 
| X
 
|-
 
|-
| &nbsp;?
+
| [no name]
 
| brox IT-Solutions GmbH (Strategic Developer)  
 
| brox IT-Solutions GmbH (Strategic Developer)  
| X
+
| X  
 +
|}
 
|}
 
|}
  
<br><small>Note: "Inactive" refers to [http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic 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.</small>  
+
<small>Note: "Inactive" refers to [http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic 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.</small>  
  
|}
+
<small>Note: feel free to correct any errors/omissions in above attendance record.</small><br/><small>Y = Yes, attended</small><br/><small>N = No, did not</small><br/><small>R = regrets sent ahead of time</small><br/><small>X = not expected</small>
 +
 
 +
== Announcements  ==
 +
 
 +
*&nbsp;?
 +
 
 +
== Indigo Status  ==
 +
 
 +
* M6a repo and packages? See {{bug|340016}} and {{bug|340462}}
 +
 
 +
== Name Indigo +1  ==
 +
 
 +
* Name that release; Indigo+1. And [http://www.eclipse.org/indigo/planning/poll2012name.php the winner is] ... ''Juno. Pending EMO Review.''
 +
 
 +
We'll examine process, votes, be sure there is a clear winner, and that the winner is not objectionable in some way we didn't think of before. Remember, once we decide the name, it will still have to be "vetted" by Ian/Mike/Janet to make sure there would be no trademark infringement, etc. Is is very unlikely ("no chance") this vetting will be done before/during EclipseCon ... so we can "announce" our choice, but with the caveat "pending final EMO reviews".
 +
 
 +
(Greatest thanks, Pascal!)
 +
 
 +
== CVS and GIT ==
 +
 
 +
* Status, plans, and urgency of moving from CVS to GIT. Why it is required, again? (Denis, Wayne?)
 +
 
 +
''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.)''
 +
 
 +
''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?)''
 +
 
 +
''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?''
 +
 
 +
== Misc. References ==
 +
 
 +
* Any discussion of these documents ...
 +
 
 +
:*[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.
 +
 
 +
:*[http://wiki.eclipse.org/RequirementsCouncilThemesAndPriorities| Themes and Priorities]. (Again, here for reference, may be discussed at joint meeting.)
 +
 
 +
''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.''
 +
 
 +
== Eclipse 4.2 vs. 3.8  ==
 +
 
 +
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]?
 +
 
 +
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?
  
<br>
+
''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.''
  
== Announcements ==
+
''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.).''
  
* ?
+
''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.''
  
== Indigo Status ==
+
''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"?''
  
* ?
+
== Long Term Planning discussion  ==
  
== Other business  ==
+
''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''.
  
* Name that release; Indigo+1. We'll examine votes, and be sure there is a clear winner, and that the winner is not objectionable in some way we didn't think of before. Remember, once we come up with the name, it will have to be "vetted" by Ian/Mike to make sure there would be no trademark infringement, etc. (They might be able to do this "in days", before EclipseCon is over ... but not sure.) (Pascal?)
+
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.  
  
* Status, plans, and urgency of moving from CVS to GIT. Why it is required, again? (Denis), Wayne?)
+
*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:
 +
:* 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 ...?  
  
* [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, I believe, if I understand the dates ... board review is next day.
+
*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?
  
* [http://wiki.eclipse.org/RequirementsCouncilThemesAndPriorities| Themes and Priorities]. (Again, here for reference, may be discussed at joint meeting.)
+
*Should we have "must do" items at all? Or, are they just recommendations?
  
== Long Term Planning discussion ==
+
*Are the requirements about right? Too many? Too few?
  
* EclipseCon face-to-face is good time to discuss high level, long term issues. The following items are along the lines of "brainstorming" agenda items ... please add any of yours.
+
*Should we have requirement related to bug fix rate? Backlog reduction? unit test coverage?
  
: Are requirements/tracking worthwhile? Working? Anything better?  
+
*How's the aggregation process? Would it be fair to ask for zipped p2 repositories for aggregation input?  
  
: Is yearly release (with two service releases) right interval? Quarterly? Every other year? LTS releases?
+
*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).
  
: Next year, should 3.8 be primary platform, still ... or 4.2 be primary, but still "support" 3.8 as secondary?
+
*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?
  
== Next Meeting ==
+
*Terminology improvements:
 +
:* "Tracker" --> "Checklist"?
 +
:* "Exceptions" --> "Deviations"?
  
 +
== Next Meeting  ==
  
* April 6, 2011 (regular "first Wednesday" meeting.
+
*April 6, 2011 (our regular "first Wednesday" meeting, at Noon Eastern).
  
 
== Reference  ==
 
== Reference  ==
  
:[http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php Indigo Requirements]  
+
:[http://www.eclipse.org/indigo/planning/EclipseSimultaneousRelease.php Indigo Requirements]
  
:[[indigo| Indigo Wiki page]]
+
:[[Indigo|Indigo Wiki page]]
  
:[[Planning_Council/Helios_retrospective]]
+
:[[Planning Council/Helios retrospective]]
  
:[[Indigo/Simultaneous_Release_Plan| Indigo Simultaneous Release]]  
+
:[[Indigo/Simultaneous Release Plan|Indigo Simultaneous Release]]
  
:[http://www.eclipse.org/org/foundation/council.php#planning Planning Council Members]  
+
:[http://www.eclipse.org/org/foundation/council.php#planning Planning Council Members]
  
 
:[[Simultaneous Release Roles]] and [[Simultaneous Release Roles/EMO]]
 
:[[Simultaneous Release Roles]] and [[Simultaneous Release Roles/EMO]]

Latest revision as of 02:58, 21 March 2011

Introduction and Introductions

This is our annual, traditional EclipseCon Face-Face Meetings, Sunday, March 20, At Hyatt, Napa Room.

3-4 (Pacific Time) PC face-to-face meeting, followed by
4-5 (Pacific Time) Joint Councils Meeting (See Donald's note to list).

Logistics

Meeting Title: Planning Council EclipseCon face-to-face meeting
Date & Time: Wednesday, March 20, 2011, at 3:00 PMC Pacific time. Napa Room
Dial-in: No 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) Y
Oliver Cole Tptp (PMC) X
Mik Kersten Mylyn (ALM) PMC  ?
Brian Payton Datatools (PMC)  ?
Anthony Hunter Tools (PMC) R
Adrian Mos SOA (PMC)  ?
Ed Merks Modeling (PMC)  ?
Thomas Watson Rt (PMC)  ?
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) Y
Kaloyan Raev SAP AG (Strategic Developer) Y
Pascal Rapicault Sonatype (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer) Y
Christian Kurzke Motorola (Strategic Developer)  ?
Achim Loerke BREDEX (Strategic Developer) Y
Appointed
Wayne Beaton Eclipse Foundation (appointed) Y
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

Name Indigo +1

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

We'll examine process, votes, be sure there is a clear winner, and that the winner is not objectionable in some way we didn't think of before. Remember, once we decide the name, it will still have to be "vetted" by Ian/Mike/Janet to make sure there would be no trademark infringement, etc. Is is very unlikely ("no chance") this vetting will be done before/during EclipseCon ... so we can "announce" our choice, but with the caveat "pending final EMO reviews".

(Greatest thanks, Pascal!)

CVS and GIT

  • Status, plans, and urgency of moving from CVS to GIT. Why it is required, again? (Denis, Wayne?)

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.)

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?)

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?

Misc. References

  • Any discussion of these documents ...
  • V6 of the Eclipse Road Map ... mostly here for reference. Any feedback should have already been given ... board review is next day.

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.

Eclipse 4.2 vs. 3.8

Next year, what's primary, what's secondary? Do we buy-in to the Eclipse Project's (implied) proposal?

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?

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.

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.).

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 mentioned, that some thought the "message" needs work ... that the details in cross project note sounded "scary"?

Long Term Planning discussion

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.

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.

  • Review our Mission and recent retrospectives. In addition to the formal, documented mission, several other motivations tend to influence our efforts:
  • 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?
  • Should we have "must do" items at all? Or, are they just recommendations?
  • Are the requirements about right? Too many? Too few?
  • Should we have requirement related to bug fix rate? Backlog reduction? unit test coverage?
  • 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:
  • "Tracker" --> "Checklist"?
  • "Exceptions" --> "Deviations"?

Next Meeting

  • April 6, 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

Copyright © Eclipse Foundation, Inc. All Rights Reserved.