Jump to: navigation, search

Difference between revisions of "Planning Council/October 03 2012"

(Juno)
(Juno)
Line 168: Line 168:
  
 
: ''The PC discussed, and decided, that we would not like to see 2 EPP packages provided from Eclipse Foundation, and below I've tried to capture the main points of discussion.''
 
: ''The PC discussed, and decided, that we would not like to see 2 EPP packages provided from Eclipse Foundation, and below I've tried to capture the main points of discussion.''
:*''The primary reason is that the 4.x stream is the strategic direction. That is what we want to encourage people to use and at least for many people, it works fine, if not great. We, the PC, and Eclipse project, are committed to improving that 4.x stream, particularly the performance problems that effects some users and use cases to the point they consider it unusable. We recognize that's terrible, if people feel they can not productively use it, but we don't feel in the big picture of things it is so dire that we must "back peddle". Better to make 4.x better.''
+
:*''The primary reason is that the 4.x stream is the strategic direction. That is what we want to encourage people to use and at least for many people, it works fine, if not great. We, the PC, and Eclipse project, are committed to improving that 4.x stream, particularly the performance problems that effects some users and use cases to the point they consider it unusable. We recognize that's terrible, if people feel they can not productively use it, but we don't feel in the big picture of things it is so dire that we must "back peddle" or provide extra packages. Better to focus on making 4.x better.''
 
:* ''Would give confusing message to community, and seems a little ill-timed. Kepler will be out before you know it. That is, seems a short term solution for (hopefully!) a short term problem.''  
 
:* ''Would give confusing message to community, and seems a little ill-timed. Kepler will be out before you know it. That is, seems a short term solution for (hopefully!) a short term problem.''  
:* ''Also mentioned that we (the Planning Council or Eclipse Foundation) are not really in the "packaging business". Yes, we do want to make things easier for users to "get started", but many companies package all sorts of distributions, based on 3.8, 3.7, 3.6, etc., and let users/companies get what they want ... and many are quite happy staying on 3.6 or what ever ... but, ease-of-use is not our (Planning Council's) only goal ... we primarily want to get Eclipse projects coordinated and headed in the same strategic direction. We are sympathetic to those that like the convenience of getting one download with everything they want, but we want our focus to be on the strategic direction.''
+
:* ''Also mentioned that we (the Planning Council or Eclipse Foundation) are not really in the "packaging business". Yes, we do want to make things easier for users to "get started", but many companies package all sorts of distributions, based on 3.8, 3.7, 3.6, etc., and let users/companies get exactly what they want ... and many are quite happy staying on 3.6 or what ever ... but, ease-of-use is not our (Planning Council's) only goal ... we primarily want to get Eclipse projects coordinated and headed in the same strategic direction. We are sympathetic to those that like the convenience of getting one download with everything they want, but we want to encourage focus on the strategic direction.''
 
:* ''Technically, 3.8 is not "part of Juno". Each project decides what it wants to contribute and the Eclipse Project PMC choose 4.2. While, technically, there is no rule against EPP producing what ever kind of packages it wants to (3.8, 3.7, 3.6, etc.), their role to date has been to draw from the (strategic) common repo and create packages from that. Even if they did produce different packages, it would still be up to us (the Eclipse Foundation) to decide what to put on main "download page". ''
 
:* ''Technically, 3.8 is not "part of Juno". Each project decides what it wants to contribute and the Eclipse Project PMC choose 4.2. While, technically, there is no rule against EPP producing what ever kind of packages it wants to (3.8, 3.7, 3.6, etc.), their role to date has been to draw from the (strategic) common repo and create packages from that. Even if they did produce different packages, it would still be up to us (the Eclipse Foundation) to decide what to put on main "download page". ''
:* ''I should note, that technically, it would not be a huge amount of work to mechanically crank out more packages, but there is a lot of "corollary" work needed to test, track bugs, sort through issues ... and, its hard to know, what surprising things might be found if not well planned, coordinated, and tested ahead of time. In other words, there would be risks and unknowns in providing more packages.''
+
:* ''I should note, that technically, it would not be a huge amount of work to mechanically crank out more packages, but there is a lot of "corollary" work needed to test, track bugs, sort through issues ... and, its hard to know, what surprising things might be found if not well planned, coordinated, and tested ahead of time. In other words, there would be risks and unknowns in providing more packages or repos.''
 
:* ''As far as "actions" we (the PC) could take, we didn't have anything too specific, though we should/could probably do a better job of encouraging early testing. Many of the problems being reported are problems the platform team, by itself, would likely never have seen on their own and (in most cases) are having a difficult time reproducing -- though there is no doubt they are real (and very serious) problems for those users experiencing them. We greatly appreciate the community's help in finding ways to reproduce the issues and/or help fix them and/or help test fixes when possible.''  
 
:* ''As far as "actions" we (the PC) could take, we didn't have anything too specific, though we should/could probably do a better job of encouraging early testing. Many of the problems being reported are problems the platform team, by itself, would likely never have seen on their own and (in most cases) are having a difficult time reproducing -- though there is no doubt they are real (and very serious) problems for those users experiencing them. We greatly appreciate the community's help in finding ways to reproduce the issues and/or help fix them and/or help test fixes when possible.''  
:* ''There was one suggestion that the Eclipse Project consider an early SR (before February) if great progress was made. John did share that the Eclipse PMC has discussed that with arguments on both sides ... would distract committers from other work, but they (the PMC) are interested in the idea of "faster release cycle", but think they should be well planned and coordinated, not reactionary to fix particular problem or set of problems. So, while not completely ruled out (I don't think) it sounds very unlikely and should not give anyone a false impression (or "false hope") that there might be an early release. I pointed out that projects are free to release anytime they like, and do not necessarily have to be only at SR1 and SR2 (WTP, Mylyn, and EGit, do it all the time), but it is a larger (PC) discussion if considering new common repo or EPP packages. There is a long standing issue that most EPP packages do not "see" updates (automatically), if EPP itself is not updated. While this is not an unsolvable problem (see {{bug|345503}}) someone would need to solve it, and it would not help in the short term for this particular problem (since a user needs to start off with the right "version" (metadata) for all of its components to be update-able automatically.''
+
:* ''There was one suggestion that the Eclipse Project consider an early SR (before February) if great progress was made. John did share that the Eclipse PMC has discussed that with arguments on both sides ... it would distract committers from other work, but they (the PMC) are interested in the idea of "faster release cycle" (seems many browsers, etc., are doing more of that these days), but they think they should be well planned and coordinated, not reactionary to fix particular problem or set of problems. So, while not completely ruled out (I don't think) it sounds very unlikely and should not give anyone a false impression (or "false hope") that there might be an early release. I pointed out that projects are free to release anytime they like, and do not necessarily have to be only at SR1 and SR2 (WTP, Mylyn, and EGit, do it all the time), but it is a larger (PC) discussion if considering new common repo or EPP packages. There is a long standing issue that most EPP packages do not "see" updates automatically, if EPP itself is not updated. While this is not an unsolvable problem (see {{bug|345503}}) someone would need to solve it, and it would not help in the short term for this particular problem (since a user needs to start off with the right "version" (metadata) for all of its components to be update-able automatically. But, this situation highlights the need for that bug ({{bug|345503}}) to get some attention?''
:* ''I (dw) will update the bug as "won't fix" but emphasize we appreciate the suggestion and community feedback, know that is was well intended, but have decided against it for the strategic reasons mentioned above.''
+
:* ''I (dw) will update the bug ({{bug|389175}}) as "won't fix" but emphasize we appreciate the suggestion and community feedback, know that is was well intended, but have decided against it for the strategic reasons mentioned above.''
  
 
== Kepler ==
 
== Kepler ==

Revision as of 14:23, 3 October 2012

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, October 03, 2012, at 1200 Eastern
Dial in: (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

Phone Numbers:

  • Ottawa (local call in Ottawa) 1-613-454-1403
  • North America (toll free) 1-877-369-7806
  • Germany (local call anywhere in Germany) +49-692-2224-6059
  • France (local call anywhere in France) +33-17-070-8535
  • UK (toll free) 0800-033-7806
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
Participant conference extension: 710 then enter pin 35498
  • SIP clients:
call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC)
John Arthorne Eclipse (PMC) Y
Steffen Pingel Mylyn (ALM) PMC Y
Brian Payton Datatools (PMC) Y
Doug Schaefer Tools (PMC) Y
Marc Dutoo for Adrian Mos SOA (PMC) D
Ed Merks Modeling (PMC)
Ian Bull Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC)
Wayne Beaton Eclipse Foundation (appointed)
Strategic Reps
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer)
Igor Fedorenko Sonatype (Strategic Developer)
Markus Knauer Innoopract (Strategic Developer)
Achim Loerke BREDEX (Strategic Developer)
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
Inactive
[no name] CA Inc. (Strategic Consumer) X

Note: "Inactive" refers to Strategic Members or PMCs we have not heard from for a while, 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
D = delegated
X = not expected

Announcements

  •  ?

Juno

  • SR1 out and on time. Thanks!
Well, sort of. "Updates" of EPP packages had to be disabled, due to a bug for Mac users, where the update operation would delete the eclipse.ini file.
Looks like solution nearly in hand and (I'm assuming) EPP will need to respin at least EPP repo (but, we should not have to respin common repo).
Unsure of plans (or recommendations) for re-spinning EPP downloadable packages. They are essentially correct, but (I think) if not re-created then those that unzip an SR1 package will immediately be offered an update (that basically does nothing ... just a few IU versions change). I don't think that'd be so bad ... but ... the final call is up to EPP (i.e Markus).
The surprising thing is that this problem was not noticed during testing. Guess no one well tests EPP updates on Mac's?
Will leave up to Markus to decide if to respin/replace downloadable packages. PC would be fine either way
We should encourage more/better early testing, somehow ... better enlist community?
Ian pointed out we need to test the case where someone has already had their eclipse.ini file removed ... would they get the "update" and get the eclipse.ini restored? Or, maybe not, since no artifacts actually installed? Just a reminder to test that.
  • Issue "in community" about having two streams of EPP builds. See bug 389175.
The goal in our meeting to decide what action to take and/or how to respond in the bug.
In mailing list, Ian provided these references to the issue, which I wanted to paste in here, to make sure easy to find.
http://mmilinkov.wordpress.com/2012/09/10/juno-performance/
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg08120.html
http://www.jroller.com/andyl/entry/something_is_really_broken_with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272
https://bugs.eclipse.org/bugs/show_bug.cgi?id=389175
https://bugs.eclipse.org/bugs/show_bug.cgi?id=389215
Another reference to follow: Platform_UI/Juno_Performance_Investigation.
The PC discussed, and decided, that we would not like to see 2 EPP packages provided from Eclipse Foundation, and below I've tried to capture the main points of discussion.
  • The primary reason is that the 4.x stream is the strategic direction. That is what we want to encourage people to use and at least for many people, it works fine, if not great. We, the PC, and Eclipse project, are committed to improving that 4.x stream, particularly the performance problems that effects some users and use cases to the point they consider it unusable. We recognize that's terrible, if people feel they can not productively use it, but we don't feel in the big picture of things it is so dire that we must "back peddle" or provide extra packages. Better to focus on making 4.x better.
  • Would give confusing message to community, and seems a little ill-timed. Kepler will be out before you know it. That is, seems a short term solution for (hopefully!) a short term problem.
  • Also mentioned that we (the Planning Council or Eclipse Foundation) are not really in the "packaging business". Yes, we do want to make things easier for users to "get started", but many companies package all sorts of distributions, based on 3.8, 3.7, 3.6, etc., and let users/companies get exactly what they want ... and many are quite happy staying on 3.6 or what ever ... but, ease-of-use is not our (Planning Council's) only goal ... we primarily want to get Eclipse projects coordinated and headed in the same strategic direction. We are sympathetic to those that like the convenience of getting one download with everything they want, but we want to encourage focus on the strategic direction.
  • Technically, 3.8 is not "part of Juno". Each project decides what it wants to contribute and the Eclipse Project PMC choose 4.2. While, technically, there is no rule against EPP producing what ever kind of packages it wants to (3.8, 3.7, 3.6, etc.), their role to date has been to draw from the (strategic) common repo and create packages from that. Even if they did produce different packages, it would still be up to us (the Eclipse Foundation) to decide what to put on main "download page".
  • I should note, that technically, it would not be a huge amount of work to mechanically crank out more packages, but there is a lot of "corollary" work needed to test, track bugs, sort through issues ... and, its hard to know, what surprising things might be found if not well planned, coordinated, and tested ahead of time. In other words, there would be risks and unknowns in providing more packages or repos.
  • As far as "actions" we (the PC) could take, we didn't have anything too specific, though we should/could probably do a better job of encouraging early testing. Many of the problems being reported are problems the platform team, by itself, would likely never have seen on their own and (in most cases) are having a difficult time reproducing -- though there is no doubt they are real (and very serious) problems for those users experiencing them. We greatly appreciate the community's help in finding ways to reproduce the issues and/or help fix them and/or help test fixes when possible.
  • There was one suggestion that the Eclipse Project consider an early SR (before February) if great progress was made. John did share that the Eclipse PMC has discussed that with arguments on both sides ... it would distract committers from other work, but they (the PMC) are interested in the idea of "faster release cycle" (seems many browsers, etc., are doing more of that these days), but they think they should be well planned and coordinated, not reactionary to fix particular problem or set of problems. So, while not completely ruled out (I don't think) it sounds very unlikely and should not give anyone a false impression (or "false hope") that there might be an early release. I pointed out that projects are free to release anytime they like, and do not necessarily have to be only at SR1 and SR2 (WTP, Mylyn, and EGit, do it all the time), but it is a larger (PC) discussion if considering new common repo or EPP packages. There is a long standing issue that most EPP packages do not "see" updates automatically, if EPP itself is not updated. While this is not an unsolvable problem (see bug 345503) someone would need to solve it, and it would not help in the short term for this particular problem (since a user needs to start off with the right "version" (metadata) for all of its components to be update-able automatically. But, this situation highlights the need for that bug (bug 345503) to get some attention?
  • I (dw) will update the bug (bug 389175) as "won't fix" but emphasize we appreciate the suggestion and community feedback, know that is was well intended, but have decided against it for the strategic reasons mentioned above.

Kepler

Kepler Requirements Planning

Begin discussion of requirements, if changes needed. To the extent possible, I suggest we start with high level issues this month (such as, should any be added, removed?) and perhaps finish up with wording changes for clarification (if any) next month.
Didn't discuss much. I brought up issue of low compliance to "greediness" issue, and as far as I know, to define everything in features is the only way for adopters to provide patches ... so ... either I need education, or better educate others on why important? Or ... maybe others don't need patches? What's alternative? New release? (which, adopters can not do "on their own", typically, such as for a "hot fix" for one customer).

Other Business

Next Meeting

  • November 7, 2012 (our regular "first Wednesday" meeting, at Noon Eastern).


Reference

Kepler Wiki page
Juno Wiki page
Planning Council/Indigo retrospective
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO