|[wtp-dev] Minutes of WTP Status Telecon, 2005-06-23|
1. Review of Open Action Items
1.1 2005-06-09 [ACTION] TimW will propose a change notification policy.
Arthur - TimW posted a proposal to the PMC list. . Please review and comment.
Tim W - I posted an updated proposal .
Arthur - I agree with the guidelines with one addition. We aslo need to remove @since tags as corrective action arising from the Release Review preparation session we held with Bjorn Freeman-Benson.
Chuck - We used @since to indicate J2EE spec level.
Arthur - We need to comply with the Eclipse Foundation guidelines which specify that @since is to be used for Platorm APIs. You can use another tag to indicate spec levels. We can also replace @since, with @plannedfor to simpilfy maintenance.
Tim D - Are unknown tags ignored?
David - Yes.
[RESOLVED] We will follow the guidelines, including the @since corrective action, posted in  during the endgame.
1.2 2005-06-16 [ACTION] Jeffrey to post proposed wording of the bug verification automatic reminder note on the wtp-dev list for comment.
Jeffrey - DONE
1.3 2005-06-16 [ACTION] Component leads to defer fixing internal API violations to WTP 1.0 M8 since the focus of WTP 0.7 is end-user tools.
Jeffrey - DONE
1.4 2005-06-16 [ACTION] Jeffrey to fix Bugzilla 82185  which tags releng component build scripts and maps.
Jeffrey - I submitted a patch to Bugzilla. I am waiting for David and Naci to review it before I commit it.
David - I'll review it. Should we tag each build? Certainly each I-build. Why not tag them all?
Arthur - Even is we don't recreate the builds, it makes comparing source code easier. You can at least find the source used for a build.
Jeffrey - Does Eclipse tag I-builds?
David - Yes.
Jeffrey - Naci was concerned about tagging I-builds.
David - Perhaps this is a UI problem. Too many tags make some views hard to read. Jeffrey should tag all builds except Nightly builds
[RESOLVED] We will tag all builds except Nighlty builds. We will not retag Milestone builds since they will already have valid tags.
2. CVS Commit Comments
Part of our shutdown process is to include the bug number in every CVS commit comment. The commit comment must be prefixed with the bug number in square brackets, e.g.:
 Fixed the foo widget.
Most people are doing this. Thx. However, many commits to releng, e.g. for maps, do not have proper CVS comments. Let's review the policy.
Tim D - What if there are many bugs associated with a map.
Arthur - Pick one.
[RESOLVED] We will include a bug number in all releng cvs commit comments. Pick any bug associated with the code being released.
3. Bug Status
Jeffrey has posted a Web page that contains the Bugzilla queries we need to review the status. 
Component leads should be prepared to summarise the status of their components with respect to the following metrics.
3.1 Backlog of Resolved but Unverified, and Verified but Unclosed Bugs
Arthur - There are currently 802 unverified bugs. We need to filter this list to include only those that are 2 weeks old and group these by component. Component leads will have responsibility for following up with reporters to verify the resolved bugs, and to ultimately close them. We should also review the list of reports with unverified bugs more than 2 weeks old, and sort this by number of bugs to see the "Top 10" most delinquent reporters.
3.2 Backlog of Bugs in Inboxes
Arthur - At present we have 102-bugs in the inboxes. We previously agreed to use the inboxes only for unreviewed bugs. Components leads should review these and reassign them to someone, possibly themselves. It doesn't take a lot of time to resassign bugs out of the inboxes. Let's have a target of 0 by next week.
3.3 Review of Major, Critical and Blocker Bugs not Targetted to 0.7
Arthur - We have 67 serious bugs that are not targetted for 0.7. We need to have a good reason for deferring any serious bug, where serious means a Severity of major or higher. These reports should be grouped by component. We also need to filter out the bugs that have a rationale for deferal. After this meeting I received a suggestion that the rationale be added to the comments and that the Priority be set to P4. Let's use this process.
3.4 Backlog of Major, Critical and Blocker Bugs Targetted to 0.7
Arthur - We have 40 serious bugs now. These need to be grouped by component. We'll use these meetings to review the status. Each component lead should review their plans for reducing this number to 0.
4. Other Issues
Arthur We held pre-release review this week with myself, Tim W and Bjorn. We are in good shape except for incorrect @since tags in the source code.
Tim W- We will send out the chart deck for review soon. Some IP items need to be closed. The review is scheduled for July 6, 10am EDT.
David - The I-Build is scheduled for tonight at 6PM. Is there any more code to be released?
Jeffrey - WS folks have a blocking bug for J2EE project creation.
Chuck - The fix was released last night.
Rational Desktop Tools Development
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
Back to the top