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


I vote yes
Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,  
phone:905-413-4032   fax: 4920  
cell: 416-432-9754
mailto:sluiman@xxxxxxxxxx
Admin : Gabrielle Chapman chapmaga@xxxxxxxxxx  Tie: 969-2323



Eugene Chan/Toronto/IBM@IBMCA
Sent by: hyades-dev-admin@xxxxxxxxxxx

05/25/2004 07:32 PM

Please respond to
hyades-dev

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






The following M10 defects require Committer's approval: (I vote YES)


Target drop date to cvs:        May 26 afternoon EST

Target regression test date:May 26 afternoon EST

Target candidate drop:        May 27 (pass 2)


Defect 62033
:
bugzilla_62033 --
Move navigator extension sample to trace.sample plugin

Rationale
:

Currently, the hyades navigator extension sample is located in the org.eclipse.hyades.ui.sample plugin. This is the wrong place, because this sample is packaged with the Test zip, not the Examples zip. The sample should be moved to trace.sample, since it is extending the profiling monitor. The reason it is packaged in the Test zip is because the SVG generator is incorrectly located in this sample plugin, but is required by hyades. SVG generator to be moved after 3.0.


Risk Assessment
:

No API change. The fix is to move the sample from the ui.sample plugin to the trace.sample plugin.

Medium risk change.



Defect 63850
:
bugzilla_63850 --
hyades.ui plugin startup routine: refactoring needed

Rationale
:

In HyadesUIPlugin.startup() we had 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). Has been tested by Test team.



--------------------------------------------------------------------
Eugene Chan
IBM Toronto Laboratory
D3/ENW/8200/MKM
Voice:   1-905-413-6102
Email:  ewchan@xxxxxxxxxx