RE: [plcs-dex] Re-baselining Dex1 capabilities

[Tim Turner <timturner11@bellsouth.net>]

Hi Rob,

thanks for the comments - hope you had a relaxing vacation!

The baseline versions for the capabilities were highlighted in the
spreadsheet I attached previously. You are correct, we wish to return to the
versions of the capabilities refered to before the upload of the example Dex
which will re-used to develop documentation of the business concept
approach. Only in one capability (C079)did I detect the case of parallel
editing resulting in some (ref) data actually being lost during the upload.

I thought the options were to either create a branch or to just create a new
version (using those capabilities previously logged). However, if it is
possible to also roll-back (as you mentioned) then this would also be
a(preferable) option (to me) though I would need help on the this. I can
write issues against each capability as required, though in theory this
wouldn't be necessary for a roll-back, just agreement from those
responsible/editors.

I haven't acted upon any of this yet except to assess the versions required
to achieve the baseline requested. However, to get Dex1 back to "pre-upload"
state I need all those affected to be re-baselined, so I wanted to get some
broad agreement before doing any of this work. The versions I have
identified do not undo anything else other than remove what was done for the
example Dex work. So I would keep the edits done by Mike Ward, for example
on some of Dex1 capabilities, before the upload occured.

The tagging approach would seem fine, though the tags will probably need to
indicate which version of a Dex a specified version of a capability belongs
to. Of course there may be multiple Dexs to which a capability may be part
of so we must cater for this too.

regards,
Tim

-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 31 March 2005 08:15
To: 'Tim Turner'; plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Re-baselining Dex1 capabilities


Hi Tim
Sorry for the slow response - I have been on vacation.
A couple of points below [RBN>]


-----Original Message-----
From: Tim Turner [mailto:timturner11@bellsouth.net]
Sent: 14 March 2005 04:11
To: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] Re-baselining Dex1 capabilities
Importance: High

Dear All,

subject to the last meeting in Lillehammer, I have been looking into
re-baselining Dex1 and the capabilities therein. This was an action for
Trine & myself to execute, which I have assumed responsiblility after
discussion with Trine. I note that with some incredulity that this was not
actually logged as an action in the minutes (with me as the action noter)!

I attach a table indicating the current versions of the capabilities that
exist, those which I consider to be relevant for the baseline prior to the
additions from the pilot & the proposed revision number for the baseline
itself.  The work of the pilot has been a useful learning exercise and has
helped to provide better direction for our work & the (capability) versions
created during this work are of course logged within sourceforge for
reference & will not be lost.

I seek a recommendation from the Dexlib administrator (Rob) whether to
create branch points for these prior revisions or to create a new revision
based upon that selected for the baseline. I assume that we should do the
latter but I am open to use of branches though I don't know if our toolset
is sophisticated enough at present to use these.
[RBN>] Yes, CVS can maintain branches - however, I do not believe that we
should
use them at the moment. Simply create a new revision of the file.

I have editorship for 8 or 9 of the affected capabilties, but not for the
other ones. If you are an editor for one of the capabilities identified in
the attached, then please let me know if you agree to this baseline version
or whether you have an alternative suggestion to achieve this. If I get no
response then I will ask the administrator to make the changes by the end of
this coming week. I will act on those I am responsble for as soon as I hear
back on the branching issue above.
[RBN>] A number of the capabilities that you list have Eurostep editors.
What
exactly are you proposing to change? I think that the right approach is to
raise
comments against the capability, then discuss the change. The other point is
that some of the changes were made as part of the example DEX prior to the
SC4
meeting - I think that these should be undone

My only other question is to other Dex leaders - do you have a baseline for
your Dex & how has it been defined (other than by date)?
[RBN>] No - there is no baseline for DEX7. A good suggestion though. The
best
approach is to use the CVS TAGS - this creates a baseline. We could develop
something more sophisticated.

regards,
Tim

NB - I'd like to make 3 comments & recommendations based upon my experience
in re-baselining Dex1 & its capabilities;

1. The versioning system of cvs has proved very useful. However, because the
commenting by the various editing team members has been so sparten I have
had to compare each version back to the point where I believe the baseline
existed. This was an arduous, time consuming task. Comments such as
"update", "revised", "upload" etc., are NOT useful to anyone attempting to
understand changes that have been made. I therefore, recommend that we seek
to have more MEANINGFUL documentation of changes effected by editors (or
ANYONE making changes). I, as well as many others have been guilty of this
sort of sparten documentation.
[RBN>] I agree. I believe that best approach is to provide meaningful
comments
in the issue log. Then, when checking in a change, reference the issue
number in
the CVS comment.

2. Some versions of capabilities were apparently worked on in isolation from
the cvs repository and as a consequence updates were made in parallel. This
is NOT an acceptable approach! In this case the main changes between these
versions were an adjustment of the reference data being used by the
capability (e.g. C079 - rep.props.numerically). However, when the edits from
the pilot were "uploaded" - those references appear to have been lost in the
current edition. I therefore, recommend that current editors either "lock"
their capabilities or, as I think was suggested in Lillehammer, that changes
be sent to the editor for updating. Personally, I would suggest that we do
BOTH.
[RBN>] This is critical!!! We MUST all use CVS properly, otherwise we have
real
chaos.
I assume that the changes to representing_properties_numerically were made
prior
to the SC4 meeting (judging by the author of the changes and the date).
I propose to remove these changes and roll back the version.

PLEASE would everyone use CVS. Do a CVS update on DEXlib BEFORE you start
editing a capability - Especially if you are not the editor.




3. There is DEFINATELY a need to be able to baseline (freeze) a version of a
Dex. This is not a wish - it has to happen & soon. This should be done
though a recording of each version of the capability used by a Dex. In
practice, this should extend deeper, such that each capability even records
the versions of the modules that it uses. Without this we are going to end
in a real pickle & soon. If we haven't reached this point already I think we
are fast approaching it. In my mind this should be a PRIORITY on the toolset
development. It need not freeze development of capabilties but will provide
a tool for establishing credible versions of the Dex for review, comparison
and management.
[RBN>] We should use CVS TAGS for this. We are investigating a baselining
mechanism for STEPmod - once this is implemented we should adapt it for
DEXlib

kind regards,
Tim