Release3.0.0

{{{ #!html }}}

= Release 3.0.0 (Alluring Albatross) =

== Motions ==

• Voting. The overall proposal is broken into motions. To each motion reply with +1 to agree, -1 to disagree. Not replying mean you don’t care. I will include the votes from BNL.

• Release date. Motion 1: I would propose 5/31/2011. Assuming we waste a month planning, this gives us 2 month to do work and the last month for stabilization. +1

• Release number. The release number for a release refers to core. Each application will have their own release number. Each product has their own release number. We still need to decide what should be the release number for the next release. For products, DESY is currently at 1.3.0, SNS is currently at 2.5.0. BNL is at 1.0.1. Should we take the biggest number, and make 2.6? Should we somehow "reset" and go to 3? Does anybody have a strong opinion? I don’t particularly care: Motion 2: the next release number shall be CSS-Core 3.0.0

• Release codename Motion 3: there should be a cute name to indicate the release, like other projects do (like Ubuntu Gutsy Gibbon, …) +1 Motion 4: I propose “Alluring Albatross” +1

A lot of requests were in the modularization and infrastructure part. Motion 5: the main theme should be modularization +1

-- Modularization – Here we discuss what in principle we want to do. After that, we’ll discuss what we believe can be done in what timeframe and what should come first.

The first thing to do is to start enacting what we had already discussed a few months ago. We should have 2 features, one called css-core and one css-core-utils. These are mainly organizational features. The first contains the bare minimum that everybody thinks should be in (we haven’t yet agreed on what it’s in there… and will probably take some time). The second contains everything that CSS-Core is, and it’s mainly meant for building and testing and documentation. Motion 6: create new features for both so that it’s more clear what they are. 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) +1 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. +1

That’s the easier part. Now the whole breaking into different pieces. I’ll take the list from SNS, which is the most exhaustive: Motion 9: org.csstudio.platform.logging: Based on java.util.logging, because that's already there? BNL – do some library have log4j as a dependency?

Motion 10: org.csstudio.platform.java: Basic Java utilities for strings, files, ... +1 – I’d also add my standard null utilities (most of which are coming in Java 7)

Motion 11: org.csstudio.platform.ui: Utilities for SWT/JFace/Draw2D to create Dialogs, ... +1 – some of this may have a dependency on data structure. We currently have a pvmanager.ui that is starting to gather reusable ui elements that depend on such data structure.

Motion 12: workspace: Workbench, workspace tools +1

Motion 13: org.csstudio.platform.auth: Authentication/Authorization. +1

Motion 14: org.csstudio.platform.csdata: Control system data types (PV name, time, alarm, values) +1 Also need to understand how this ties with the data structures defined in PVManager

Motion 15: remote control as separate plug-in +1

Motion 16: org.csstudio.platform.statistics as separate plug-in (SNS/DESY proposed) +1

Motion 17: org.csstudio.platform.dal as separate plug-in (SNS/DESY proposed) +1

Motion 18: utility.pv as a core plug-in +1 hopefully we can get PVManager to the same level of equivalent functionality, but it will take time to do that and rewriting existing applications still has a cost.

Motion 19: PVManager as a core plug-in +1

I’d feel more comfortable if these changes were done gradually. Therefore I propose the following: Motion 20: the org.csstudio.platform will remain. As pieces are taken out, platform will depend on these pieces. Other plugin will stop having (when possible) a direct dependency on platform. If and when platform does not contain anything and no other plug-in depends on it, it can be junked. +1

-- Infrastructure – Other couple of things we need to understand.

Currently we are all working on the same trunk, which is essentially an unstable branch. This creates the following problem: while we are working on a new release, parts of the codebase will become unstable. This effectively prohibits people from making a patch release, where they are just fixing a small bug, and sharing that fix (it will be merged to trunk with all the other unstable changes). 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. +1

Motion 22: create a script that crawls the repository and creates an HTML page with the plug-in maintainers and pushes it on sourceforge. +1 BNL volunteers to do this

Motion 23: investigate how to include/run the unit tests as part of the build (BNL/DESY both proposed something similar) +1

Ok, I think this is enough for now. We should iterate and see where we converge. After there is agreement with the tasks, we can start talking about who can do what.

Gabriele

Motion 4.5: The next release name is picked by DESY, the following by SNS +1

Motion 18.5 IValue as now used by utility.pv and archive code as a separate plugin. Could be in org.csstudio.platform.csdata.

Motion 20.5: To make it more obvious what 'remains' and what has been re-designed, stop using 'platform' for the new plugins. Use 'o.c.core' for what's in the core feature that everybody loves. Use 'o.c.framework' for what some people love and others hate. +1

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

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.

Motion 23: investigate how to include/run the unit tests as part of the build (BNL/DESY both proposed something similar) +1 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.