|
|
(926 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
| + | = Documents = |
| + | Some documents written and/or used by the PMC: |
| + | |
| + | * [[E4/Graduation_4.0]] |
| + | * [[Eclipse/PMC/Unix Groups]] |
| + | |
| = Meeting Schedule = | | = Meeting Schedule = |
| | | |
− | The [http://www.eclipse.org/eclipse/team-leaders.php Eclipse Project PMC] has a weekly phone meeting '''every wednesday at 10.30am EST'''. | + | The [http://www.eclipse.org/eclipse/team-leaders.php Eclipse Project PMC] has a weekly phone meeting '''every Tuesday at 11.00am EST'''. |
| | | |
| = Meeting Minutes = | | = Meeting Minutes = |
| | | |
− | '''Aug 19:''' - McQ, Dani, Martin, Jeff, John A
| + | See https://github.com/eclipse-platform/.github/wiki/PMC-Meeting-minutes for new minutes |
− | * '''Pruning inactive committers'''
| + | |
− | ** Martin: The EMO [http://dev.eclipse.org/mhonarc/lists/eclipse.org-project-leadership/msg00000.html recommends keeping committers active]. 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.
| + | |
− | *** Jeff: sees some sense in pruning the list.
| + | |
− | ** Rights - what can we actually do in the Portal?
| + | |
− | *** Component leads can mark people active who appear inactive on the portal
| + | |
− | *** CL don't have the right to move a committer to Emeritus, only Project Lead / PMC can do that
| + | |
− | *** Martin: [http://dev.eclipse.org/mhonarc/lists/eclipse.org-project-leadership/msg00002.html The Project Lead can decommitterize] 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 turn to emeritus immediately.
| + | |
− | * '''Reference Platforms'''
| + | |
− | ** Windows 7
| + | |
− | | + | |
− | <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/>
| + | March 30, 2022 - Alex, Tom, Lars |
| + | * Discussion about simplification of the Github repo structure |
| + | * Currently no plan to provide a Github for user to report issues, we rather |
| + | * For pull request there should no need to open a bug report / GH issue, all present PMC members agreed, to be discussed next week with Jay and MQ. |
| | | |
− | '''Jan 28:'''
| + | February 16, 2022 - Alex, Tom, Jay, Lars, McQ |
| + | * IP log done for 2022-03, process might be removed by the foundation in the future |
| + | * Auto-closed policy can now be decided by project, project committer can vote on it |
| + | * Support of additional architecture LoongArch and FreeBSD was discussed, for now we expect the builds outside of Eclipse.org for these architures |
| + | ** building Eclipse might get easier with planned enhancements in Tycho |
| + | * Bug reports from Bugzilla are not planned to be moved to Github, will continue to exist in Bugzilla |
| | | |
− | * 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:''' | + | '''January 19, 2022''' - Alex, Tom, Jay, Lars, McQ |
| + | * Eclipse aggregator build is currently migrated to Github |
| + | * Github migration work of the aggregator is documented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=577323 |
| + | * The most important PGP work items are done with the help of Ed Merks, some secondary issues are still missing, e.g. such features are shown as unsigned |
| + | * JFR Event are discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=578055, PMC members should check so that we can discuss it next week |
| | | |
− | * How should we track meeting minutes topic - Wiki
| + | '''January 12, 2022''' - Alex, Tom, Jay, McQ |
− | * Provisional API conventions - Jeff working on {{bug|261874}} for discussion at the AC | + | * Move to PGP signed content news to IDE WG and Planning Council |
− | ** should there be a tag in the Javadoc (ie. "experimental")? | + | ** Well received so far |
− | ** Jeff wants to keep the concerns "conventions" vs "Javadoc" separate | + | ** 2022-03 to has the implementation, 2022-06 to do full switch |
− | ** Jeff, "... Javadoc should not be generated for provisional ..." | + | ** we use PGP for content not delivered to Simrel |
− | ** Martin disagrees, "... need feedback and discussion for new API ..." | + | ** Ed helps with implementation/bug fixes |
− | * What is the '''role of the PMC lead?''' | + | ** only concern is critical CVE - that would require either help or PGP signed content being pushed to 2022-03 |
− | ** global view of components/processes | + | *** To be further discussed if such an issue happens |
− | ** organize architecture call, ensure we are on track | + | * ECF relation |
− | ** spark conversations (ie. M5 is feature freeze) | + | ** Project is heavily under resourced |
− | * '''Reference platforms''' | + | ** No one knows good reason to still be using Apache Httpclient, Java HttpClient is not tried out and the previous JVM Http code had severe limitations |
− | ** we should choose JDK1.6, "update 11" rather than "update 4" | + | ** Development falling out on Platform releng for updates to Apache Httpclient, Windows proxy support and etc. is a no-go |
− | ** around "RC time", solidify the reference platform (it is the one we are testing on) | + | ** Possible plan |
| + | *** Create Java Httpclient based connector for ECF or enhance the current default one to use Httpclient and not Httpconnection - removes need to update Apache Httpclient dependency, take care of windows specific bundles with JNA dependency and so on |
| + | *** If previous doesn't uncover limitation in Java's Httpclient stop shipping Apache Httpclient connector |
| + | *** Assuming 2 previous complete - look if it makes sense to not have ECF as a dependency at all to skip one cyclic dependency |
| | | |
− | '''Jan 14:'''
| + | = Archive = |
| | | |
− | * PMC component ownership x bugzilla pmc authorization | + | * [[Eclipse/PMC/Minutes 2021 | Archive of Meeting Minutes from 2021]] |
| + | * [[Eclipse/PMC/Minutes 2020 | Archive of Meeting Minutes from 2020]] |
| + | * [[Eclipse/PMC/Minutes 2019 | Archive of Meeting Minutes from 2019]] |
| + | * [[Eclipse/PMC/Minutes 2018 | Archive of Meeting Minutes from 2018]] |
| + | * [[Eclipse/PMC/Minutes 2017 | Archive of Meeting Minutes from 2017]] |
| + | * [[Eclipse/PMC/Minutes 2016 | Archive of Meeting Minutes from 2016]] |
| + | * [[Eclipse/PMC/Minutes 2015 | Archive of Meeting Minutes from 2015]] |
| + | * [[Eclipse/PMC/Minutes 2014 | Archive of Meeting Minutes from 2014]] |
| + | * [[Eclipse/PMC/Minutes 2013 | Archive of Meeting Minutes from 2013]] |
| + | * [[Eclipse/PMC/Minutes 2012 | Archive of Meeting Minutes from 2012]] |
| + | * [[Eclipse/PMC/Minutes 2011 | Archive of Meeting Minutes from 2011]] |
| + | * [[Eclipse/PMC/Minutes 2010 | Archive of Meeting Minutes from 2010]] |
| + | * [[Eclipse/PMC/Minutes 2009 | Archive of Meeting Minutes from 2009]] |