Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "TPTP Jan 07 face to face"

m (Agenda topics January 9/10/11, 2007)
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
Return to TPTP [[TPTP | wiki main page]].
+
[[TPTP|TPTP Wiki home]] > [[TPTP_Miscellaneous|Miscellaneous]] >
  
  
Line 84: Line 84:
 
****Project leads will ensure new test cases for all new defects/enhancements. This is a specific item identified and sized in each enhancement request.
 
****Project leads will ensure new test cases for all new defects/enhancements. This is a specific item identified and sized in each enhancement request.
 
****TPTP will investigate running performance benchmarks using SPEC jAppServer (http://www.spec.org/jAppServer/).  Each member company of TPTP can use SPEC jAppServer for evaluating the performance impact of TPTP. the jAppserver code can not be in the TPTP CVS, but periodic runs will be done and results published.
 
****TPTP will investigate running performance benchmarks using SPEC jAppServer (http://www.spec.org/jAppServer/).  Each member company of TPTP can use SPEC jAppServer for evaluating the performance impact of TPTP. the jAppserver code can not be in the TPTP CVS, but periodic runs will be done and results published.
****''Action:'' [Paul] The Test project will investigate using Emma (http://emma.sourceforge.net/) for code coverage of TPTP's Java code.
+
****''Action:'' [Paul] The Test project will investigate using Emma (http://emma.sourceforge.net) for code coverage of TPTP's Java code.
****''Action:'' [Paul] The Trace project will investigate using PIN for code coverage of TPTP's native code.
+
****''Action:'' [Guru] The Trace project will investigate using PIN (http://rogue.colorado.edu/Pin) for code coverage of TPTP's native code.
 
****The Test project will discuss how the Trace project's JVMTI test infrastructure, and the Agent Controller and Profiler test server can be integrated with the Test tools.
 
****The Test project will discuss how the Trace project's JVMTI test infrastructure, and the Agent Controller and Profiler test server can be integrated with the Test tools.
 
****test dashboard (https://bugs.eclipse.org/bugs/show_bug.cgi?id=112928) will be reviewed  
 
****test dashboard (https://bugs.eclipse.org/bugs/show_bug.cgi?id=112928) will be reviewed  

Latest revision as of 14:22, 24 January 2007

TPTP Wiki home > Miscellaneous >


When a call in is active the number will be

Conference ID: 6044164

Dial in Local number: 416-343-2622

Toll-free Dial-in number: 1 866-516-6489



if you want to call in and the line is silent or inactive, e-mail Harm and sluiman@ca.ibm.com

Agenda topics January 9/10/11, 2007

Day One (January 9, 2007)

  • Current Issues
    • TPTP 4.4 (Europa M4)
      • TPTP builds are ready but the Europa site is not ready.
      • EMF 2.3.0 requires JRE 1.5.0 which causes Europa to require JRE 1.5.0. However, TPTP 4.4 will package EMF 2.2.0 with the Agent Controller and build the plug-ins against EMF 2.2.0 to support both JRE 1.4.x and JRE 1.5.0 run-times. This is due to a consumer requirement to continue our model run time support in a 1.4 web server environment.
    • TPTP 4.2.2
    • 4.3.1
      • No issues noted by the commiters or project leads on the dates and deliver ables for 4.3.1.
  • Role Changes
    • Joanna is proposed to assume the Platform.Execution(Execution), Platform.Execution.Framework (Execution: Framework), Platform.Collection (Collection Control) and Platform.Communication (Communications) components. ACTION: The current component owner(s) will nominate Joanna to assume ownership, and the normal approval process will be followed. In the meantime Joanna will be filling in for Christophe.
    • The build component will be expanded to include release engineering and web site management. In practice this has been part of the role Hubert and others have played and this will formalize the ownership. ACTION: A releng component needs to be created in bugzilla (or renamed) and the function of this component needs to be documented on the platform project web page that describes it's high level component purpose.
    • Project leads require CVS privileges for updating the TPTP website (e.g. TPTP Matrix). The PMC/PG approves the following project leads to have CVS privileges to the TPTP web site (http://dev.eclipse.org/viewcvs/index.cgi/www/tptp/?root=Eclipse_Website): ACTION:releng to update
      • Paul Slauenwhite
      • Dave Smith
      • Joanna Kubasta [coordinated with commiter nomination]
      • Guru Nagarajan
    • Europa packaging is changed from Callisto and the TPTP roles must be defined.ACTION:AG will determine the Europa packaging categories.
    • A commiter is required to own the TPTP product documentation (including translating and TVT) and web site documentation (including the WIKI) to reduce the documentation defect backlog, reviewing (e.g. consistency checking) and testing (e.g. spelling, links and grammar). When not related to a specific enhancement, this is considered sustaining work. This also include removal of old content.ACTION:Project Leads need to identify a specific commiter in their project to own this part of the project content and deliverable.
    • ACTION:The owner of the component described by the documentation is responsible for the technical review of the documentation at least once per release (as part of the documentation freeze).
  • Housekeeping
    • To cleanup the TPTP Matrix, the following components have been approved to be removed from the TPTP Matrix and Bugzilla:
      • Test.UI (n/a)
      • Test.UI.Charting (Charting)
      • Test.Analysis (Analysis rule)
      • Platform.Execution.Choreography (Execution: Choreography) [org.eclipse.tptp.choreography plug-in is deprecated]
      • Trace.Analysis (n/a)
      • Trace.Execution (Execution: Probe instances)
      • Monitor.UI.CustomizedStatsView (Customized Stats View)
    • ACTION:releng- Committer matrix will be made dynamic (as prototyped by Hubert) based on CVS and Bugzilla.
    • The TPTP architecture and sub project description pages need constant updating. They are intended to be current descriptions of the structure and function of the project, and are accessed from the foundation architecture pages. The original intent was to also link to other documentation and project rleated information.ACTION:Project leads need to update each project's space on the TPTP web site. Each project's space should be current based on the current features, architecture and user interface. This information should drill down to more detailed functional and architectural information.
  • Project Structure Updates
    • Create a samples/examples component per project to include the Eclipse-based samples/examples shipped with the TPTP run-time/SDK. The project leads will be the component leads for these components.ACTION:project leads to coordinate
    • Package all of the sample code/projects used at presentations and demonstrations (e.g. conferences) on the TPTP web site packaged as downloadable Eclipse projects/plug-ins.ACTION:Project leads to coordinate
    • Create and maintain a shared repository of donations from the user community hosted but unsupported by TPTP (e.g. http://www.eclipse.org/tptp/home/project_info/general/contribute_or_feedback.html). For example:
      • GLA rules
      • Static analysis rules
      • Probes
      • BIRT report templates
      • Symptom databases
    • This is comparable to wiki content, only the archive will be in a bugzilla attachment, yet the discussions can be completely open in the wiki. TPTP will simply provide a single plugin download for each domain that holds the end user provided extensions. There is no commitment of support or adoption, but all contributions may be considered for adoption into core function of the project.

ACTION:For at least these examples the project leads will coordinate that the components have common mechanism in place that is within the foundation IP rules.ACTION:releng to create the packaging and deliverable. The hosting component will own the validation and testing of the contributions

  • 2006 in Reflection
    • Discussion of post mortem of TPTP 4.3.
      • Several of the locations where commiters where co-located held post mortem reviews. The overall project community seems to have shared common observations and the following captures the feedback in those sessions and the intended relative actions.
      • Concern: Reasons for missing the 4.3 release deadline and being in crunch mode for 4.2 and other 2006 release.
      • Issues:
        • Checking unstable code to meet deadlines.
        • The driver is not in a stable condition when the test pass starts.
        • Not enough time allocated to code reviews.
      • Solutions:
        • Commiters need to adhere to the project schedules, incrementally check-in code to CVS and continual regression testing.
        • Project leads will schedule and monitor peer reviews.
        • The entry criteria for a test pass in no expected failures, particularly high severity ones. This implies a component level validation has completed successfully before the test pass candidate is delivered.
      • Concern: Investing more time in infrastructure (e.g. testing/code reviews/etc...) improvements.
      • Issues:
        • We make a commitment to improving quality but invest little time/effort to improve our infrastructure.
      • Solutions:
        • Project leads will ensure new test cases for all new defects/enhancements. This is a specific item identified and sized in each enhancement request.
        • TPTP will investigate running performance benchmarks using SPEC jAppServer (http://www.spec.org/jAppServer/). Each member company of TPTP can use SPEC jAppServer for evaluating the performance impact of TPTP. the jAppserver code can not be in the TPTP CVS, but periodic runs will be done and results published.
        • Action: [Paul] The Test project will investigate using Emma (http://emma.sourceforge.net) for code coverage of TPTP's Java code.
        • Action: [Guru] The Trace project will investigate using PIN (http://rogue.colorado.edu/Pin) for code coverage of TPTP's native code.
        • The Test project will discuss how the Trace project's JVMTI test infrastructure, and the Agent Controller and Profiler test server can be integrated with the Test tools.
        • test dashboard (https://bugs.eclipse.org/bugs/show_bug.cgi?id=112928) will be reviewed
      • Concern: Defect approval process during must-fix phases.
      • Issues:
        • The process of sending requests on the mailing list is not efficient and pollutes the mailing list making other posting hard to follow.
        • The process is confusing since it is not clear.
      • Solutions:
        • The documented process for defect approval in shutdown mode is:
          • All defects require 1) Project Lead and 2) PG approvals (e-mail on the tptp-pmc@eclipse.org mailing list). Each approval request must be accompanied by a completed stop ship template http://www.eclipse.org/tptp/home/documents/process/development/stop_ship_template.html) which is included in the defect as well. If the Project Lead has approved the defect, the request is forwarded to the PG by the Project Lead for approval. The defect will be considered approved as soon as one additional PG member votes +1. Any PG member may vote -1 vote which will negate all +1 until there is a resolution by the PMC.
        • This process will be added to the TPTP web site after 4.3.1. This process is followed during the following points of a release:
          • Last week of development in a full release iteration.
          • Last iteration in a full release.
          • All iterations in a maintenance release.
        • It is felt that with the other changes being put in place the volume of activity will be minimal and using mail is most flexible and transparent.
      • Concern: Weekly project and AG weekly meeting agendas.
      • Issues:
        • Sub-project and AG calls meetings are polluted with low level project status, such as defect and test run status.
        • Often the AG call time slot was taken for overrun or check point review by the PG/PMC as a result of the Wed. call. This was done as a convenience to schedule time, but was poorly communicated to the larger community.
      • Solutions:
        • Valentina will query the project committers for suggestions on architectural issues they want to address during the weekly AG call. This meeting will be used for:
          • Demonstrations
          • Architectural updates
          • Peer reviews
          • Investigation result presentations, or short investigative discussions
          • Committer suggested content
        • Weekly project meetings are by definition status meetings so committers will have to determine if they want to attend weekly meetings based on the posted agenda. Within the projects, the committers are free to suggest additional content for the regular meetings.
      • Concern: PG Communication of various non-development related requests
      • Issues:
        • There are situations where committers are asked to run tasks on a very short notice, without knowing the rationale of that request.
      • Solutions:
        • The specific issue in 4.3 regarding contributions was the result of unclear communication. The sudden issue was triggered by the discovery that the IP log and related material was not current, which would result in not being able to release. In some cases the information request was larger than needed and the motivation was not communicated. This was unfortunate but it should not be lost that the issue was real and a result of committers not following protocol and process earlier in the release.
        • Moving forward, PMC members and project leads will consider the current point of the release/iteration and nature of any requests.
      • Concern: Update test case results after the tests are executed and mark test cases with deferred defects as in conclusive.
      • Issues:
        • Project leads ask committers to manually update the execution history and mark test cases failed because of deferred defects as inconclusive.
      • Solutions:
        • The consensus was that the execution history should not be changed to inconclusive if test cases are failed due to deferred defects.
        • We use the one report for multiple purposes and it would be better to have more reports. One to report progress with ongoing problems, one to report execution of the test cases expected to succeed, one to report overall project health which must include coverage statistics to make the test coverage a meaningful metric.
        • The use of the inconclusive verdict is clear in the TPTP Testing Strategy document and should not be used for 'hiding' failing test cases.
        • Project leads need to remind committers of the TPTP Testing Strategy document (http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
  • Sandbox Proposal
    • Motivation:
      • Provide a loosely managed environment to suggest and find out what uncommitted work items are needed and of interest to the TPTP project.
      • Provide a page for open discussion and evolution of the concept and design.
      • A place committers can see what is of interest for them to work on without commitment rather than ad hoc self assignment the work is intended to be "filler" or "side" activities beyond the regular project commitments.
    • Proposal:
      • One root wiki page with a simple outline of the rule of engagement.
      • A list of links to a page for each subject work item.
      • Each page can evolve into a formal enhancement, an incubation, or nothing.
      • The progress of these work items must be reviewed by the AG before reaching a point of being committed to CVS, even as a tech preview.
      • Subject matter is typically related to "help wanted" enhancement or things generally perceived as good for TPTP including samples, tutorials, build tools, enhancements. This is not intended to be a replacement of the release review process. It is purely a place to find good use of free time.
  • Defect Backlog Plan
    • TPTP has a backlog fo >1000 defects most of which are less than 1 year old. The backlog has been growing steadily and has reached a point where they can only be assessed in filters groups. This has opened the door to problems being able to leak into the stack without proper triage and may be an indication of a problem in the quality of the base code. This is why addressing this issue is one of the imperatives for TPTP 4.4.0
    • Test
      • Currently 260 active defects.
      • Each commiter will focus on reducing the defect backlog early in 4.4.
      • Each commiter will share a terse 'to-do' list of defects including blocking issues and architectural issues/concerns on the weekly Test Project call that will be the focus for the upcoming week. This will assist in keeping the defect backlog front and center, encourage peer review, tack status and identify/communicate and blocking issues.
      • The Test project will triage the higher severity defects (e.g. >normal) on a weekly basis to track status and identify any blocking issues.
    • Monitoring
      • Currently 172 active defects.
      • Still triaging existing defects.
      • Outstanding information required for remaining Monitoring defects.
    • Trace
      • Currently 51 active defects.
      • Fix defects in the test cases (e.g. error verdict).
      • Target the defects that are failing the test cases (e.g. failure verdict).
      • Triage the remaining defects.
    • Platform
      • Currently 654 active defects.
      • Resource limitations for resolving Agent Controller defects.
      • Outstanding information required for remaining Platform defects.
    • ACTION:All projects will follow the following process for reducing the defect backlog plan:
      • Lead committers will triage each defect to assign an accurate severity and priority (http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html). Duplicate and expired defects will be returned/closed. All outstanding defects are to be triaged in order to make filtering by severity and priority meaningful.
      • Lead committers will determine what defects they feel can be resolved in 4.4. and All defects will be properly marked with a priority of 1, 2 or 3. 1 meaning that it is committed to be delivered and thus stop ship, 2 meaning extended efforts should be made if possible to deliver in 4.4 but is not stop ship, 3 meaning that it is not considered important to deliver in 4.4.
      • Project leads and lead committers will discuss and prune which defects will be confidently resolved in 4.4 to determine the concrete exit criteria for each iteration of 4.4.
      • Project leads will report any inconsistencies between the number of candidate defects and the total number of defects.
      • Project leads will include an estimated cost of this part of sustaining work as input to the PG by EOD Jan 17.
  • Internal API Usage:
    • Internal api usage will enter a zero tolerance point during 4.4. TPTP has only a few cases of this and has done this with the awareness of the api provider in order to provide significant request end user function. However even with every-one's best intent we have not been able to attain the needed api or a viable work around. At the same time the end users we are trying to please are experiencing major problems when unknowingly updating components. This has been the subject of various blogs, newsgroups and mailing lists, and is a problem for all our consumers.
      • ACTION:Release engineering will provide build scripts/reports to flag the change in internal API usage compared to a previous baseline, as well as the current report of internal API usage.
      • No internal API will be tolerated in 4.4.
      • ACTION:Any internal API reference that can not be resolved by the end of 4.4 i1, it (and its containing functionality) will be removed from 4.4. The community of users that want these function can help by lobbying the dependant components along with TPTP to get the needed API.
      • Top-level defect:
      • Monitoring:
      • Platform:
        • https://bugs.eclipse.org/bugs/show_bug.cgi?id=142103
          • An agreed WTP linkage is in place but still requires formal closure.
        • https://bugs.eclipse.org/bugs/show_bug.cgi?id=126584
          • Completed except the Profile launch configuration for Eclipse JUnit/Plug-in.
          • Currently, if the required internal PDE APIs are not made public in Eclipse 3.3 M5, the Eclipse JUnit/Plug-in Profile launch configuration will be removed in TPTP 4.4.
        • https://bugs.eclipse.org/bugs/show_bug.cgi?id=163805
          • Targeted for 4.4. i1.
        • https://bugs.eclipse.org/bugs/show_bug.cgi?id=162562
          • Contribution included internal API in the FastXPath compiler that was not removed by the component owner.
          • No accurate estimation to work-around these internal APIs.
          • As such, the FastXPath compiler will be removed in TPTP 4.4. The existing use cases will run much slower and this may not be acceptable to consumers. In that case addition resource may need to be provided to recover the performance.
          • The alternative is to add the the function for static compilation. Once sized, if reasonable this will be contained as sustaining work, but if not containable additional resources may be required to get closure.
      • Test:
        • https://bugs.eclipse.org/bugs/show_bug.cgi?id=126575
          • There are several internal PDE APIs requested to be made public currently in plan for Eclipse 3.3 M5.
          • Currently, if the required internal PDE APIs are not made public in Eclipse 3.3 M5, the JUnit plug-in test type will be removed in TPTP 4.4.

Day Two (January 10, 2007)

  • TPTP 4.4 Enhancement Update
    • All approvals are still subject to PG/PMC review after the resource assessments are completed by the project leads, due Jan 17. This is an approval, conditional in some cases, to include these items into the short list of candidates for 4.4 consideration.
    • Stage 1
      • COSMOS and TPTP data collection and storage discussion.
        • Mark Weitzel will post the architectural slides on the COSMOS WIKI, and collaboration on the design will continue. Collaboration will focus on the statisitical heirarchy and log models.
        • TPTP Use Case: Scalability for all TPTP models using an abstract data persistence layer. Focus of interest is on trace and test log.
        • Due to the minimal resources at this point from both projects on this effort, an assessment will have to be done realtive to which model and what release cycles will make sense.
      • WSDM:
      • BtM:
        • https://bugs.eclipse.org/bugs/show_bug.cgi?id=159634
        • Approved the BtM monitoring instrumentation (ARM, JMX and CBE) pending an assessment of the integrated use cases with the rest of TPTP.
        • Confirm support for JMX data from a BtM instrumented JBoss or JOnAS server application being collected by the TPTP JMX Metric Statistical Agents.
      • JVMTI:
        • https://bugs.eclipse.org/bugs/show_bug.cgi?id=168375
        • Code has been hardened since the end of November 2006.
        • No internal API issues.
        • Outstanding candidate features that are beyond what has currently been hardened:
          • Object reference graph
          • Thread Analyser
          • Launch configuration (attach) support
          • Trace data aggregation in the agent
        • The above outstanding features are required and potentially considered for 4.4 which will be staffed by Intel. However, these outstanding features require accurate sizings.
        • Outstanding feature:
        • In order to GA all of the follow are required:
          • It is clear that the base function is hardening and the attach profiling use cases are understood. In order to round out the functional part of profiling the yet to be sized and staffed candidates are also required (Object refernece graph, thread analyzer, trace data aggregation, launch config improvements). As noted, these sizings and resource commitments are needed in order to proceed.
          • The tech preview asserts the need for coexistance of both agent controller implementations as TIagent with PIagent in order to support the existing larger TPTP use cases. For example profiling of a probekit instrumented application that logs to the existing logging agent, all as part of a JUnit test. The end user experience in TPTP must not degrade and it is not clear we need to expose the user to anything more than a choice of >= Java 5. This is a combination of work items in the UI, the agent controller, as well as the agents, partly due to the fact that the TIagent requires the newer agent controller.
          • The sizing of effort to integrate this set of features will require the time of other committers to review the design and code. Historically this has been an area of oversight in TPTP plans and this workload must alos be sized and confirmed before proceeding to GA.
    • Stage 2
      • There will be no stage 2 features considered for 4.4 at this time due to the anticipated lack of resources. Once hte detailed contribution and sustaining cost are tabulated, there may still be time to carefully entertain some additional content in the plan.
  • TPTP 4.4 Plan
    • Iteration 1 will be internal API clean.
    • API freeze will be the end of iteration 2.
    • Project leads will work with lead committers to triage all active defects to complete the following (see http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html):
      • Blocking, critical and major severity are proposed as P1 by default.
      • Highly desirable and planned for 4.4 but not stop ship are P2.
      • Unsupported platforms are set P3.
    • After triaging ALL defects determine an overall sizing for the following severity defects:
      • Blocking
      • Critical
      • Major
      • Normal
    • Committers will focus on reducing the defect backlog when not completing 4.2.2/4.3.1 maintenance releases by completing P1 defects first.
  • 2007 Resource Planning
    • PG/PMC will finish gathering the individual contribution per member company and compile the final resource requirements.
    • Assessment of contribution levels
    • Noteworthy:In TPTP 4.4, native code on only the following core platforms will be refreshed:
      • Windows (x86, EM64T, IPF)
      • Linux (x86, EM64T, IPF)
    • Native code on all other platforms will be in sustaining mode based on the 4.3.0 Remote Agent Controller code base.
    • Existing Java based agents will continue to evolve against this base and continue to deliver as part of the 4.4 stream on all platforms.They will be packaged as addons to the 4.3 base and by default the 4.3 dependancy base will not be bundled in any packaging.
    • On the core platforms, RAC and JVMPI in 4.4 is constrained to Java 1.4.x with Agent Controller and JVMTI will support Java 1.5.x and newer run-times.
    • Agent Controller and JVMTI will only be supported on the core platforms.
  • Other Topics
    • Assess future maintenance streams
      • there are currently no outstadnign requests for maintenance streams, but if any arrise thye wull only be taken on if other work can be quiesed or addition resources come available.
    • Conformance and quality testing for the Eclipse Foundation:
      • TPTP Test tooling is not sufficiently mature for the Eclipse Foundation.
      • There are insufficient resources for the high support costs from this type of effort.
      • TPTP Test will monitor but not pursue this effort.
      • In the meantime TPTP will become an exemplary host of itself to demonstrate and validate the capabilites.
    • TPTP Book:
      • An abstract and outline has been drafted.
      • ACTION" Paul - The outline will be posted to the TPTP web site to solicit authors for each chapter.
    • TPTP WIKI (http://wiki.eclipse.org/index.php/TPTP):
      • Lightweight facade for other public TPTP mediums (e.g. news group, mailing lists and web site).
      • COSMOS has a reasonable entry point wiki pageACTION: Harm to request help from the COSMOS writer
      • Open forum for dynamic web-based content (e.g. discussion and meeting minutes) but not a replacement for the other public TPTP mediums (e.g. news group, mailing lists and web site).
    • 2Q07 TPTP F-2-F:
      • Proposed for May 2007 as a time ot close the post 4.4 plan.
      • IBM US location (e.g. Raleigh or Austin).

Day Three (January 11, 2007)

  • Other Topics
    • Emma Integration
      • Motivation is to provide support to TPTP in order to optimize the test suites. This function has also been requested by the Jazz team and other projects.
      • Test Project will assume the responsibility for integrating Emma (Java line level code coverage) with TPTP 4.4 as a Technology Preview.
      • Assigned resources are pending the 4.4 resource plan however this iwll be treated as sustaining work due to the great need in TPTP itself.
      • ACTION: Paul - An enhancement (and Description Document) will be created for 4.4.
      • Paul will investigate the cost of integrating Emma (Java line level code coverage) with TPTP and report back to the PMC/PG next Wednesday.
      • Guru will investigate the cost of integrating PIN (C/++ line level code coverage) with TPTP and report back to the PMC/PG next Wednesday.
      • Emma will eventually replace the existing line level code coverage (LLC) in TPTP whihc is tech preview and will be depricated.
    • IAC
      • Topic:
        • Replace the RAC code in the IAC with the Agent Controller.
      • Issue(s):
        • The Agent Controller prototype uses only sockets for communication.
          • Proper use case data needs to be collected to determine of this is actually scalable. The shared memory approach was developed to increase bandwidth of data communications, and remove the need for socket administration whihc is a security problem for some users.
        • The RAC uses shared memory pipe for communication.
        • The disadvantages with using the Agent Controller include:
          • Socket-based communication is considered inefficient compared with shared memory communication, but we need fresh data to prove either way.
          • The TPTP launch configuration detects the availability of the Agent Controller by determining if the named pipe is available. The socket approach although simple to maintain does not have a parallel convienence.
          • The Agent Controller-based prototype IAC does not currently support the compatibility layer. As accurate estimate is required since this has been done in the out of process AC on both windows and linux although the linux support has not shipped yet..
          • Socket versus shared memory pipe performance benchmarks will not be completed until February 9, 2007.
          • The Agent Controller-based IAC will be deferred to 4.4. i2.
          • This issue is tightly coupled to the TIagent discussions already captured since Java 5 and TI based profiling needs to coexist with other user function. This coexistance and cross use case support has also not even been attempted at this point.
    • Miscellaneous:
      • We will still have a PMC/PG call on Wednesday (January 17, 2007) despite Harm and Sri's absence to discuss 4.4 defect sizings per project.

Back to the top