Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

WTP 2008-07-10

WTP Development Status Meeting 2008-07-10

Attendees

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

Announcements And Reports

Focus on Requirements Planning (Raghu)

  • Minutes:
Raghu:
willSend out a note to dev list today
have defined the steps, July 24th, similar process, tracking using wiki, simpler, enter bugs for the bugzilla, standard format, using bugzilla as main feature plan

WTP 2.0.3

Schedule

June 27 - M build
July 3rd - RC1 build
July 10th - RC2 - Final build
July 11th - 2.0.3 GA
  • Minutes:
Smoketest issued, pls complete by Friday for 2.0.3 GA

WTP 3.0

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.

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:
Smoketest issued, our first M build, pls complete smoketest

WTP 3.1

Schedule

  • Assuming the regular 6 week cycle, 1 week plan, 4 weeks dev, 1 week testRC5 -> June 16th 2009
Planning 10th
July 14th -> planning week
July 21st -> August 18 => 4 weeks of dev
August 18th => 1 week of test
M1 -> August 22nd
M2 -> Oct 3rd
M3 -> Nov 14th
M4 -> Jan 5th 2009
M5 -> Feb 16th 2009
M6 -> April 6th 2009
M7 -> May 5th 2009
RC1 -> May 19th 2009
RC2 -> May 26th 2009
RC3 -> June 2th 2009
RC4 -> June 9th 2009
RC5 -> June 16th 2009

Performance Focus (Kaloyan)

Kaloyan:

Not going well
startover again, start with something small and involve more ppl from WTP
Discuss more in the next mtg, hope to have more ppl involved
David: Each project team to contribute a person to help out with this, if no volunteers, then we may need to abandon this, we'd need ppl and resources, think about this and we'll decide next week

API Tools/Scans (Kaloyan)

Kaloyan:

Our official 3.0 has adopter breakage report ready.
The report will be run for every 3.x and 3.0.x declared build.
Do you we need the report for the 2.0.x declared builds?
  • Minutes:
Nothing new
David: Not needed for the 2.0 stream
Kaloyan, can remove this section
DaveC and DavidW: will look into diff reports
No progress to report, yet.

Other business

Project leads: please fix meta-data during July. Especially, see "information about ..." from your subproject web page left nav bar.
Changes coming to IP Log management (more automated, but more for Project Leads to do?): See http://wiki.eclipse.org/Development_Resources/Automatic_IP_Log
In the works: Proposal to adjust bugzilla so bugzilla "products" match our subcomponents (currently have 4, need about 8?)

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