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

TPTP Jan 07 face to face

Revision as of 16:45, 10 January 2007 by Paulslau.ca.ibm.com (Talk | contribs) (→‎Agenda topics January 9/10/11, 2007)

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
  • Role Changes
    • Joanna is proposed to assume the Platform.Execution(Execution) and Platform.Execution.Framework (Execution: Framework) components. The current component owner(s) will nominate Joanna to assume ownership.
    • The build componet will be expanded to include release engineering and web site management.
    • 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):
      • Paul Slauenwhite
      • Dave Smith
      • Joanna Kubasta [coordinated with committer nomination]
      • Guru Nagarajan
    • AG will determine the Europa packaging categories.
    • A committer 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).
    • The owner of the componet described by the product documentation will be responsible for the technical review of the documentation once per release (post UI 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)
    • Committer matrix will be made dynamic (as prototyped by Hubert last year) based on CVS and Bugzilla.
    • 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 componet per project to include the Eclipse-based samples/examples shipped with the TPTP run-time/SDK. The project leads will be the componet leads for these components.
    • 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.
    • 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
  • 2006 in Reflection
    • Discussion of IBM's post mortem of TPTP 4.3.
      • Concern: Reasons for missing the 4.3 release deadline.
      • 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:
        • Committers 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.
      • 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.
        • 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 Trace project will investigate using PIN for code coverage of TPTP's native code.
        • The Test project will discuss how the Trace project's JVMTI test infrastructure, test dashboard (https://bugs.eclipse.org/bugs/show_bug.cgi?id=112928) and the Agent Controller and Profiler test server can be integrated with the Test tools.
      • 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.
      • 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.
      • 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
          • Investigations
        • 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.
      • 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 was the result of unclear communication.
        • 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.
        • 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.
      • Committers will be encouraged to work here but to also communicate the activity with AG.
      • Subject matter is typically related to "help wanted" enhancement or things generally perceived as good for TPTP including samples, tutorials, build tools, enhancements.
  • Defect Backlog Plan
    • Test
      • Currently 260 active defects.
      • Each committer will focus on reducing the defect backlog early in 4.4.
      • Each committer 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.
    • 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.
      • Lead committers will determine what defects they feel can be resolved 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.
    • Internal API Usage:

Day Two (January 10, 2007)

  • TPTP 4.4 Enhancement Update
    • Stage 1
      • COSMOS and TPTP data collection and storage discussion.
        • Mark Weitzel will post the architectural slides on the TPTP WIKI.
        • TPTP Use Case: Scalability for all TPTP models using an abstract data persistence layer.
      • WSDM:
      • BtM:
      • 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:
          • Object reference graph
          • Thread Analyser
          • Launch configuration (attach)
          • Trace data aggregation
        • 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:
        • Core JVMTI API and UI changes are approved for GA in 4.4.
        • Concern with resources for code/peer review.
    • Stage 2
      • Emma Integration
      • IAC
  • 'Reducing Platform Coverage
  • 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 P1.
      • Highly desirable and planned for 4.4 but not stop ship are P2.
      • Unsupported platforms are set P3.
    • 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
    • Assessment of contribution levels
    • In TPTP 4.4, only the following core platforms will be refreshed:
      • Windows (x86, EM64T, IPF)
      • Linux (x86, EM64T, IPF)
    • All other platforms will be in sustaining mode based on the 4.3.0 code base and will only support Java 1.4.x and 1.5.x.
    • JVMPI in 4.4 is constrained to Java 1.4.x with JVMTI will support Java 1.5.x run-times.
    • JVMTI will only be supported on the core platforms.
    • Existing agents (e.g. logging, comptest, etc.) will continue to be supported and packaged on non-core platforms based on the 4.3.0 code base.
    • Assess future maintenance streams
  • Other Topics
    • Foundation level conformance and quality testing framework
    • TPTP non-fiction book plans
    • Propose use of TPTP wiki for discussion and minutes but not as a substitute for other controlled forums.

Day Three (January 11, 2007)

Retrieved from "https://wiki.eclipse.org/index.php?title=TPTP_Jan_07_face_to_face&oldid=22635"

Back to the top