[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tptp-monitoring-tools-dev] Request approval for doc fix (requires new plug-in and update to a feature)


I approve approach #1.


Dave N. Smith
Data Collection Tooling                          
IBM Toronto Laboratory
smith@xxxxxxxxxx




Ruth Lee/Toronto/IBM@IBMCA
Sent by: tptp-monitoring-tools-dev-bounces@xxxxxxxxxxx

02/06/2006 04:15 PM

Please respond to
TPTP Monitoring Tools Project developer discussions <tptp-monitoring-tools-dev@xxxxxxxxxxx>

To
tptp-monitoring-tools-dev@xxxxxxxxxxx, tptp-testing-tools-dev@xxxxxxxxxxx, tptp-tracing-profiling-dev@xxxxxxxxxxx
cc
Subject
[tptp-monitoring-tools-dev] Request approval for doc fix (requires        new plug-in and update to a feature)






Dave, Christophe, this defect can be fixed in one of two ways, and I need you two to agree on which of the approaches should be taken.


Test: https://bugs.eclipse.org/bugs/show_bug.cgi?id=144905 Need some description of the BIRT reports

Monitoring: https://bugs.eclipse.org/bugs/show_bug.cgi?id=145142 Need some description of the BIRT reports

Trace: https://bugs.eclipse.org/bugs/show_bug.cgi?id=145143 Need some description of the BIRT reports


The technical review found a hole in the documentation: we have no topics describing the BIRT reports in Test, Monitoring, or Trace.


Approach #1 (the 'right way'):

To fix this problem, the right way to fix it is to:

       1. Create a new BIRT doc user plug-in in Test, Monitoring, and Trace.

       2. Add a new topic into each of the new plug-ins.

       3. Update each BIRT feature in each Project to include their new plug-in.


Technically changing a feature is considered breaking API, but in this case I think that we can make this change without breaking consumers. Because each Project already lists Platform as a prerequisite, and org.eclipse.tptp.platform.doc.user is part of that prerequisite, adding new doc plug-ins into a feature will not add any new dependencies that the consumers need to pick up. Thus the consumers' build will not be broken and I believe that it is safe to make this change to the features.


Approach #2 (the 'backup'):

I do have a backup plan if the 'right way' is not approved, and that involves temporarily adding a single file to a platform doc user plug-in and changing the content of that file dynamically. It would be an abuse of the intent of the Help system's dynamic help support, but it's doable if changing features is considered too risky.


Thank you,

Ruth.



Ruth Lee
IBM Toronto Lab
ruthdaly@xxxxxxxxxx
T/L 969-4453
_______________________________________________
tptp-monitoring-tools-dev mailing list
tptp-monitoring-tools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tptp-monitoring-tools-dev