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.
Difference between revisions of "Planning Council/October 03 2012"
(→Juno) |
(→Juno) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 42: | Line 42: | ||
| John Arthorne | | John Arthorne | ||
| Eclipse (PMC) | | Eclipse (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| Steffen Pingel | | Steffen Pingel | ||
| Mylyn (ALM) PMC | | Mylyn (ALM) PMC | ||
| − | | | + | | Y |
|- | |- | ||
| Brian Payton | | Brian Payton | ||
| Datatools (PMC) | | Datatools (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| Doug Schaefer | | Doug Schaefer | ||
| Tools (PMC) | | Tools (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| − | | Adrian Mos | + | | Marc Dutoo for <strike>Adrian Mos</strike> |
| SOA (PMC) | | SOA (PMC) | ||
| − | | | + | | D |
|- | |- | ||
| Ed Merks | | Ed Merks | ||
| Line 64: | Line 64: | ||
| | | | ||
|- | |- | ||
| − | | Ian Bull | + | | Ian Bull |
| Rt (PMC) | | Rt (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| David Williams | | David Williams | ||
| WTP (PMC) (appointed Chair) | | WTP (PMC) (appointed Chair) | ||
| − | | | + | | Y |
|- | |- | ||
| Gary Xue | | Gary Xue | ||
| Line 90: | Line 90: | ||
| Neil Hauge | | Neil Hauge | ||
| Oracle (Strategic Developer) | | Oracle (Strategic Developer) | ||
| − | | | + | | Y |
|- | |- | ||
| Kaloyan Raev | | Kaloyan Raev | ||
| Line 138: | Line 138: | ||
* SR1 out and on time. Thanks! | * 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}}. | * 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. | : 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 4.x, 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 == | ||
Latest revision as of 20:26, 3 October 2012
Contents
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:
|
Members and Attendees
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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 4.x, 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).