| [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.
2005-06-16
Arthur - TimW posted a proposal to the PMC
list. [1]. Please review and comment.
2005-06-23
Tim W - I posted an updated proposal [2].
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 [2] during the endgame.
DONE
[1] http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg00099.html
[2] http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg00118.html
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.
2005-06-23
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.
2005-06-23
Jeffrey - DONE
1.4 2005-06-16 [ACTION] Jeffrey
to fix Bugzilla 82185 [1] which tags releng component build scripts and
maps.
2005-06-23
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.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=82185
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.:
[12345] 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. [1]
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.
[1] http://eclipse.org/webtools/development/bugs/bugs.html
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.
Arthur Ryman,
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
intranet: http://labweb.torolab.ibm.com/DRY6/