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

WTP 2008-06-25

Revision as of 19:46, 26 June 2008 by Hjzhang.ca.ibm.com (Talk | contribs) (Bug Lists for 3.0.1)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

WTP Development Status Meeting 2008-06-26

Attendees

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

Announcements And Reports

WTP 3.0 released! Congratulations & Thanks everyone!

Marking bugs for official patch

No meeting next week 07/03/2008

Focus on Requirements Planning (Raghu)

  • Minutes:
Raghu: main wiki page for the next release => next Thursday
July 21st: 1st round of enhancement, add a 'Plan' keyword in bugzilla
Project plan in a standard format
Final cut for plan document August 22nd
Instructions will be posted on the wiki page

WTP 2.0.3

Schedule

June 27 - M build
July 3rd - RC1 build
July 10th - RC2 - Final build
July 11th - 2.0.3 GA
  • Build
  • Smoketest
  • Minutes:
Proposed schedule is official
smoketest will be issued tomorrow morning and driver to declare later in the day

WTP 3.0

Bug Lists

3.0 JST, WST, JSF Bugs Fixed (~1101)
3.0 JPT Dali Bugs Fixed (~229)
All Remaining Targeted Enhancements (~1)
Remaining Targeted Bugs (~6)
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 (~40)
  • Minutes:
Only 6 bugs left targeted to 3.0 to clean up
40 unverified resolvered blockers/criticals to close

WTP 3.0.1

Schedule

  • 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.
  • Build
  • Test

Bug Lists for 3.0.1

3.0.1 Blockers & Criticals
All 3.0.1 Hotbugs (~1)
Current 3.0.1 targeted bugs (251)
  • Minutes:
First M build to be declared on 7/11
Smoketest will be issued on 7/10

Performance Focus (Kaloyan)

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

  • Minutes
Kaloyan: still stuck, no updates 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?

  • Minutes:
DaveC: will look into diff reports
Kaloyan: will run reports on our released build next week

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