Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Minutes of WTP Status Telecon, 2005-06-16

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


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.
                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.
                Arthur - TimW posted a proposal to the PMC list. [1]. Please review and comment.


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


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


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

Back to the top