Release3.0.0
Was released on 5/31/2001 as planned.
The main theme is modularization, splitting the platform plugin into independent chunks.
This is the list of proposed plugins for core. The Maintainer is the person responsible for making a plan for the release, organize the different contributions and will be the one that decides when the plugin is ready for release (no new features from that point, stable enough). Reviewer should be some other person that validates the plugin (it works for him too, the API is not useless and not intelligible). Contributors are people that believe have elements to be included in that plug-in, want to take care of some aspect or simply want to "help" (up to the maintainer to do the coordination).
||Plugin name || Info || Status || Maintainer||Reviewer(s)|| Contributors || ||org.csstudio.core.feature || Keep track of core plugins || Done || Release manager (Gabriele for 3.0.0)|| One for each site || || ||org.csstudio.core.util.feature || Keep track of core-util plugins || Done || Release manager (Gabriele for 3.0.0)|| One for each site || || ||org.csstudio.auth || Authentication/Authorization || Done || Jan || ? || ? || ||org.csstudio.csdata || Common data objects for pvs and devices || Done || Kay/Gabriele || ? || ? || ||org.csstudio.csdata.ui || widgets and ui element that deal with csdata structures|| || ?|| ? || ? || ||org.csstudio.dal || dal as separate plug-in || Dropped from 3.0.0 || Jan || Joerg || Joerg, Cosylab || ||org.csstudio.data || common data structures || Done || ?|| Bastian? || ? || ||org.csstudio.java || Basic Java utilities for strings, files, etc. || Groundwork done || ?|| Gabriele?, Bastian || Gabriele, Bastian || ||org.csstudio.logging || responsible for configuring the log || Done || Kay || Gabriele || || ||org.csstudio.ui.menu || Defines menus and popup menus using extensions || Done || Gabriele || ? || ? || ||org.csstudio.ui.util || utilities for SWT/JFace/Draw2d || Groundwork done || Gabriele || ? || ? || ||org.csstudio.remote || remote control as separate plug-in || Done || Jan || Joerg, Eugen || Joerg, Eugen, Jan || ||org.csstudio.statistics || statistics as separate plug-in || Dropped from 3.0.0 || Jan || ? || ? || ||org.csstudio.startup || Remove dependency to platform || Done (needs review in 3.1.0) || Kay || ? || ? || ||org.csstudio.utility.pv || utility.pv for inclusion in core || Done || Kay || ? || ? || ||org.csstudio.utility.pvmanager || pvmanager for inclusion in core || Done || Gabriele || Kay? || Bastian || ||org.csstudio.workspace || rename the plugin || Done (needs review in 3.1.0) || || || ||
- look for commonalities in startuphelpers from BNL/SNS
- org.csstudio.dal
- org.csstudio.statistics
- org.csstudio.openfile - REVIEW (probably need a full featured extension point for using commandline arguments)
- org.csstudio.workspace – REVIEW (this was taken as it was and renamed. At the very least, the package name should be consistent)
- org.csstudio.csdata.clipboard – REVIEW (can we have a generic clipboard action that leverages the work done for D’n’D?)
- org.csstudio.ui.util – if needed, review and consolidate
- org.csstudio.java – if needed, review and consolidate
Motion 1: release date 5/31/2011. Accepted
Motion 2: the next release number shall be CSS-Core 3.0.0. Accepted
Motion 3: there should be a cute name to indicate the release, like other projects do (like Ubuntu Gutsy Gibbon, …). Accepted
Motion 4: “Alluring Albatross” for first release. Accepted
Motion 4.5: The next release name is picked by DESY, the following by SNS. Accepted
Motion 5: the main theme should be modularization. Accepted
Motion 6: create new features for "core" and "core-utils" so that it’s more clear what they are. Accepted
Motion 7: create org.csstudio.platform.core.feature that will contain all plugins that everybody requires (one site not wanting it makes it not part of this feature). Accepted
Motion 8: create org.csstudio.platform.util.feature that will contain all plugins that anybody believe should be part of core (one site wanting it makes part of this, the maintainer has to agree to give support and keep the interfaces somewhat stable). Each site will include any number of these plug-ins. The feature is there so that once a plug-in is part of the feature the build will pick it up. Accepted
Motion 9: org.csstudio.logging plugin. Accepted
--> Add motions for Kays proposals
Motion 10: org.csstudio.java: Basic Java utilities for strings, files, ... Accepted
Motion 11: org.csstudio.ui: Utilities for SWT/JFace/Draw2D to create Dialogs, ... Accepted
Motion 11.5: org.csstudio.csdata.ui for ui elements that depend on the data structures. Accepted
Motion 12: workspace: Workbench, workspace tools. Accepted
Motion 13: org.csstudio.auth: Authentication/Authorization. Accepted
Motion 14: org.csstudio.csdata: Control system data types (PV name, time, alarm, values). Accepted
Motion 15: remote control as separate plug-in. Accepted
Motion 16: org.csstudio.statistics as separate plug-in. Accepted
Motion 17: org.csstudio.platform.dal as separate plug-in. Accepted
Motion 18: utility.pv as a core plug-in. Accepted
Motion 18.5: IValue as now used by utility.pv and archive code as a separate plugin. Accepted
Motion 19: PVManager as a core plug-in. Accepted
Motion 20: the org.csstudio.platform will remain. As pieces are taken out, platform will depend on these pieces. Accepted
Motion 20.5: To make it more obvious what 'remains' and what has been re-designed, stop using 'platform' for the new plugins. Accepted
Motion 20.6: Don't put anything in the plugin name that determines whether it's core or core-utils, given that plugins may change status. Accepted
Motion 21: we should have a cs-studio-stable-branch which contains only released plug-ins, at least for core. Any pushed plug-in there should increase the release number of the plug-in. Accepted
Motion 22: create a script that crawls the repository and creates an HTML page with the plug-in maintainers and pushes it on sourceforge. Accepted
Motion 22.5: Each plugin source contains an INFO file with brief information that's also included in the HTML page, so it can be a table of Pluging Name, Maintainers, Info. Rejected
Motion 22.6: Use Bundle-Description for the info field. This way we parse one thing, it's actually distributed and recognized by OSGi. Eclipse does not have a field in the UI editing for this, but if you put "Bundle-Description" in the MANIFEST.MF it's recognized. Accepted
Motion 23: investigate how to include/run the unit tests as part of the build (BNL/DESY both proposed something similar). Accepted
Motion 23.5: Move test code in fragments (e.g. plugin org.csstudio.pvmanager and fragment org.csstudio.pvmanager.test). We get rid of test code and the mock-libs in CSS products. Accepted
(Modified: Move test code into its own source tree. Use separate fragment if test code requires other plugins or libraries beyond junit)