Note: all this information is confidential, and should not be disclosed out of Nokia!
Presentation by Brian White.
Official name: Unified Change Management.
Right out of the box model, optional.
Will support the concept of "project" (as a ClearCase entity), with
roles: Project Leader, Developer, Integrator.
Working in ClearCase alone, with additional support from ClearQuest.
Hides configuration specifications under Streams: baseline +
changes.
A version of a component is a baseline
Positive impression: the concept of baseline encompasses somehow
what I requested with versioned types (not exactly of course).
Support for project is a good thing, hopefully allowing for some
factorization of information.
Some drastic restrictions make the first version useless (one
component per vob).
Also, the project stuff will be managed in a separate vob --good--
that must be replicated with the source vobs concerned --bad!!!--
The expert is Joyce (I missed her name, but she promised to mail me as the patch is available).
January patch will contain an enhancement to NFS load issue, as well as a fix for one touch problem.
We are being discouraged to use HP-UX 11, especially in clients... Problems with threads and looping, as well as with large vobs.
HP kernel group still uses 10.20 for their own server.
Multiple versions of HP NNM under a vob: there is some undocumented support for chroot usage, so that: first get support from HP for installation of multiple NNM version (option to swinstall), and then come back to get this under ClearCase.
The expert is Kevin Esler.
I exposed the status of the .cmake.state problems, and mailed him my demo makefile. While we all believe there is nothing serious, nobody fully understands all the aspects.
We discussed the issue of identical derived objects, and how to
avoid producing them. This issue is becoming
more critical because of the announce of the Express Build
feature, allowing developers to build without making their derived
objects public (available for promotion to the shared status). In this
scheme, people are more likely to produce identical derived objects
than before. They will also have an opportunity to promote these
later, resulting in many shared copies!
Kevin understood my concern, and promised to investigate.
The next issue was the matching of directories for build avoidance. I misstated my case, leading to a wrong agreement (on providing a support that later happened to be already in place). I corrected my statement later by mail.
Finally, we discussed Java building under clearmake. We mentioned the tool used by JP Patinen, but Kevin encouraged me to send him my suggestion to process the config records instead of parsing Java source.
Heini Aarela was interested in support for a PD tool called makeit. Kevin promised to have a look.
Heini Aarela had requirements concerning protections, and support for logical roles beyond using Unix groups (and blurring the actual identities in history records). She got sympathy but no more. The SUM is not likely to provide anything like what she was after. I acknowledge a weakness in ClearCase in these matters, which hasn't been a problem at ours so far, since tmsosadm and root have been clearly identified, but this could not be always the case.
The concern about the requirement to replicate admin vobs was
acknowledged by Peter Klenk, but with no promise of any kind. It was
new to them, since they are planing to extend the same kind of scheme
for project vobs in SUM, which seems to me to be a total killer: the
source code and the process should be fully decoupled in my mind, as
much for pragmatic as for reuse reasons.
I still intend to continue a discussion with Peter on this issue.