Re: [hyades-dev] Committer vote required for M10 check in

[Kent D Siefkes <kdsiefke@xxxxxxxxxx>]

I vote yes,

Kent Siefkes
Rational Software
IBM Software Group

Joseph P Toomey/Lexington/IBM@IBMUS
Sent by: hyades-dev-admin@xxxxxxxxxxx

05/26/2004 12:12 PM

Please respond to
hyades-dev

To	hyades-dev@xxxxxxxxxxx
cc
Subject	Re: [hyades-dev] Committer vote required for M10 check in

I vote yes......... 

Joe Toomey 
Senior Software Engineer
Rational Software
IBM Software Group

Joseph P Toomey/Lexington/IBM@IBMUS
Sent by: hyades-dev-admin@xxxxxxxxxxx

05/26/2004 12:08 PM

Please respond to
hyades-dev@xxxxxxxxxxx

To	hyades-dev@xxxxxxxxxxx
cc
Subject	[hyades-dev] Committer vote required for M10 check in

Some of these are repeats -- sorry for the confusion.

--Joe 


Defect 63867: 
bugzilla_63867 -- Datapool Editor: Value
class values are not being updated correctly.

Rationale:

In this release, we are adding support for Display Value Classes which
allows consumers to customize the Datapool Editor to handle different editors
(for example, a color chooser).  A bug was found by a consumer of
the component noting that the values were not being updated correctly.
 This was due to a missing call to the Display Value Class API.  This
was not an issue for base Hyades because all values are stored as strings
and the default string editor always returned the updated value.  The
fix involves adding a call to the update method of the display value class
and using the updated value.  The fix is currently being tested by
the consumer who found the bug (it is not yet checked into CVS).  Without
this fix, the feature is basically useless for complex editors whose getValue()
does not return the actual value (for example a combo box).

Risk Assessment:

No API change. Does not impact consumers except that value objects get
updated properly. 
Low to Medium risk change. 
Target drop date to cvs:        May 26 afternoon EST
Target regression test date:May 26 afternoon EST
(Peter Sun)
Target candidate drop:        May 27 (pass 2)




Defect: 
bugzilla_62467 -- Execution History
model is not incrementally updated during test execution.
Rationale:
This is a fix to have a lost feature apparently loose when we updated the
execution history viewer: the viewer had the capability to be updated every
n seconds (configurable via preference page) in order to update the current
execution history. 
Risk Assessment 
No breaking API changes. 
Low risk change. 
Dates 
fix: May 27 
regression test: May 28 (Jerome Gout) 



Defect: 
bugzilla_63682 -- Need a programmatic
way to open the highlighting rectangle from the time compression bar to
the interested lifeline 
Rationale:
This is a fix to have the capability to programmatically highlight an event
in the sequence diagram. This is required for BlueRat for highlighting
a event (between 2 consecutive messages) when we move the event bar in
the thread view. 
Risk Assessment:
Isolated code changes in three files: 
     org.eclipse.hyades.uml2sd.ui.TimeCompressionBar.java
     org.eclipse.hyades.uml2sd.ui.SDWidget.java
     org.eclipse.hyades.uml2sd.trace.loaders.BaseTraceInteraction.java
No breaking API changes, but a new API is added 
Low risk change. 
Here is a patch containing what we plan to update:

Dates 
fix: as soon as we have the agreement 
regression test: May 28 (Sebastien Veyriere) 



Defect: 
bugzilla_63860 -- Launch Configuration:
Launch Progress Monitor should stop when TEH fails
Rationale:
This is a fix to  avoid infinite "Launching..." jobs in
the Progress view when a Test launch fails because the Test Execution Harness
throws an exception. These jobs never ends, and cannot be cancelled. They
are not blocking, but they are very confusing for the user who might think
the Test is still running. 
Risk Assessment:
No API change. The fix consists in adding a try
{ ... } finally { monitor.done(); }
block around an existing portion of code in AbstractLaunchConfigurationDelegate
class in test.ui. 
Low risk change. 
Dates 
fix: May 27 
regression test: May 28 (Julien canches) 


Defect: 
bugzilla_63138 -- Manual Test Execution is not available
Rationale:
You can not create a launch configuration for a manual test -- the manual
tests are not listed as available tests in the tree from which you choose
the test to run.  This can be fixed by implementing an extension point,
however, because we must also add the code necessary to prepare the test
to be run, we must add a couple of new classes that will be used by the
extension point implementation.  This portion of the fix is a medium
risk change requiring good testing to validate, but without it, we can
not execute manual tests.  
Risk Assessment:
Medium risk change, extension point implementations (not new extension
points) added to plugin.xml for manual test.  Two additional classes
added to o.e.h.test.manual plugin 
Dates 
fix: May 26 
regression test: May 27 (Joe Toomey) 


Defect: 
bugzilla_63846 -- Test Common plugin startup: refactoring
needed 
Rationale:
This defect is the counterpart to 63850, already approved for the UI team.
 The plugin startup method has a call to Display.getDefault().syncExec().
The platform discourages the use of thread synchronization in the startup()
method as it is prone to deadlocks. This was in fact the case for the Test
team when they were loading this plugin from a worker thread. Normally,
the plugin is loaded from the UI thread.   
Risk Assessment:
No API change. The fix is to first check whether we are in the UI thread
already (the common case). If not, defer the execution via asyncExec().
Low risk change (will not affect the common case).
Dates 
fix: May 26 
regression test: May 27 (Joe Toomey) 


Joe Toomey 
Senior Software Engineer
Rational Software
IBM Software Group 
ForwardSourceID:NT0001591A