|
|
Line 68: |
Line 68: |
| * Jeff will be away for next six weeks (vacation) | | * Jeff will be away for next six weeks (vacation) |
| * McQ to contact Steve to see if he still wishes to remain on PMC | | * McQ to contact Steve to see if he still wishes to remain on PMC |
− |
| |
− | <hr/>
| |
− | '''Dec 9:''' - John, Dani, McQ, Martin
| |
− | * Agree on the [[Eclipse/API Central/Deprecation Policy]]
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''Nov 25:''' - John, Dani, McQ
| |
− | * No interesting discussion due to lack of attendees
| |
− |
| |
− | <hr/>
| |
− | '''Nov 18:''' - John, Martin, Dani
| |
− | * John: Deadlocks / errors during JDT and CVS tests - deadlocks should be fixed, not sure about other failures.
| |
− |
| |
− | <hr/>
| |
− | '''Nov 11:''' - Dani, Martin, John, Jeff
| |
− | * Nothing to discuss.
| |
− |
| |
− | <hr/>
| |
− | '''Nov 4:''' - Dani, Martin
| |
− | * Discussed speeding up builds along the lines of {{bug|293830}}.
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''Oct 7:''' - John, Dani, Martin, Jeff
| |
− | * Martin: '''How to run the performance tests'''
| |
− | ** John: See [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.test.performance/doc/Performance%20Tests%20HowTo.html?view=co web doc]
| |
− | ** Dani: Frederic working on a tool for displaying results, he's still the man to ask in case of questions.
| |
− |
| |
− | <hr/>
| |
− | '''Sep 30:''' -
| |
− |
| |
− | <hr/>
| |
− | '''Sep 24:''' -
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''Sep 10:''' - McQ, John, Jeff
| |
− | * '''Java 5'''
| |
− | * Jeff: '''Apache Aerius'''
| |
− | * '''e4 progress'''
| |
− |
| |
− | <hr/>
| |
− | '''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'''
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''Aug 19:''' - McQ, Dani, Martin, Jeff, John A
| |
− | * '''Pruning inactive committers'''
| |
− | ** Martin: The EMO [http://dev.eclipse.org/mhonarc/lists/eclipse.org-project-leadership/msg00000.html 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 [http://dev.eclipse.org/mhonarc/lists/eclipse.org-project-leadership/msg00002.html 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 [http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04309.html decommitterized] and optionally turned to [http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04324.html 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
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''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}}
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''Jul 15:''' - McQ, Dani, Martin, John A, Jeff
| |
− | * Dani: What to do with the [http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg08660.html 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
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''May 27:''' - McQ, Martin, Steve
| |
− | * {{bug|277735}} releng.tools copyright tool - Martin would like to see it released. Discuss in Arch call.
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− | <hr/>
| |
− | '''May 13:''' - McQ, Martin, Jeff, Steve, Philippe
| |
− | * {{bug|273660}} Common Navigator: Pipelining issues with JDT + CDT
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− |
| |
− | <hr/>
| |
− | '''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 [http://java.sun.com/javase/6/javase-6-thirdpartyreadme.txt 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)
| |
− |
| |
− |
| |
− | <hr/>
| |
− | '''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}}
| |
− |
| |
− |
| |
− | <hr/>
| |
− | '''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.
| |
− |
| |
− |
| |
− | <hr/>
| |
− | '''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
| |
− |
| |
− |
| |
− | <hr/>
| |
− | '''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 [http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00575.html 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
| |
− |
| |
− | <hr />
| |
− |
| |
− | '''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.
| |
− |
| |
− | <hr/>
| |
− |
| |
− | '''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?
| |
− |
| |
− | <hr/>
| |
− |
| |
− | '''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:'''
| |
− |
| |
− | <hr/>
| |
− |
| |
− | '''Jan 28:'''
| |
− |
| |
− | * Java 6
| |
− | ** move reference platform to Sun 6u11
| |
− | *** problem(?): Sun added 3 new items added that are licensed LGPL or GPL
| |
− | *** [[Image:Ok_green.gif]] Martin added comment to {{bug|261724}} to identify this issue
| |
− | * ICU 4.0
| |
− | ** we will stay with 4.0
| |
− | * Deprecation Policy
| |
− | ** still under discussion, {{bug|261544}}
| |
− | * 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
| |
− | *** [[Image: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
| |