Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Minutes of the WTP Status Telecon, 2006-05-11

See WTP Status Telecons [1] for more information.



Amy Wu

Arthur Ryman

Chris Brealey
Chuck Bridgham
David Williams
Der Ping Chou
Jeffrey Liu
John Lanuti

Kathy Chan

Keith Chong
Konstantin Komissarchik
Larry Dunnell

Lawrence Mandel

Nitin Dahyabhai

Rob Frost
Steve Francisco
Ted Bashor
Thomas Yip
Tim Deboer

Tim Wagner

1. Actions Items - Jeffrey Liu

Active Items

The following actions items showed some activity last week. [1]
136717 nor P3 PC katep@xxxxxxxxxx NEW [action] WS: Review and identify changes in WTP 1.5 that ...
136716 nor P3 PC csalter@xxxxxxxxxx CLOS FIXE [action] XML: Review and identify changes in WTP 1.5 that...
136720 nor P3 PC dpchou@xxxxxxxxxx CLOS FIXE [action] RDB: Review and identify changes in WTP 1.5 that...

3 bugs found.

Open Items

The following action items are currently open [2]. Action items owners should update their status in Bugzilla prior to the status telecon. Thx.

136717 nor P3 PC katep@xxxxxxxxxx NEW [action] WS: Review and identify changes in WTP 1.5 that ...

One bug found.



2. Help the community select the right component for bugs - Arthur Ryman

- We'll update the components page [1] with better descriptions and the names of QA contacts. Each component should suggest an improved description and a QA contact.

- When reporters don't pick the right component, committers should add a boilerplate message describing how to pick the right one. The text will be added to the Committer FAQ [2]

"Thank you for reporting this bug. It has been assigned to the appropriate component.
For guidance on how to select the appropriate component in future bug reports, please see"



Arthur - Update QA contact info.

Jeff - wst.command (Environment Command Framework), this component doesn't really mean anything to end users. Do we really want to keep it? It seems to make things more confusing.

Arthur - Before we remove any components, we need to check with the Webmaster on the life cycle of components

Tim - We need to make sure the bugs don't sit there for a long time.

Arthur - They should be reassign to the default QA contact.

Jeff - Any Eclipse doc that say how long a bug can sit before it is triaged?

Arthur - No.

3. WTP 1.5 to WTP 2.0 Interoperability - Arthur Ryman

- The requirements be clarified  by the PMC [3]

- discuss how to support these requirements. In particular:

“A WTP 1.5 should also be able to work on projects created by WTP 2.0 users and shared via a repository. Any new artifacts creates by WTP 2.0 should not break WTP 1.5. WTP 1.5 should either ignore or tolerate any new artifacts created by WTP 2.0.”

- do we have any "brittle" code in WTP 1.5


Arthur - Defining requirements for WTP 2.0. We need to be explicitly on what our requirements are for migration. We need to make sure users can use WTP in a mix environment.

Arthur - Not require workspaces to be sharable, but projects should be.

Arthur - We can add new features, but we should not force users to upgrade.

Arthur - If compatibility must be broken, then a new type of project should be created.

Konstantin - How about a manual switch to convert projects to pure 2.0 project?

Arthur - Have seen this kind of thing in Derby. There's nothing wrong with these kind of migration utilities.

Arthur - The immediate action now is to think about potential problems. And if possible, remove code that causes interoperability problems down the road

Chris - We need to make sure we do not accidentially upgrading the Axis jars (that we put into the users' project) from a previous release or visa versa. Mixing different version of Axis jars in the same project will sure be messy.

4. WTP 1.0.3 Status - David Williams

The first time something is released to a plugin for 1.0.3, its version's service number should be bumped up by one. Plus, we do not yet, have a good "automatic" solution for incrementing effected feature version qualifiers, and in the worst case, will have to do so "manually", by tagging/releasing the cvs version of effected features ... both so the features service number is changed the first time, one of its contained plugins change, and from then on, change it qualifier (cvs version tag) when ever on of its contained plugins change).  

So, if you are the first to release a fix to a plugin, you should up the version's service number, AND, I suggest, make a note in the bug that you have done so, (and what version was, and what you changed it to) so there will be trace of it, in case that makes it easier to manage this.

The end-goal of all this care in versioning is so that, in principle, someone could "pick up" any build and update a current install with it, and all the right versions would be installed, and right ones picked at run time.

David - We are almost ready to start a build.

David - Be careful with plug-in version changes. The real pain is feature versions because they don't upgrade automatically.

Jeff - Should we update the feature versions at the same time when we update the plugin version?

David - Yes. Also, your plug-in maybe in more than one feature.

Jeff - How do we know if somebody else has already bump up the feature version?

David - Bump it to 1.0.3

Kathy - This is only for the 1.0.3 maintenance stream, correct?

David - Yes.

Jeff - Maybe we can use the "what's fix" tool to help us determine which plug-ins/features were changed?

David - I'll send a note to Naci.

4.1 WTP 1.0.3 approved bugs [1] - Jeffrey Liu


5. WTP 1.5 Status

5.1 WTP 1.5 Build Status - David Williams

David - Smoke test our build. Problems moving up to RC3, our build actually broke because of some old W3C DOM conflict.

David - We'll be removing xerces from the re-export list.

Jeff - Will this break TPTP? They are using our xerces plug-in.

David - No, because we are not removing the plugin. We are just removing xerces from other plug-ins re-export list.

5.2 WTP 1.5 Hot Bugs [1] - Jeffrey Liu


5.3 WTP 1.5 Hot Bug Requests [1] - Jeffrey Liu


[action] Konstantin - document the workaround in the bug and move it off the list. Also confirm that this problem will be addressed in 2.0.

5.4 P1 Bugs [1] - Jeffrey Liu

5.5 Blocking Bugs [1] - Jeffrey Liu

5.6 Bugs to be Triaged [1] - Jeffrey Liu

6. Other Business - Open

Arthur - We have APIs that are refering to non-API types. We need to clean them up.

Jeffrey Liu
IBM Rational Software
IBM Toronto Lab.
8200 Warden Ave. Markham, Ontario, L6G 1C7
Internal mail: D3/UMZ/8200/MKM (D3-268)
T/L: 969 3531
Tel: (905) 413 3531
Fax: (905) 413 4920

Back to the top