[wtp-dev] Minutes of WTP Status Telecon, 2005-06-16

[Arthur Ryman <ryman@xxxxxxxxxx>]

Attendees:
Gorkem Ercan, Gerry Kessler, Raghu Srinivasan,
Paul Meijer, Thomas Yip, Karl Lum, Rankin (Buji) Kern,Thomas
Yip, Hoi Lam, Konstantin Komissarchik,  Arthur
Ryman, Chris Brealey, Chuck Bridgham, Craig Salter, David Williams, Jeffrey
Liu, John Lanuti, Kathy Chan, Keith Chong, Lawrence Dunnell, Lawrence Mandel,
Nitin Dahyabhai, Sheila Sholars, Susan Yeshin

Minutes

1. Review of Open Action Items

1.1 2005-06-09 [ACTION] Arthur
will get WTP 1.0 M8, M9, and M10 targets added to Bugzilla.
        2005-06-16

         
      Arthur - Targets for both WTP 1.0 and WTP
1.5 have been created. DONE

1.2 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.

[1] http://dev.eclipse.org/mhonarc/lists/wtp-pmc/msg00099.html

1.3 2005-06-06 [ACTION] Arthur
will request a new mailing list and CVS commit notifications.
        2005-06-16
         
      Arthur - We now have 3 cvs mailing lists.
JST [1], WST [2], releng [3]. Please subscribe. DONE

[1] https://dev.eclipse.org/mailman/listinfo/jst-cvs-commit
[2] https://dev.eclipse.org/mailman/listinfo/wst-cvs-commit
[3] https://dev.eclipse.org/mailman/listinfo/wtp-cvs-commit

2. WTP 1.5 Milestones Proposal

The PMC has proposed the following dates:

1.5 M1 - 2006-02-24
1.5 M2 - 2006-04-21 
1.5 M3 - 2006-06-16 
1.5 M4 - 2006-07-14 (end game) 

3. Bug Handling Process Proposal

We need to establish a WTP process for
handling bugs. Here's a strawman proposal:

a) Automatic email notifications will
be send out once a week to anyone who reported a bug that is waiting to
be verified. See [2] for an example.  Developers should then close
the verified bugs. We will review the unverified and unclosed  bugs
weekly and take corrective action for old bugs.

Daivd - This might be overkill. Yet
another message to deal with.
Arthur - What about having a 2 week
grace period? You don't get a note unless a fix has been waiting to be
verified for over 2 weeks? This only happens during shutdown phases.
Paul - We think a weekly nag is useful.
David - We need to give more direction
on which build to verify the fix on.

Arthur - OK, we'll send out these notes
only during shutdowns for fixes older than 2 weeks and the note will give
guidance on which build to use to verify the fix.
[ACTION] Jeffrey to post proposed
wording of the note on the wtp-dev list for comment.

b) Component owners should reassign
bugs that are currently assigned to an inbox id. We will review the inboxes
weekly and take corrective action for old bugs.

Arthur - The goal here is to show that
the bug has been reviewed. By moving it out of the inbox id that signals
it has been looked at.
Thomas - Can I be notified of bugs that
get added added to the inbox?
Lawrence - Yes - there is a Bugzilla
preference.

David - What is the purpose of reassigning?
Arthur - To ensure that new bugs are
reviewed.
Jeffrey - The bugzilla workflow is not
clear. When a bug comes in it is in the New state. They should be assigned
to someone, not necessarily targetted though.
David - I look at all the bugs in the
inbox. If it belongs there I leave it until someone is ready. Otherwise
I reassign it to the right inbox.
Jeffrey - How about assigning it to
yourself?
David - That's misleading since I'm
not actually working on it.
Craig - Leaving it unassigned may encourage
people to work on it.
David - The problem is to ensure that
the bug has been reviewed.
Arthur - How about just adding a comment
? Can we query to determine if a comment has been added?
Jeffrey - I'll look into that.
David - We can also add keywords to
fields. Maybe add a "Triage" keyword.
Jeffrey - There are restrictions on
who can add keywords.
Sheila - Is there an Accepted state?
Jeffrey - No.
John - What's wrong with assigning it
to the responsible component lead?
Nitin - Assigning it is like adding
a comment.
David - John's idea is ok. So we should
reassign it to the right component lead, and leave it in the New state.

Arthur - We agree that we will signal
that a bug has been reviewed by reassigning out of the inbox id. Don't
target it until the work can actually be performed. This will let contributors
find bugs to fix.

c) Bugs should be accurately targetted.
If the target is known, assign it. Otherwise leave it as unspecified to
avoid raising false hopes. We will review the bugs assigned to the current
release weekly. Also, any major bugs that are not targetted to the current
release should have a good rationale for being defered.

David - I agree 100%.

d) We will review the major bugs targetted
to the current release weekly.

All agree.

e) Defer fixing internal API violations
to WTP 1.0 M8 since the focus of WTP 0.7 is end-user tools.

Lawrence - Are these bugs in our code
or in the platform?
Arthur - Both are possible. If they
are against the platform we need to have enhancement requests.
Jeffrey - Eclipse won't fix them in
3.1 so we should defer them until 1.0 M8.
Chuck - I agree.
Arthur - Since these won't get fixed
we should defer the work.
[ACTION] Component leads to defer
these bugs to 1.0 M8.

f) Defer most other non-user impact
fixes to at least WTP 1.0 M8.

David - Don't disagree in principle.
There are some things we should fix up. They are classified as ARC (for
Architecture) and Major. There are some major violations of architecture.

Arthur - OK, but major end-user bugs
get higher priority.
David - There is not a lot of time until
WTP 1.0 ships so we have to start addressing them.
Arthur - OK, but we need to consider
how much it destabilizes code. If a lot then defer to WTP 1.0 M8.

4. Other Business

David - What is the opinion of our I-Build?
We have some JUnit failures that we can't reproduce on Windows. We have
had code released after the I-Build which means you want 
Nitin - I released a fix for relative
URL resolution. I am requesting a rebuild.
David - Has anyone done testing on other
aspects? I will respin the build tonight. Do smoke testing on Friday morning
and we'll declare the I-Build Friday afternoon.
Kathy - We have a blocker in the current
I-Build. J2EE has a fix. Bugzilla 100308. [1]
Chuck - We'll release it for the I-Build.
I'll coordinate with David.
David - Would the WS team please fix
their build properties before 7pm tonight? (Unnecessary source). Please
release before the I-build.
Chris - Will do.
Arthur - Why aren't we tagging the releng
component? We can't really reproduce a build unless be use the original
build scripts and maps.
David - Bugzilla 82185 [2] was opened
for that but it requires someone familiar with the build scripts to fix.
[ACTION] Jeffrey to fix this
Bugzilla 82185

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=100308
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=82185

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/