Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] Committer vote required for M10 check in



Joe, I have no issues with these defects being committed.  YES

Richard K. Duggan
Problem Determination Enablement
IBM Toronto Laboratory
External: 905-413-2396
Internal: 969-2396



                                                                           
             Joseph P Toomey                                               
             <jptoomey@xxxxxx.                                             
             com>                                                       To 
             Sent by:                  hyades-dev@xxxxxxxxxxx              
             hyades-dev-admin@                                          cc 
             eclipse.org                                                   
                                                                   Subject 
                                       [hyades-dev] Committer vote         
             05/26/2004 12:08          required for M10 check in           
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
                hyades-dev                                                 
                                                                           
                                                                           





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



Back to the top