Attending: Eugene, Harm, Oliver, Chris, Paul, Joanna
Profilier inititiave (POG)
Oliver apologized for being a bit late following up on emails. Eugene indicated that he would be finalizing initial collateral today.
- Eugene will be sending out initial posting for newsgroups
- He will send Oliver information about where it was posted so that Oliver can follow up and express excitement over the concept with potential users :-)
- If we are lucky enough to get too much response we will need to come up with an approach for filtering who to work with first.
Oliver asks if there is anything to discuss for 4.5.2?
- Oliver thanks Joanna for getting project plan XML file done
Joanna provided a heads up to PMC
- One consumer asking for some changes to Test functionality
- Paul is working on some defect fixing for them
- Paul will provide some details about what bugs fixed and explore providing a simple patch to consumer.
- Hopefully this will be enough and we can avoid a request for a point release (126.96.36.199)
Request for other Platforms
NOTE: This is a preliminary discussion and should not be construed as a decision by PMC or participants in project... :-)
Joanna reminded us that the Agent controller technology was deprecated on all but x86/EM64T/IPF. Java6 profiling for example cannot work on other platforms.
- Joanna noted that at least one team at IBM has asked for a port of the AC and TI to several other platforms of interest to IBM.
- They (Joanna's team) may get resources to do some basic porting and put in appropriate ifdefs for platform support
- They would like to consider storing back into CVS so that it is reflected in HEAD to avoid replicated codebases
- If there is interest, there might be some opportunity to publicly provide non-supported binaries for these platforms.
The PMC had assorted discussion about the merits of this. We noted that there are some places in TPTP where there is ifdefed code that is not used in any released binaries. So having such ifdefed code is not really a problem. A bigger problem relates to avoiding a slippery slope where resourcing focus turns into creating ifdefed code and not in driving release code quality. Taken to an extreme, it could be at odds with the purpose of Eclipse open source. Oliver definately asked what impact this might have on future resourcing.
- The release of unsupported as-is binaries on eclipse.org for components that were never generally available did not seem to be consistent with Eclipse philosophy.
We did have some discussion around whether or not the engineers who would be doing the work are currently committers to the Platform component where the patches will be. If they are and they follow appropriate committer rules, there is not a problem.
- If they are not currently committers, they would need to submit patches that would be reviewed and integrated by committers. Over time, with a little wider focus they would become considered for committership.
- Harm notes that patches could not go in at any time (i.e., TPTP project has release cycles and patches could only go in during appropropriate points in the development cycle for a given release).
- Joanna noted that she would need also need to think a bit about testing for the consumer.
Harm indicates that if this is done poorly, it can start to look like we are having a double standard and are allowing code to be "dumped" without support by a priviledged few.
- Oliver noted that since IBM does provide significant resourcing to the project already, some level of flexibility is probably appropriate
- Chris noted that it is a somewhat grey area and that scatterings of small ifdefs for an experimental port are a different thing from large blocks of ifdefed code.
- We discussed that the committers that would review such code would need to exert some rule to determine what was excessive. We should be following normal peer review process and have some PMC oversight regarding what is going on.
Harm noted that if we allow this, we may want to revisit the recurring request/volunteering to provide some experimental ifdefs for an Apple port.
- Someone provides ifdef code in patch form along with confirmation that it works but no binary distribution on eclipse.org
- It would need to follow the same process... If Mac/OS expert contribs similar ifdefs, committers in project should review/accept them with same basic rules of thumb as for the other unsupported platforms.
- It is possible that such a person could become a committer over time.
Paul opened defect about simplifying web site.
- AI to PMC members to please review and comment on