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 "WTP 2008-06-25"

(WTP 3.0.1)
(WTP 3.0.1)
Line 163: Line 163:
  
  
<ul>
+
 
 
<li><a href="http://www.google.com/calendar/feeds/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic">XML</a></li>
 
<li><a href="http://www.google.com/calendar/feeds/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic">XML</a></li>
 
<li><a href="http://www.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL</a></li>
 
<li><a href="http://www.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL</a></li>
</ul>
 
  
  

Revision as of 16:29, 25 June 2008

WTP Development Status Meeting 2008-06-25

Attendees

Project Leads
Konstantin
Tim
Nitin
Kathy
Chuck
Naci
Raghu
Neil
David
Helen
Philippe
Committers
Bob
Carl
Dave
Phil
Kaloyan
Larry
Amy
Kate
Angel
Brad
Valentin
Gary
Friends
Nick
Gilbert

Announcements And Reports

Focus on Requirements Planning (Raghu)

Raghu: start talking about planning ... soon?

WTP 2.0.3

Proposed Schedule

June 27 - M build
July 3rd - RC1 build
July 10th - RC2 - Final build
July 11th - 2.0.3 GA


WTP 3.0


  • The 3.0 Release pages should be reviewed by everyone to ensure accuracy. Information or screenshots in the New and Noteworthy may need updating, and there is a page for Release Notes. Good candidates for release notes include major fixes that were deferred to 3.0.1.


Schedule

Ganymede 06/17
Code done by Wed. 6/11
Smoke tests on Thur. 6/12
"Unofficial Declare" on Friday 6/13
Make official on Tuesday 6/17

Builds

  • Currently running
  • Mintues:

Testing

  • Minutes:
Teams need to update the test results

Issues

This bug/issue is not marked fixed ... are we doing anything here?
The help has a file called "Limitations and Known Issues" - this functions as a type of readme so that users can easily search for problems that have known workarounds.

This will be kept in the help, team leads pls review current content and add anything extra

Kate has opened a bug 233531, please use to add updates using comments

Bug Lists to Ramp Down

All Blockers and Criticals (~14)
All Hot Bugs and Requests (~0)
All Remaining Targeted Enhancements (~1)
3.0 RC Blockers/Criticals (~1)
Remaining Targeted Bugs (~45)
Note: a 3.0.1 target was added to bugzilla (not M301 301), to better re-target some of the bugs.
Resolved but Unverified Blockers/Criticals By Assignee (~42)
  • Minutes:
Kaloyan: 3.0P, 1.5.5P targets will be created
use whiteboard to explain how the patch can be provided
will create a wiki page to document this
David: All patches are cumulative

WTP 3.0.1

  • Guideline
In general, the minimum requirement is that if you branch a plug-in, you need to branch all the plug-ins in the corresponding map file. This is to make it easier for others to know what to load, to "be current" in a maintenance branch. It is fine to branch everything in a sub-project if you choose to, but still need to correspond to what's in a map file, and the map file should be updated to explain what it's used for. Map files can be re-organized some, if that helps make it easier to organize and understand what teams are working on what.
The names for branches should follow the pattern of 'R3_0_maintenance'. This will be the name for all 3.0.x maintenance work (not just the first, 3.0.1 maintenance work). Note that JSF and JPA code may use R2_0_maintenance, but their map files, will still be branched using R3_0_maintenance.


  • <a href="http://www.google.com/calendar/feeds/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic">XML</a>
  • <a href="http://www.google.com/calendar/ical/prfk26fdmpru1mptlb06p0jh4s%40group.calendar.google.com/public/basic.ics">ICAL</a>

    • Minutes:
    David: build will be available as early as tonight
    build system wil be slow but this will happen occasionally
    How to add calendars to a webpage
    DaveC: XSLT tooling page
    Helen to embed

    Performance Focus (Kaloyan)

    No progress for the last two weeks. Still fighting with the Results Graph Generator.

    • Minutes
    Kaloyan: a collegue is getting familiar with this, no progress so far

    API Tools/Scans (Kaloyan)

    Can we run reports? Though they are hard to spot errors since out of date ... perhaps we can "diff" reports?

    Other business

    BobF: meta-data: happy to round up the webpage?
    David: some projects do not point to a pheonix style page
    Action: by July: sub-project to get rid of or update pages to be consistent with pheonix style page

    Teams Status and Focus for Coming Week

    Source Editing

    • Ongoing triaging of incoming bug reports
    • Working on updating bug backlogs
    • Triaging remaining 3.0 requirements and targeted bugs

    Server Tools

    Web Services/WSDL

    1. Ongoing triage of incoming and existing bugs.
    2. Fixing and verifying bugs.

    Java EE

    Dali JPT

    • JPT 2.0
      • Working on:
        • EclipseLink support
        • Bugs for M7
        • Performance

    JSF

    • Feature exceptions
    • Bug Fixes

    releng

    • tweaks to downloads page, 202 patch builds, prepare 301 maintenance builds, better integrate Incubation Builds, integrate production of update site via cruise control tasks.

    References

    In general, the minimum requirement is that if you branch a plug-in, you need to branch all the plug-ins in the corresponding map file. This is to make it easier for others to know what to load, to "be current" in a maintenance branch. It is fine to branch everything in a sub-project if you choose to, but still need to correspond to what's in a map file, and the map file should be updated to explain what it's used for. Map files can be re-organized some, if that helps make it easier to organize and understand what teams are working on what.
    The names for branches should follow the pattern of 'R3_0_maintenance'. This will be the name for all 3.0.x maintenance work (not just the first, 3.0.1 maintenance work). Note that JSF and JPA code may use R2_0_maintenance, but their map files, will still be branched using R3_0_maintenance.
    • Instructions for tagging existing and new WTP wiki pages can be found at WTP's Category page; remember, we can create subcategories as well
    • This Week's Smoke Test Results
    WTP Smoke Test Results R30
    Information about process for milestone bugzilla line item planning has been added to the WTP Bugs, Workflow, and Conventions document.
    PMC Candidate Review Request Checklist - See the updated PMC Review document with attention to the "How To Prepare a PMC Defect Candidate" section
    Adopter Migration Information for WTP 2.0 - Please add any details for your component.
    • Website
    Documentation on Setting up your system for Web Tools Web site development and Using Web Tools Phoenix PHP templates is on the wiki at Web Tools Web Site Development.
    • Bug Day
    Monitor and participate in Bug Day if you would like.
    Mark any applicable bugs with keyword "bugday", but only if you'll have a representative on hand to respond through Bugzilla or in IRC
    Current WTP Bug Day bugs (~53)

    Release Review Requirements References

    IP Log

    • In general, Project leads should review our IP Log for completeness and correctness.
    • non-Committer Contributions
    * bugzillas with contributed patches should be marked with contributed keyword
    * There are some WTP IP Tools to help explore potential contributions.

    Copyrights

    • Make sure copyrights are up-to-date and according to Eclipse Foundation form:
    See Default Eclipse Foundation Copyright and License Notice

    Check for "license files"

    • Check 'about.html' files exists
    • are valid
    • have correct "layout" in directories
    • References:
    In the general eclipse legal section
    http://www.eclipse.org/legal/
    Is one page that speaks to the about files directly
    http://www.eclipse.org/legal/epl/about.php
    In particular, note there are two that refer to literal HTML only versions, to use as your starting point.
    http://www.eclipse.org/legal/epl/about.html
    http://www.eclipse.org/legal/epl/longabout.html
    Also, please read
    http://www.eclipse.org/legal/guidetolegaldoc.php#Abouts
    It goes into detail about the locations, needs for plugins and features, and also mentions that third party content requires a seperate license file.

    Bug Backlogs

    All Untriaged WTP Bugs (Graph)
    All Untriaged WTP Bugs (~244)
    All WTP Verified, Not Closed Bugs (Graph)
    All WTP Verified, Not Closed Bugs (~398)
    All WTP Resolved, Unverified Bugs (Graph)
    All WTP Resolved, Unverified Bugs (~2098)
    All WTP Defect Backlog (Graph)
    All WTP Defect Backlog (~3131)
    All WTP Future Bugs (~422)
    All Open WTP Bugs with Patches Attached (Graph)
    All Open WTP Bugs with Patches Attached (~205)
    All API Requests (~9)


    Back to WTP Meeting Archives

    Focus on Backlog and Quality metrics (Neil)

    Current Focus Item
    • Options are
    • Target bug for a release or "future"
    • Mark as Invalid or Wont Fix
    Upcoming Focus Item
    Past Focus Items
    • Invalid - Enhancement does not fit with the scope of the project or is already implemented.
    • helpwanted keyword - This is a valid request, but due to committer resources and other priorities, outside help will be needed to make this happen.
    • Future - I would use this in conjunction with the helpwanted keyword. I use this for legitimate requests that are important but will not make any planned release, but likely will make a future release.
    • Before July 1st, 2007 - 21
    Where did they all go?
    • Minutes:
    Neil: will focus on untargeted enhancements again after Release of 3.0

    Back to the top