Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

Eclipse/PMC/Minutes 2009

< Eclipse‎ | PMC

This page contains an archive of Eclipse/PMC meeting minutes for 2009.

Meeting Minutes

Dec 9: - John, Dani, McQ, Martin

Dec 2: - John, Dani, McQ

  • Some discussion about getting good talk coverage at EclipseCon
  • Need to revisit API deprecation policy when we have enough attendees

Nov 25: - John, Dani, McQ

  • No interesting discussion due to lack of attendees

Nov 18: - John, Martin, Dani

  • John: Deadlocks / errors during JDT and CVS tests - deadlocks should be fixed, not sure about other failures.

Nov 11: - Dani, Martin, John, Jeff

  • Nothing to discuss.

Nov 4: - Dani, Martin

  • Discussed speeding up builds along the lines of bug 293830.

Oct 28: - McQ, Dani, Martin, John

  • McQ - vacation for 2 weeks: Dani to do the calls, John to do the status messages
  • McQ, Dani - IntelliJ gone open source; but not making the J2EE part open source; GUI designer and XML tooling is open source; JUnit and TestNG integration; svn integration out of the box
    • Seems to be a very liberal license - pulling in the UI designer into the Eclipse world might be an option
    • We need more information
    • Pre-integration of stuff: Could we have a "Get more stuff into Eclipse" menu item that auomatically grabs the popular stuff, rather than offering the more complex repo choices we have today
      • Or, lazy loading: E.g. click on a docs stub, open a dialog to install the docs
      • Address the casual end users like "Hey I just want to edit some XML"
    • Martin: This is the "product" vs "framework" discussion which has come up before
    • McQ: perhaps it is just a question of level of indirection?
    • Martin: Yes but who is going to actually put resources on that?
    • McQ: must have a solution in the base (the Platform)
    • Martin: That would be great, then we can approach the AC with a much stronger background
    • McQ: want to be competitive. Will know more about resourcing by Nov 16.
    • John: Already have a plan for some groundwork for this in 3.6. Some Mylyn solution exists on top of p2.
    • AI Martin put the item on the AC agenda
  • Martin - Follow up on Oct 14 McQ Official Eclipse Platform Deprecation Policy
    • John - Concerned about putting semantics on "Marketing numbers" for the releases. Focus on the time ("2 years") rather than releases.
    • John - What about upstream projects? E.g. ECF had a major release
      • McQ - cannot make decisions for other projects. If I can only move when everyone else moves, we get a deadlock. Would like to only commit to version ranges that are re-exported
    • AI continue discussion on the mailing list

Oct 21: - McQ, John, Dani, Martin, Jeff

  • McQ - backward compatibility: struggling more with maintaining backward compatibility than hoped
    • 12000 references to "internal" in IBM products (RAD) according to API - mostly due to verbatim copies of Platform code, will need better API tooling to get rid of these false positives -- e.g. by grouping together by "copied package"
    • IBM may need to keep the shape of internals alive when refactoring code
    • Keep 3.x in place as is. Do any larger API changes in e4.
    • Jeff - consumers need to understand that there is a lot of work being put into API, and it requires consumer's feedback / interaction
    • If non-IBM committers need to break internals, they are allowed to do so. If IBM people need the internals, they will invest time to work around that again.
  • Jeff - retention policies in the Galileo Repo
    • Just keep on everybody's radar. Getting this right is VERY important for the entire community.
    • We got some good stories in p2, but these don't mesh very well with mirroring (unless the entire repo is mirrored)
    • Martin - discussions in last EAC call: Maven has long history of keeping old versions alive, Andrew Overholt mentioned that making access to old versions too easy may also be a problem

Oct 14: - McQ, Dani, Martin

  • Dani Nightly Builds: More builds broken. Need to take more care for the builds.
  • Martin e4 and the AC: AC wants monthly e4 updates; Question about 4 competing declarative UI technologies
    • The switch between being in the "incubator" and being the "Eclipse SDK" needs to be "what are we using ourselves"?
    • Until we use e4 ourselves to develop, it's going to remain in the incubator. At the time we switch over, there will be one or more winning technologies.
    • McQ to join AC calls, Martin to remind timely.
  • Martin AC - API Deprecation Policy should be published, projects want to follow the Platform lead. AI McQ write something down

Oct 7: - John, Dani, Martin, Jeff

  • Martin: How to run the performance tests
    • John: See web doc
    • Dani: Frederic working on a tool for displaying results, he's still the man to ask in case of questions.

Sep 30: -

Sep 24: -

Sep 17: - McQ, Dani, Martin, John

  • John: CQ Process - The PMC's +1 is not for reading the code but for verifying that "we want this" on a high level. Bring dubious ones to the PMC as a group.
  • McQ: Java 5 - there are few plugins which may want an earlier Execution Environment, but it makes sense to drop the 1.4 Reference Platforms (need to communicate this to IBM).
  • John: Component Milestone Plans - bring up in the arch call
  • Martin: AC Representation - McQ to lead, John to second
  • Getting ready for M2, signing off for 3.5.1

Sep 10: - McQ, John, Jeff

  • Java 5
  • Jeff: Apache Aerius
  • e4 progress

Sep 3: - McQ, Dani, Martin, John

  • John: New 3.6 plan - consider removing 1.4 as reference platform, talk to Runtime guys at IBM
  • Dani: Doc Features

Aug 26: - McQ, Dani, Martin, Jeff

  • New Sat4j version - RT PMC decided to take it out again, so not an issue
  • Separating docs from the code? - Dani to post respective bug on the pmc mailing list
  • e4 status updates - Jeff interested in regular e4 updates on the pmc

Aug 19: - McQ, Dani, Martin, Jeff, John A

  • Pruning inactive committers
    • Martin: The EMO recommends removing inactive committers in order to keep the project vibrant and relevant. Why are there so many non-voters?
      • Dani: Component Granularity - Portal is still broken for JDT UI vs. JDT Core.
      • Martin: Yet there are likely some who really haven't been active for long -- but only component / project lead would know that
    • McQ: We are not actively searching to prune inactive committers. Committers are good, whether active or not. No interest in doing any work for this, but OK if others do.
      • Jeff: sees some sense in pruning the list, and did so in the past for Equinox
    • Rights - what can we actually do in the Portal?
      • Component leads can mark people active who appear inactive on the portal
      • Only The Project Lead can decommitterize, and can do so without PMC interaction
        • Jeff - it's odd that this is not symmetrical to approving new committers
    • John: Once a committer is emeritus and decides to come back, can we make the process of re-making them a committer easier?
      • Jeff thinks that the normal committer process is good in this case.
    • Consensus:
      • We do not actively ask to remove inactive committers, but if a component / project lead wants to do so, they are welcome
      • The process is to first send E-Mail to the potentially inactive committer and if they agree they are decommitterized and optionally turned to committer emeritus
      • If the E-Mail doesn't work any more they can also be decommitterized immediately.
  • Reference Platforms
    • Going through the process of refreshing reference platform list for Helios
    • Currently considering: Switch to SLES 11 from SLES 10, add Windows 7, add Ubuntu LTS 9.04, add 64-bit Eclipse for Linux PPC-64 (possibly replacing 32-bit Eclipse for Linux PPC-64)
    • If you have additional platforms or upgrades to consider, send a note on eclipse-pmc or mention during a PMC call
  • Bugzilla: LATER / REMIND states
    • 4000 bugs affected. Need to discuss in the arch call how to proceed.
    • Dani Proposal: LATER --> WONTFIX / REMIND --> INVALID / and move back to the inbox since often assignees no longer active

Aug 12: - McQ, Dani, Martin, Jeff, John A

  • Retrospective Actions -
    • Need to nominate a person to care for performance: Dani to try find somebody from JDT core for a bounded time (6 months or so)
    • Build issues
    • Bugzilla performance etc
  • Backward compatibility
    • Reporting tool - want a foundation database, that Members can report their API / non-API usage signatures into
    • Part of the member value-add
    • KNOWING the impact is the first important thing
  • Forward compatibility - from RT / Christian Campo
    • PDE never tried to ensure that somebody can use 3.4 to launch 3.5
    • The differences in launching 3.4 vs 3.5 are small... if we would have been aware, we could have made this possible

Aug 5: - McQ, Dani, Martin, Jeff, John A

  • Security proposal on eclipse-pmc list - agree that this should be closer to the target runtimes (wtp, ...)
  • "Plugin" vs "Bundle" - Clarification: Proposal was only about PDE. Global replacement is out of reach.
    • McQ thinks that Plugin is a Bundle that makes use of the Eclipse extension registry (plugin.xml) - Jeff disagrees wrt declarative services
    • As a message to end users, does it help us if we talk about "plugins"?
    • Is this an internal statement about tooling, or something we should do more globally?
    • Real problem is, that people should perceive PDE as tooling for bundles: Make Eclipse more adoptable in the OSGi community
    • "Bundle" and "Plugin" have been used interchangeably for about 5 years... but still, a more pervasive change would require lots of docs changes that may be very painful for consumers
    • McQ wants a technical proposal what should be changed
    • Perhaps provide a separate tooling for bundles (with property files replaced)? EPP Package for Bundle Developers? - But a choice is not a good thing...
    • Jeff suggestion: Do PDE 3.6 that is "all bundles" plus add a compatibility bundle that gives you the word "plugin" back.
  • McQ: Backward Compatibility - consuming new versions of Eclipse is still too hard. IBM makes it the highest priority that everything that ran on 3.5 also runs on 3.6 - including internals - or the new version may not be consumable!
    • Do anything that may not be easily backwards compatible in the 4.0 stream rather than the 3.x stream.
    • Jeff thinks this is going to be a hard sell because internals are made to be internal
    • Jeff: API Tooling that allows people to discover use of internals, see also bug 261544

Jul 29: - McQ, Dani, Martin, John A, Jeff

  • Dani will start to organize Eclipse/Galileo/Retrospective items
  • Too many broken builds recently
  • e4 shipping 0.9 this week
  • PDE project proposal coming to explore Eclipse build technology

Jul 15: - McQ, Dani, Martin, John A, Jeff

  • Dani: What to do with the Galileo Retrospective items? Which ones should become action items? E.g. Bugzilla Slowness?
    • John: Next PC meeting is Aug 3, should have items for the PC ready by then
    • Decision: PMC mailing list conversation, will review retrospective action in Jul 29 PMC meeting.
  • McQ to send out a note to formalize John as the PC representation
  • McQ wants status messages again for the arch call

Jun 24: - McQ, Dani

  • Dani asked whether the PMC meeting notes are targeted for the public
    • McQ: yes, they got announced on pmc mailing list
  • no PMC call next week due to a holiday

Jun 17: - McQ, Dani, Jeff, John A, (Martin joined just as we were hanging up)

  • Dani asked whether the PMC had internal discussion of new committer votes
    • A: Generally the PMC member for the component gives +1, unless they feel the need to bring the discussion to the rest of the PMC
  • Jeff mentioned that we should remind the teams to do retrospectives

Jun 10: - McQ, Martin, Dani, Steve, John A

  • Welcome to Dani, John agrees to be here as a listening member for a while
  • Sun Java 6u14 (May 25) broken for debugging because thread ID's are changed when garbage collector runs
    • Clearly a Sun bug (also happens in jdb) but not yet confirmed by Sun
    • Described in Readme, but readme will only be available when a rebuild occurs
    • Dani will send out a note tomorrow when they know more about other platforms

Jun 3: - McQ, Martin, Steve, Jeff

  • McQ - asking Dani M to join the Eclipse PMC to represent JDT. PMC agrees. McQ will send a note to Mike Milinkovich / EMO.
  • McQ - asking John A to represent the Eclipse Project on Planning Council
    • Jeff thinks that the PC rep should be a PMC member in order to have a strong bi-directional communication path.
    • McQ proposes asking John to join the PMC calls for communication.
    • Martin agrees provided that John is OK with this delegate role.
  • Steve bug 277713 critical bug, probably more critical bugs to triage - defer to arch call
  • Jeff Target Provisioning discussion

May 27: - McQ, Martin, Steve

  • bug 277735 copyright tool - Martin would like to see it released. Discuss in Arch call.

May 20: - McQ, Martin

  • PC Lead: John A suggested to represent Eclipse
  • Linux: New Launchers built, didn't start on Linux ... I-build was broken, want to know why

May 13: - McQ, Martin, Jeff, Steve, Philippe

  • bug 273660 Common Navigator: Pipelining issues with JDT + CDT

May 6: - McQ, Martin, Jeff

  • McQ PDE Feature Request
    • New Target Platform came in late
    • PMC agrees with trying to fix this, but want to see the final patch before +1
  • McQ Testplan
    • People going to test their own because test plan is too complex
  • Jeff Splash Screen

Apr 29: - McQ, Martin, Steve

  • Martin: Java6 ref platform - anything between 6u3 and 6u10 (exclusive) was broken, anything after 6u10 (inclusive) has license issues in thirdpartylicensereadme.txt.
    • Suggestion: Dont update the plan document yet, but start running tests with 6u13 on Linux. AI McQ talk to Kim about this.
    • AI Martin make a final attempt to get more info out of Sun.
  • Steve: Solaris x86 - looks good but some problems with X server
  • McQ: API Deprecation Policy bug 261544 - AI McQ synthesise some summary and comment on the bug
  • M7: Testers found some interesting prolbems with launching Eclipse from Eclipse (depending on VM, BIDI chars in paths dont work)

Apr 22: - McQ, Martin, Steve, Philippe

  • Steve: Solaris x86 - got a Browser running, looking good,
  • Steve: Cocoa Sheets - new API - Dialogs associated with a Window: Dialog slides down from title bar
    • Clients need to opt in through new API because they need to specify a dialog as being adequate for sheet support
  • Martin: Maintenance builds post SR2
    • experience in the past has shown only very few, surgically isolated patches so the problem is probably smaller than anticipated
    • don't want anything produced to appear official -- anything that appears official MUST result in a test pass and this must be avoided
    • it makes sense to talk about this in the context of "Release Train" and not only "Eclipse Platform" -- Martin filed bug 273262 against the AC
  • Martin has some update on Sun Java 6 -- will update bug 261724

Apr 15: - McQ, Jeff, Martin, Steve

  • McQ: Solaris x86 - OK if we get the machine up and running until Friday, too late for swapping reference platform otherways
  • Polish List Polish3.5 - Some developers don't have time for polish items. For now, it's just a list such that we *know* what's coming up.
    • Martin wondering why we need a separate wiki page, bugzilla query should be enough?
    • Who owns the Polish list - Eclipse Project Committers. We capture items that we find "stupid" when using Eclipse ourselves.
  • Maintenance builds after 3.4
    • IBM will never consume any community builds: want the absolute minimum of required fixes
    • If a fix shows up in any IBM product, then it is on a bug somewhere
    • But fixes are never cumulative
    • Martin thinks that a first step would be well-defined markup of such "released-to-product" fixes.
    • Another next step is allowing Eclipse builds by the Community -- we can do anything that's not making Kim's life harder.
    • How to proceed with communications: open bugs, bugzilla discussions.

Apr 1: - McQ, Jeff, Martin, Steve, Philippe

  • McQ: Solaris x86 (recommend building since Sun helped at Eclipsecon), Perf results (not trustworthy on Windows?)
  • Martin: M-builds beyond 3.4.2
    • Two problems: (a) provide a build system that the community can use, and (b) provide a platform for accumulating fixes easily without risking version collisions etc
      • The risk of (b) is high that as a result we'd have some low-quality sea of incompatible fixes. We better don't go with this.
    • Other solution is allow to cherry-pick on source level - just provide a new target milestone in bugzilla, product builders cherry-pick patches they want to apply and do so locally.
  • Jeff: OSGi tooling; future plans around build
    • We need to run builds ourselves (see also above) - e.g. equinox sdk feature is in some internal repository
    • PDE build has stretched pretty far over time.. what to do with it
      • Needs to be one of the main plan items for 3.6, but don't want to wait that long
      • SAP perhaps to help out with staffing
  • Boris to host the arch call since Steve, McQ, Philippe all cannot join

Mar 18: - McQ, Steve, Martin

  • no arch next week due to EclipseCon
  • McQ found a performance test that is 8000% slower
    • teams are overwhelmed (but remind them to check performance tests)
  • Martin reminded us about use of Parallel IP for Mature Projects and JSch-0.1.41
    • need to identify uses on the download links (or also inside the downloads?)
    • EMO has not developed the policy yet
    • McQ: "Q: Should we just not use the mechanism?"
    • Downstream consumers may need to test against new lib features early. Just for test and experimentation, not for consumption: want parallel IP in I-builds
    • McQ: Milestones are a corner case -- some consumers use these in products!
    • Parallel IP is a tool for projects who want it. A clear policy is one thing. Guidelines for projects to adopt it or not is another thing -- may depend on the number and kind of consumers.
    • Result: Martin to Bring up that topic on the Architecture Council/Meetings/March 22 F2F EclipseCon 2009,
      • Example issues: can't put it in for I-build and remove for Milestone S-build

Mar 11: - McQ, Steve, Jeff, Martin

  • Martin - bug 227055 and late API additions
    • McQ: after m6 is too late if it has any downstream impact (changing behavior, deleting things, ...). Plain API additions may slip a week.
    • Steve: If new API has effect on performance and polish, may look more favorably.
    • If going in after M6, it needs to go through the process (e-mail and public discussion on eclipse-pmc list).
    • Strict API Tooling checks to be enabled next week
  • McQ - state of M6; some late UI things to review
    • Some low-risk polish Cocoa items for Eclipsecon (enablers)
    • Still changes in p2 (after m6), but stabilizing
  • Martin/Jeff - New Target Platform Page may require more tweaking - risk of breaking community workflows!
    • E.g. adding a directory to the target platform; Jeff uses target platforms a lot, so he's likely more exposed than most of the Community... 10 to 15 locations with hundreds of bundles...
    • Related to the bug 224145 p2 "extension location" problem which broke user workflows. Don't want to have such breakage again.
  • Jeff - Status on Galileo Must do's - deferred to next week
  • McQ - p2 OSGi OBR Repositories
    • Jeff: OSGi wants to foster bundle store / bundle repositories, and specify a repository standard (long-standing RFE112 never been ratified)
    • Similar to p2, but does have some potential issues
    • Ideally, Equinox would be the reference impl of whatever standard comes up... but got a staffing problem, how to get the solution standardized that we need.
      • Writing a p2 OBR repository adapter is not hard, but OBR repos won't be able to eat p2 metadata
    • p2 doesn't care about XML format whereas OBR specifies the XML. p2 got more sophisticated API model. Jeff doesn't have access to the latest spec.
  • Steve wants Eclipsecon demos to be done on Cocoa, will expedite any bugfixes (please do file them!). Jeff needs browser integration.

Mar 4: - McQ, Steve, Jeff, Philippe, Martin

  • Upgrade 3.4 -> 3.5
    • Will we be able to support this in p2?
      • Nope, needed hooks already in previous release (ie. needed them in 3.4 to be used by 3.5)
    • Problems include replacing the Eclipse .exe
    • Is this an important use case? There is no band width to solve this problem in 3.5
    • it's a good showcase for p2 technology
    • idea: put in the low level hooks for 3.5.1 and use them next time (ie. 3.5 -> 3.6)
    • Did Update Manager ever do this?
      • Jeff: It does not
  • Deprecating Mac carbon?
    • Apple claims Cocoa is the future
    • 3.5 will be the last version of Eclipse where Carbon is under active development
      • But will maintain for 3.6 and 3.7
    • Q: Has Apple officially deprecated carbon?
      • No but they have down played it (ie. no 64-bit support for carbon)
    • Should there be an official deprecation policy for platforms?

Feb 25: - McQ, Steve, Martin, Philippe

  • AC "committers should know" mail
    • Following external links McQ why not introduce some Javascript on the server that warns users automatically when they follow an external link?
    • Components to projects flattening (not on our plate at the time)
  • Steve Target milestones for Eclipse project
  • BZ patches to be flagged when they contain API
  • N-builds broken over the weekend (again) - 3 weekends in a row - no people currently who are willing to work during the weekend
    • Hudson might help eventually, for now using e4 builds as the guinea pig
  • UI Forms has no committers - opportunity for Community to become committer
    • migrate off (using internal browser instead)
    • no critical bugs, less than 125 interesting bugs
    • long-term future is e4 with css/styling and declarative ui
  • Performance: No news (not yet while closing down API)
    • Philippe thinks that the performance milestone must be earlier since performance might touch on API. We're losing memory because rebasing
    • McQ - this cycle we had a performance run in M2, this year we're in a better position than last year

Feb 18: - no meeting

Feb 11:

Feb 4:

Jan 28:

  • Java 6
    • move reference platform to Sun 6u11
      • problem(?): Sun added 3 new items added that are licensed LGPL or GPL
      • Ok green.gif Martin added comment to bug 261724 to identify this issue
  • ICU 4.0
    • we will stay with 4.0
  • Deprecation Policy
  • Use of internal provisional
    • seems to be some consensus about *not* requiring this, bug 261874
  • JDT co-leadership
    • what is the process?
      • Jeff: vote in community; then propose to the PMC
      • Would like to get Dani Meghert involved.
      • Philippe will check development process documents
  • Cocoa port
    • Looking good
    • Taking early access off and making it the "first" choice for Mac downloads
  • Milestone progress / 3.4.2
    • Need to discuss M5 in arch call (should have done this last week)
    • Should always remind the team in the arch call of upcoming deadlines
    • Performance issues that need API to fix have to happen by M6
      • Teams should understand performance results (will be discussed in a couple of weeks)
  • Re: Reference Platforms
    • Java6 on Solaris
      • Martin's company would like to support this
      • Ok green.gif filed bug 262907 to discuss process and practices around reference platforms

Jan 21:

  • How should we track meeting minutes topic - Wiki
  • Provisional API conventions - Jeff working on bug 261874 for discussion at the AC
    • should there be a tag in the Javadoc (ie. "experimental")?
    • Jeff wants to keep the concerns "conventions" vs "Javadoc" separate
    • Jeff, "... Javadoc should not be generated for provisional ..."
    • Martin disagrees, "... need feedback and discussion for new API ..."
  • What is the role of the PMC lead?
    • global view of components/processes
    • organize architecture call, ensure we are on track
    • spark conversations (ie. M5 is feature freeze)
  • Reference platforms
    • we should choose JDK1.6, "update 11" rather than "update 4"
    • around "RC time", solidify the reference platform (it is the one we are testing on)

Jan 14:

  • PMC component ownership x bugzilla pmc authorization

Back to the top