[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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>] Regards Rob ------------------------------------------- Rob Bodington Eurostep Limited Web Page: http://www.eurostep.com http://www.share-a-space.com Email: Rob.Bodington@eurostep.com Phone: +44 (0)1454 270030 Mobile: +44 (0)7796 176 401 -----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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]