Difference: DecfilesReleases (1 vs. 23)

Revision 232018-06-05 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 56 to 56
 

Request the deployment

Changed:
<
<
To ask for deployment, go to JIRA (https://sft.its.cern.ch/jira/browse/LHCBDEP) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment.
>
>
To ask for deployment, go to JIRA (https://its.cern.ch/jira/projects/LHCBDEP) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment.
 

Update bookkeeping

Revision 222018-02-27 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 83 to 83
 
Changed:
<
<

Update the documentation for the release

>
>

Update the documentation for the release

 Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
python make_df_doc.py v27r15

Revision 212018-02-27 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 14 to 14
 In order to check the status of the package you can use the nightly build where the head (or a branch) of DecFiles is built. The DecFiles package is build in the lhcb_branches slot together with Gauss v45b (for now - a separate test project will be set up separately in the future). For the final steps - or if you need to do any modification - you will need to get a local copy of the package.

Check there are no errors/problems with the newly committed event types

Changed:
<
<
You can check if there are decay files with errors and for which the options have not been produced by looking at the error messages produced in the nightly. Syntax errors for which the options of the event types could not be built will appear as build errors. Simple tests for all event types for which decay files have been committed since the last release are automatically run in the slot: 5 events will be run and you can check if the jobs were successful. These checks can be done regularly and you can contact the people that committed the problematic decay files as soon as you spot a problem.

In most cases the errors messages will be of expected types, i.g. missing known keyword and you may fix them yourself without the need to contact the authors, while problems when running the events will likely need you to get in touch with them.

If you need to fix build errors in the decay files you will need to get a local copy of the package and build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by

>
>
to get a local copy of the package and build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by
 
Changed:
<
<
cd Gen/DecFiles/cmt
>
>
cd Gen/DecFiles
 make >& make.log

Note that you will need to remove the event types produced to make them again otherwise the script will find them and refuse to make them again.

Deleted:
<
<

Checking the status with respect to the previous version are those expected from the tag collector

There are two scripts setup to help you do this. They are located in $LHCBHOME/group/gauss/releases. First do a diff of all subdirectories of the nightly (or your local copy) vs the previous release excluding the svn path. For the dkfiles and options directories save them in files, e.g.
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/cmt $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/cmt
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/doc $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/doc
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/dkfiles $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/dkfiles | tee dkfiles-vs-v24r1.log
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/options $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/options | tee options-vs-v24r1.log

p.s. the 'Mon' above is given as example. Put the day for which you are doing the verification.

The differences in the various packages should be those expected (e.g. you know that the create_options.py has been modified as listed in the release notes and in the tag collector).

Now check the differences in the subdirectory you expect them. A script exist to list the real differences, new files or removed files in the dkfiles and options directory.
For dkfiles do:

python /afs/cern.ch/lhcb/group/gauss/releases/DiffDecFiles-dk.py dkfiles-vs-v27r14.log
You will have first a report of the files with real differences: they should correspond to those that have been fixed in the metadata part for example. Then you will have a list of files only present in your local copy (the new one) and those only present in the version v27r14. Check this against the tag collector and the release notes. For the files only present in version v24r1 or for which the event type code has been changed, verify they are listed in the file doc/table_obsolete.py: if not check you will need to update it. See below.


You then have to check the difference between the new options produced and those in the latest version. A dedicated script exist also in this case:

python /afs/cern.ch/lhcb/group/gauss/releases/DiffDecFiles-opts.py options-vs-v27r14.log
Again you will see if people modified options (check if this make sense, i.e. does not change the meaning, for example the association eventtype-nickname or settings to produce exotic even types without this having been agreed on), new options and removed options. They should be consistent with what expected from the differences in dkfiles. Note that you can have more then one options produced from one single decay file.
 

Clean up obsolete decay files

Event types are unique identifier of MC samples and as such cannot be reused in a production campaign. Even if people remove or fix decay files the event type id most likely has to be kept, in particular if sample for it exist in the book-keeping or if releases in a DecFiles for a running production (now Sim08, i.e. >=v27r4). Check if decay files removed or with a modified event type have already been entered in the doc/table_obsolete.py, if not do so with a nickname that will indicate this is old/wrong/buggy. Don't forget to updated the release notes and the tag collector!
Line: 67 to 30
 

Get a local copy of the package

At this point if you have not already done so you will have to get a copy of the package as you will need to make some changes. In case it is for the latest development get the head revision.
Changed:
<
<
getpack Gen/DecFiles HEAD
>
>
git lb-clone-pkg Gen/DecFiles
 
Deleted:
<
<
Due to the special nature of DecFiles being a package you cannot use the tag collector utilities for releases.
 

Change version and put an header in the release notes

Make sure the version in the requirements file correspond to the one you are preparing the release for (e.g. v27r15) and put the header line with the version and date in the release notes
Changed:
<
<
Commit to svn and tag with
tag_package Gen/DecFiles [vXrY]
e.g. 
tag_package Gen/DecFiles v27r15

For a branch, use the -B options:

tag_package -B v26b Gen/DecFiles v26r17
>
>
Commit back to gitlab. Afterwards visit https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/tags and create new tag from master (or branch in case of special needs)
 

Build the tagged version and prepare the dev documentation

Changed:
<
<
It is a good idea to build once the tagged version to check there are no lingering errors if somebody committed somethings after the last nightly build. You should do that in the $LHCBDEV/GAUSS area. Note: Only Gloria and Patrick may be able to do so at the moment Go to the area and clean up the previous version sitting there
cd $LHCBDEV/GAUSS/
rm -fR Gen/DecFiles
then getpack the tagged version you want to release and build it
getpack Gen/DecFiles [vXrY]
e.g.
getpack Gen/DecFiles v27r15
and build it
>
>
It is a good idea to build once the tagged version to check there are no lingering errors. You should do that in the $LHCBDEV/GAUSS area.
 
Changed:
<
<
cd Gen/DecFiles/cmt cmt make
>
>
cd $LHCBDEV/GAUSS/Gen/DecFiles git pull git checkout vXrY make clean make
  You should not have any error/warning at this point. And you can now check that what you have is identical to what you had in the nightly before you added the release notes and tagged it.
Line: 113 to 55
 python make_df_doc.py dev
Deleted:
<
<

Put the tagged version in the nightlies

You can now add the tag to the nightlies for a very final check with the qmtests (Note: Only Gloria should do so at the moment since it is a integrated with the Gauss nightly. Ask her to put the version in the nightly.)
Go to the Nighlies Summary and click on the 'Configuration editor' button. Click on the lhcb-branches slot and on then on the arrow on the left: it will open up - Change the DecFiles version from HEAD to the one to be released.

Announce the availability of the pre-release for final checks

You should also send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and when there are many changes to gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v27r15) is available and will be picked up by the Gauss nightly builds in the lhcb-branches slot and the list of decay files produced is on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.
 

Request the deployment

Changed:
<
<
After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://sft.its.cern.ch/jira/browse/LHCBDEP) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Tomas.Pilar@cernNOSPAMPLEASE.ch in the cc at the bottom. When asking for a deployment of two parallel releases, specify to run the bookkeeping update only for one (for example, for v26 but not for v25).
>
>
To ask for deployment, go to JIRA (https://sft.its.cern.ch/jira/browse/LHCBDEP) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment.
 

Update bookkeeping

Line: 153 to 83
 
Changed:
<
<

Update the documentation for the release and announce it

>
>

Update the documentation for the release

 Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
python make_df_doc.py v27r15
update the soft link releases/latest to point to v27r15 then edit releases/v27r15/description.html with some explanation (you can look at the examples for previous versions.
Changed:
<
<
Finally got into the Sim08 subdirectory and put a soft link to introduce this version in the Sim08 category and also update here the soft link to the latest version
>
>
Finally got into the Sim09 subdirectory and put a soft link to introduce this version in the Sim09 category and also update here the soft link to the latest version
 
ln -s ../v27r15 v27r15
ln -s ../v27r15 latest
Changed:
<
<

Finally send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.
>
>

Update production steps and models in Dirac

Announce new version

Finally, send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.
 
Changed:
<
<
-- GloriaCorti - 14-Nov-2011
>
>
-- MichalKreps - 2018-02-27

Revision 202018-02-13 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 122 to 122
 

Announce the availability of the pre-release for final checks

You should also send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and when there are many changes to gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v27r15) is available and will be picked up by the Gauss nightly builds in the lhcb-branches slot and the list of decay files produced is on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.
Deleted:
<
<

Prepare the tag collector for the next release

Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to do it, if not already done.
Go to the tag collector and Click on New Project'. Enter 'DecFiles' as name of the project and the next version. Add the explanation on how to add a new change in the tag collector (you can cut and paste the one of the previous version). Once the new DecFiles (e.g. v27r16) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v27r16.
 

Request the deployment

After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://sft.its.cern.ch/jira/browse/LHCBDEP) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Tomas.Pilar@cernNOSPAMPLEASE.ch in the cc at the bottom. When asking for a deployment of two parallel releases, specify to run the bookkeeping update only for one (for example, for v26 but not for v25).
Added:
>
>

Update bookkeeping

From lxplus, once the changes on CVMFS have been propagated (check with ls /cvmfs/lhcb.cern.ch/lib/lhcb/DBASE/Gen/DecFiles), you have to update the bookkeeping.

  • Get a valid Grid proxy
    lhcb-proxy-init
    
  • Update the bookkeeping
    cd /cvmfs/lhcb.cern.ch/lib/lhcb/DBASE/Gen/DecFiles/<version>
    lb-run -c best LHCbDirac dirac-bookkeeping-eventtype-mgt-insert doc/table_event.sql
    lb-run -c best LHCbDirac dirac-bookkeeping-eventtype-mgt-update doc/table_event.sql
    lb-run -c best LHCbDirac dirac-bookkeeping-eventtype-mgt-update doc/table_obsolete.sql
    

The dirac-bookkeeping-eventtype-mgt-insert command will produce many errors like

{'EVTTYPEID': '12165431', 'DESCRIPTION': 'Bu_D02pi+pi-,K+pi-pi0=PHSP,DecProdCut', 'PRIMARY': '[B+ -> pi+ pi+ pi- (D0bar -> K+ pi- pi0)]cc'} : Excution failed.: ( ORA-00001: unique constraint (LHCB_DIRACBOOKKEEPING.SYS_C00302542) violated
ORA-06512: at "LHCB_DIRACBOOKKEEPING.BOOKKEEPINGORACLEDB", line 1131
ORA-06512: at line 1
 ) 
This is normal as most event types already exist in the Oracle table. Things are OK if the last line is like
The following event types are inserted: ['42102201', '42102200', '42163203', '42102221', '42102220', '15104451', '42100210', '42100211', '42100230', '42100231', '42142201', '42142200', '42102210', '42102211', '42162203', '42162202', '15574100', '42100221', '42100220', '12163436', '12163437', '42102601', '42102600', '12163236', '42163202', '12163235', '42112200', '42112201'] 
 

Update the documentation for the release and announce it

Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
Line: 148 to 168
 
Finally send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.
Deleted:
<
<

Set the version as released in the tag collector

The very last thing to do is to go to the tag collector and hide the DecFiles v27r15 version. When asked if you want to declare the project released answer yes.
 

-- GloriaCorti - 14-Nov-2011 \ No newline at end of file

Revision 192017-05-10 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 47 to 47
 
For dkfiles do:
Changed:
<
<
python $LHCBHOME/group/gauss/releases/DiffDecFiles-dk.py dkfiles-vs-v27r14.log
>
>
python /afs/cern.ch/lhcb/group/gauss/releases/DiffDecFiles-dk.py dkfiles-vs-v27r14.log
  You will have first a report of the files with real differences: they should correspond to those that have been fixed in the metadata part for example. Then you will have a list of files only present in your local copy (the new one) and those only present in the version v27r14. Check this against the tag collector and the release notes. For the files only present in version v24r1 or for which the event type code has been changed, verify they are listed in the file doc/table_obsolete.py: if not check you will need to update it. See below.
Line: 55 to 55
 
You then have to check the difference between the new options produced and those in the latest version. A dedicated script exist also in this case:
Changed:
<
<
python $LHCBHOME/group/gauss/releases/DiffDecFiles-opts.py options-vs-v27r14.log
>
>
python /afs/cern.ch/lhcb/group/gauss/releases/DiffDecFiles-opts.py options-vs-v27r14.log
  Again you will see if people modified options (check if this make sense, i.e. does not change the meaning, for example the association eventtype-nickname or settings to produce exotic even types without this having been agreed on), new options and removed options. They should be consistent with what expected from the differences in dkfiles. Note that you can have more then one options produced from one single decay file.

Revision 182014-10-21 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 129 to 129
 Once the new DecFiles (e.g. v27r16) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v27r16.

Request the deployment

Changed:
<
<
After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://savannah.cern.ch/task/?group=lhcbdeployment) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put
>
>
After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://sft.its.cern.ch/jira/browse/LHCBDEP) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put
 Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Tomas.Pilar@cernNOSPAMPLEASE.ch in the cc at the bottom. When asking for a deployment of two parallel releases, specify to run the bookkeeping update only for one (for example, for v26 but not for v25).

Revision 172014-02-17 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 90 to 90
 Note: Only Gloria and Patrick may be able to do so at the moment Go to the area and clean up the previous version sitting there
Changed:
<
<
cd $LHCBDEV/GAUSS/Gen rm -fR DecFiles
>
>
cd $LHCBDEV/GAUSS/ rm -fR Gen/DecFiles
  then getpack the tagged version you want to release and build it
Line: 107 to 107
 You should not have any error/warning at this point. And you can now check that what you have is identical to what you had in the nightly before you added the release notes and tagged it.


Changed:
<
<
To make the documentation go to $LHCBDOC/decfiles and use the script set up for it
>
>
To make the documentation go to $LHCBDOC/decfiles, change previous version in make_df_doc.py and use the script set up for it
 
cd $LHCBDOC/decfiles
python make_df_doc.py dev

Revision 162013-11-29 - MichalKreps

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 90 to 90
 Note: Only Gloria and Patrick may be able to do so at the moment Go to the area and clean up the previous version sitting there
Changed:
<
<
cd $LHCBDOC/GAUSS/Gen
>
>
cd $LHCBDEV/GAUSS/Gen
 rm -fR DecFiles then getpack the tagged version you want to release and build it

Revision 152013-11-27 - GloriaCorti

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 11 to 11
 
  • what is expected from the tag collector
and that the release notes reflect the status of the package.
Changed:
<
<
In order to check the status of the package you can use the nightly build where the head (or a branch) of DecFiles is built. The DecFiles package is build in the lhcb_branches together with Gauss v45b (for now - a separate test project will be set up separately). This will cover most of the cases but for the final steps you will need to get a local copy of the package.
>
>
In order to check the status of the package you can use the nightly build where the head (or a branch) of DecFiles is built. The DecFiles package is build in the lhcb_branches slot together with Gauss v45b (for now - a separate test project will be set up separately in the future). For the final steps - or if you need to do any modification - you will need to get a local copy of the package.
 

Check there are no errors/problems with the newly committed event types

You can check if there are decay files with errors and for which the options have not been produced by looking at the error messages produced in the nightly.
Line: 21 to 21
  In most cases the errors messages will be of expected types, i.g. missing known keyword and you may fix them yourself without the need to contact the authors, while problems when running the events will likely need you to get in touch with them.
Changed:
<
<
If you need to fix build errors in the decay files you will need to get a local copy of the package and build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by
>
>
If you need to fix build errors in the decay files you will need to get a local copy of the package and build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by
 
cd Gen/DecFiles/cmt
make >& make.log
Line: 30 to 30
 Note that you will need to remove the event types produced to make them again otherwise the script will find them and refuse to make them again.

Checking the status with respect to the previous version are those expected from the tag collector

Changed:
<
<
There are two scripts setup to help you do this. They are located in $LHCBHOME/group/gauss/releases
>
>
There are two scripts setup to help you do this. They are located in $LHCBHOME/group/gauss/releases.
 First do a diff of all subdirectories of the nightly (or your local copy) vs the previous release excluding the svn path. For the dkfiles and options directories save them in files, e.g.
Changed:
<
<
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/cmt $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/cmt diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/doc $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/doc diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/dkfiles $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/dkfiles | tee dkfiles-vs-v24r1.log diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/options $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/options | tee options-vs-v24r1.log
>
>
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/cmt $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/cmt diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/doc $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/doc diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/dkfiles $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/dkfiles | tee dkfiles-vs-v24r1.log diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v27r14/options $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/options | tee options-vs-v24r1.log
 

p.s. the 'Mon' above is given as example. Put the day for which you are doing the verification.

Line: 60 to 60
 Again you will see if people modified options (check if this make sense, i.e. does not change the meaning, for example the association eventtype-nickname or settings to produce exotic even types without this having been agreed on), new options and removed options. They should be consistent with what expected from the differences in dkfiles. Note that you can have more then one options produced from one single decay file.

Clean up obsolete decay files

Changed:
<
<
Event types are unique identifier of MC samples and as such cannot be reused in a production campaign. Even if people remove or fix decay files the event type id most likely has to be kept, in particular if sample for it exist in the book-keeping or if releases in a DecFiles for a running production (now Sim08, i.e. >=v27r4).
>
>
Event types are unique identifier of MC samples and as such cannot be reused in a production campaign. Even if people remove or fix decay files the event type id most likely has to be kept, in particular if sample for it exist in the book-keeping or if releases in a DecFiles for a running production (now Sim08, i.e. >=v27r4).
 Check if decay files removed or with a modified event type have already been entered in the doc/table_obsolete.py, if not do so with a nickname that will indicate this is old/wrong/buggy. Don't forget to updated the release notes and the tag collector!

Changed:
<
<

Get a local copy of the package

>
>

Tagging the release and final verifications

Get a local copy of the package

 At this point if you have not already done so you will have to get a copy of the package as you will need to make some changes. In case it is for the latest development get the head revision.
getpack Gen/DecFiles HEAD
Due to the special nature of DecFiles being a package you cannot use the tag collector utilities for releases.
Changed:
<
<

Change version and put an header in the release notes

>
>

Change version and put an header in the release notes

 Make sure the version in the requirements file correspond to the one you are preparing the release for (e.g. v27r15) and put the header line with the version and date in the release notes Commit to svn and tag with
Line: 84 to 85
 tag_package -B v26b Gen/DecFiles v26r17
Changed:
<
<

Put the tagged version in the nightlies and announce the availability of the pre-release for final checks

Note: Only Gloria should do so at the moment since it is a integrated with the Gauss nightly. Ask her to put the version in the nightly.
Go to the Nighlies Summary and click on the 'Nighlty configuration' button. Click on the lhcb-branches slot and on then on the arrow on the left: it will open up - Change the DecFiles version from HEAD to the one you just tagged.

When there are major changes you should also send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v27r15) is available in lhcb-branches of the nightlies and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.

>
>

Build the tagged version and prepare the dev documentation

It is a good idea to build once the tagged version to check there are no lingering errors if somebody committed somethings after the last nightly build. You should do that in the $LHCBDEV/GAUSS area. Note: Only Gloria and Patrick may be able to do so at the moment Go to the area and clean up the previous version sitting there
cd $LHCBDOC/GAUSS/Gen
rm -fR DecFiles
then getpack the tagged version you want to release and build it
getpack Gen/DecFiles [vXrY]
e.g.
getpack Gen/DecFiles v27r15
and build it
cd Gen/DecFiles/cmt
cmt make
You should not have any error/warning at this point. And you can now check that what you have is identical to what you had in the nightly before you added the release notes and tagged it.
 
Changed:
<
<
To prepare the dev documentation you should:
>
>

To make the documentation go to $LHCBDOC/decfiles and use the script set up for it
 
Added:
>
>
cd $LHCBDOC/decfiles
 python make_df_doc.py dev
Added:
>
>

Put the tagged version in the nightlies

You can now add the tag to the nightlies for a very final check with the qmtests (Note: Only Gloria should do so at the moment since it is a integrated with the Gauss nightly. Ask her to put the version in the nightly.)
Go to the Nighlies Summary and click on the 'Configuration editor' button. Click on the lhcb-branches slot and on then on the arrow on the left: it will open up - Change the DecFiles version from HEAD to the one to be released.

Announce the availability of the pre-release for final checks

You should also send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and when there are many changes to gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v27r15) is available and will be picked up by the Gauss nightly builds in the lhcb-branches slot and the list of decay files produced is on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.
 
Changed:
<
<

Prepare the tag collector for the next release

>
>

Prepare the tag collector for the next release

 Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to do it, if not already done.
Go to the tag collector and Click on New Project'. Enter 'DecFiles' as name of the project and the next version. Add the explanation on how to add a new change in the tag collector (you can cut and paste the one of the previous version).
Line: 125 to 149
 Finally send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.

Set the version as released in the tag collector

Changed:
<
<
The very last thing to do is to go to the tag collector and hide the DecFiles v25r1 version. When asked if you want to declare the project released answer yes.
>
>
The very last thing to do is to go to the tag collector and hide the DecFiles v27r15 version. When asked if you want to declare the project released answer yes.
 

-- GloriaCorti - 14-Nov-2011

Revision 142013-11-26 - GloriaCorti

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Deleted:
<
<

Get a local copy of the package

First you have to get a copy of the package as you will need to make some changes. In case it is for the latest development get the head revision.
getpack Gen/DecFiles HEAD
 

Verify the status of the package

You will need to check the status of the package with respect to
Line: 16 to 11
 
  • what is expected from the tag collector
and that the release notes reflect the status of the package.
Changed:
<
<
In order to check the status of the package you first must build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by
>
>
In order to check the status of the package you can use the nightly build where the head (or a branch) of DecFiles is built. The DecFiles package is build in the lhcb_branches together with Gauss v45b (for now - a separate test project will be set up separately). This will cover most of the cases but for the final steps you will need to get a local copy of the package.

Check there are no errors/problems with the newly committed event types

You can check if there are decay files with errors and for which the options have not been produced by looking at the error messages produced in the nightly. Syntax errors for which the options of the event types could not be built will appear as build errors. Simple tests for all event types for which decay files have been committed since the last release are automatically run in the slot: 5 events will be run and you can check if the jobs were successful. These checks can be done regularly and you can contact the people that committed the problematic decay files as soon as you spot a problem.

In most cases the errors messages will be of expected types, i.g. missing known keyword and you may fix them yourself without the need to contact the authors, while problems when running the events will likely need you to get in touch with them.

If you need to fix build errors in the decay files you will need to get a local copy of the package and build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by

 
cd Gen/DecFiles/cmt
make >& make.log
Changed:
<
<
You can now check that the error messages are all of the type expected, i.e. missing known keyword.
>
>
Note that you will need to remove the event types produced to make them again otherwise the script will find them and refuse to make them again.
 

Checking the status with respect to the previous version are those expected from the tag collector

There are two scripts setup to help you do this. They are located in $LHCBHOME/group/gauss/releases
Changed:
<
<
First do a diff of all subdirectories of your local copy vs the previous release excluding the svn path. For the dkfiles and options directories save them in files, e.g.
>
>
First do a diff of all subdirectories of the nightly (or your local copy) vs the previous release excluding the svn path. For the dkfiles and options directories save them in files, e.g.
 
Changed:
<
<
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/cmt cmt diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/doc doc diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/dkfiles dkfiles | tee dkfiles-vs-v24r1.log diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/options options | tee options-vs-v24r1.log
>
>
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/cmt $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/cmt diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/doc $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/doc diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/dkfiles $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/dkfiles | tee dkfiles-vs-v24r1.log diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/options $LHCBNIGHTLIES/lhcb-branches/Mon/GAUSS/GAUSS_v45b/Gen/DecFiles/options | tee options-vs-v24r1.log
 
Added:
>
>
p.s. the 'Mon' above is given as example. Put the day for which you are doing the verification.
 The differences in the various packages should be those expected (e.g. you know that the create_options.py has been modified as listed in the release notes and in the tag collector).

Now check the differences in the subdirectory you expect them. A script exist to list the real differences, new files or removed files in the dkfiles and options directory.
For dkfiles do:

Changed:
<
<
python $LHCBHOME/group/gauss/releases/DiffDecFiles-dk.py dkfiles-vs-v24r1.log
>
>
python $LHCBHOME/group/gauss/releases/DiffDecFiles-dk.py dkfiles-vs-v27r14.log
 
Changed:
<
<
You will have first a report of the files with real differences: they should correspond to those that have been fixed in the metadata part for example. Then you will have a list of files only present in your local copy (the new one) and those only present in the version v24r1. Check this against the tag collector and the release notes. For the files only present in version v24r1 or for which the event type code has been changed, verify they are listed in the file doc/table_obsolete.py: if not check if they are in the list of events present in the book-keeping (a list of event type not used in the book-keeping, i.e. with no data sample, is available at $LHCBDEV/GAUSS/MC11/EventType/notusedeventtypes.csv). If the event type is used by the book-keeping and not in the table_obsolete.py put it there.
>
>
You will have first a report of the files with real differences: they should correspond to those that have been fixed in the metadata part for example. Then you will have a list of files only present in your local copy (the new one) and those only present in the version v27r14. Check this against the tag collector and the release notes. For the files only present in version v24r1 or for which the event type code has been changed, verify they are listed in the file doc/table_obsolete.py: if not check you will need to update it. See below.
 
You then have to check the difference between the new options produced and those in the latest version. A dedicated script exist also in this case:
Changed:
<
<
python $LHCBHOME/group/gauss/releases/DiffDecFiles-opts.py options-vs-v24r1.log
>
>
python $LHCBHOME/group/gauss/releases/DiffDecFiles-opts.py options-vs-v27r14.log
  Again you will see if people modified options (check if this make sense, i.e. does not change the meaning, for example the association eventtype-nickname or settings to produce exotic even types without this having been agreed on), new options and removed options. They should be consistent with what expected from the differences in dkfiles. Note that you can have more then one options produced from one single decay file.
Changed:
<
<

Clean up obsolete decay files

Check the list of files with errors and for which the options have not been produced. The easiest is to look at the error messages produced by the script and that you may have saved in cmt/make.log. Keep those for which an explicit request has been sent to the lhcb-gauss-manager@cernNOSPAMPLEASE.ch and remove from svn all others. Check if those you removed are used by the book-keeping (see point above) and if they are enter them in the doc/table_obsolete.py. Don't forget to updated the release notes and the tag collector!
>
>

Clean up obsolete decay files

Event types are unique identifier of MC samples and as such cannot be reused in a production campaign. Even if people remove or fix decay files the event type id most likely has to be kept, in particular if sample for it exist in the book-keeping or if releases in a DecFiles for a running production (now Sim08, i.e. >=v27r4). Check if decay files removed or with a modified event type have already been entered in the doc/table_obsolete.py, if not do so with a nickname that will indicate this is old/wrong/buggy. Don't forget to updated the release notes and the tag collector!

Get a local copy of the package

At this point if you have not already done so you will have to get a copy of the package as you will need to make some changes. In case it is for the latest development get the head revision.
getpack Gen/DecFiles HEAD
Due to the special nature of DecFiles being a package you cannot use the tag collector utilities for releases.
 

Change version and put an header in the release notes

Changed:
<
<
Make sure the version in the requirements file correspond to the one you are preparing the release for (e.g. v25r0) and put the header line with the version and date in the release notes
>
>
Make sure the version in the requirements file correspond to the one you are preparing the release for (e.g. v27r15) and put the header line with the version and date in the release notes
 Commit to svn and tag with
tag_package Gen/DecFiles [vXrY]
e.g. 
Changed:
<
<
tag_package Gen/DecFiles v25r0
>
>
tag_package Gen/DecFiles v27r15
 

For a branch, use the -B options:

Line: 69 to 84
 tag_package -B v26b Gen/DecFiles v26r17
Changed:
<
<

Put the tagged version in the nightlies, update the documentation and announce the availability of the pre-release for final checks

Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to put the version in the nightly.
>
>

Put the tagged version in the nightlies and announce the availability of the pre-release for final checks

Note: Only Gloria should do so at the moment since it is a integrated with the Gauss nightly. Ask her to put the version in the nightly.
 
Changed:
<
<
Go to the directory $LHCBDEV/GAUSS and remove the Gen/DecFiles that is there. Check out the tagged version and make the options:
getpack Gen/DecFiles v26r22
cd Gen/DecFiles/cmt
make
To update the documentation go to $LHCBDOC/decfiles and remove the directory releases/dev with all its contents, then make it again for the new version you just did:
>
>
Go to the Nighlies Summary and click on the 'Nighlty configuration' button. Click on the lhcb-branches slot and on then on the arrow on the left: it will open up - Change the DecFiles version from HEAD to the one you just tagged.

When there are major changes you should also send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v27r15) is available in lhcb-branches of the nightlies and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.

To prepare the dev documentation you should:

 
python make_df_doc.py dev
Deleted:
<
<
Send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v25r0) is available in $LHCBDEV/nightly and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.
 

Prepare the tag collector for the next release

Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to do it, if not already done.
Go to the tag collector and Click on New Project'. Enter 'DecFiles' as name of the project and the next version. Add the explanation on how to add a new change in the tag collector (you can cut and paste the one of the previous version).
Changed:
<
<
Once the new DecFiles (e.g. v25r1) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v25r1.
>
>
Once the new DecFiles (e.g. v27r16) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v27r16.
 

Request the deployment

After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://savannah.cern.ch/task/?group=lhcbdeployment) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put
Line: 100 to 112
 

Update the documentation for the release and announce it

Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
Changed:
<
<
python make_df_doc.py v25r1
>
>
python make_df_doc.py v27r15
 
Changed:
<
<
update the soft link releases/latest to point to v25r1 then edit releases/v25r1/description.html with some explanation (you can look at the examples for previous versions. Finally got into the MC11a subdirectory and put a soft link to introduce this version in the MC11a category and also update here the soft link to the latest version
>
>
update the soft link releases/latest to point to v27r15 then edit releases/v27r15/description.html with some explanation (you can look at the examples for previous versions. Finally got into the Sim08 subdirectory and put a soft link to introduce this version in the Sim08 category and also update here the soft link to the latest version
 
Changed:
<
<
ln -s ../v25r1 v25r1 ln -s ../v25r1 latest
>
>
ln -s ../v27r15 v27r15 ln -s ../v27r15 latest
 
Finally send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.

Revision 132013-01-31 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 72 to 72
 

Put the tagged version in the nightlies, update the documentation and announce the availability of the pre-release for final checks

Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to put the version in the nightly.
Changed:
<
<
Go to the directory $LHCBDEV/nightlies/DBASE and remove or rename the Gen/DecFiles that is there.
>
>
Go to the directory $LHCBDEV/GAUSS and remove the Gen/DecFiles that is there.
 Check out the tagged version and make the options:
Changed:
<
<
getpack Gen/DecFiles v25r0
>
>
getpack Gen/DecFiles v26r22
 cd Gen/DecFiles/cmt make

Revision 122012-10-18 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 64 to 64
 tag_package Gen/DecFiles v25r0
Added:
>
>
For a branch, use the -B options:
tag_package -B v26b Gen/DecFiles v26r17
 

Put the tagged version in the nightlies, update the documentation and announce the availability of the pre-release for final checks

Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to put the version in the nightly.

Revision 112012-10-11 - GloriaCorti

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 89 to 89
 

Request the deployment

After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://savannah.cern.ch/task/?group=lhcbdeployment) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put
Changed:
<
<
Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Mark.Whitehead@cernNOSPAMPLEASE.ch in the cc at the bottom. When asking for a deployment of two parallel releases, specify to run the
>
>
Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Tomas.Pilar@cernNOSPAMPLEASE.ch in the cc at the bottom. When asking for a deployment of two parallel releases, specify to run the
 bookkeeping update only for one (for example, for v26 but not for v25).

Update the documentation for the release and announce it

Revision 102012-10-04 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 89 to 89
 

Request the deployment

After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://savannah.cern.ch/task/?group=lhcbdeployment) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put
Changed:
<
<
Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Mark.Whitehead@cernNOSPAMPLEASE.ch in the cc at the bottom.
>
>
Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Mark.Whitehead@cernNOSPAMPLEASE.ch in the cc at the bottom. When asking for a deployment of two parallel releases, specify to run the bookkeeping update only for one (for example, for v26 but not for v25).
 

Update the documentation for the release and announce it

Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type

Revision 92012-08-04 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 76 to 76
  To update the documentation go to $LHCBDOC/decfiles and remove the directory releases/dev with all its contents, then make it again for the new version you just did:
Changed:
<
<
python make_df_doc_new.py dev
>
>
python make_df_doc.py dev
 

Send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v25r0) is available in $LHCBDEV/nightly and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.

Line: 94 to 94
 

Update the documentation for the release and announce it

Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
Changed:
<
<
python make_df_doc_new.py v25r1
>
>
python make_df_doc.py v25r1
  update the soft link releases/latest to point to v25r1 then edit releases/v25r1/description.html with some explanation (you can look at the examples for previous versions.

Revision 82012-06-28 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 72 to 72
 
getpack Gen/DecFiles v25r0
cd Gen/DecFiles/cmt
Changed:
<
<
source setup.csh
>
>
make
  To update the documentation go to $LHCBDOC/decfiles and remove the directory releases/dev with all its contents, then make it again for the new version you just did:

Revision 72012-06-27 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 19 to 19
 In order to check the status of the package you first must build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by
cd Gen/DecFiles/cmt
Changed:
<
<
source setup.csh >& make.log
>
>
make >& make.log
 

You can now check that the error messages are all of the type expected, i.e. missing known keyword.

Revision 62011-12-07 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 65 to 65
 

Put the tagged version in the nightlies, update the documentation and announce the availability of the pre-release for final checks

Changed:
<
<
Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to put the version in the nightly.
>
>
Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to put the version in the nightly.
 
Changed:
<
<
Go to the directory $LHCBDEV/nightly/DBASE and remove or rename the Gen/DecFiles that is there.
>
>
Go to the directory $LHCBDEV/nightlies/DBASE and remove or rename the Gen/DecFiles that is there.
 Check out the tagged version and make the options:
getpack Gen/DecFiles v25r0
cd Gen/DecFiles/cmt
source setup.csh
Changed:
<
<
To update the documentation go to $LHCBDOC/decfiles and remove the directory releases/dev with all its contents, then make it again for the new version you just did:
>
>
To update the documentation go to $LHCBDOC/decfiles and remove the directory releases/dev with all its contents, then make it again for the new version you just did:
 
python make_df_doc_new.py dev
Changed:
<
<
Send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v25r0) is available in $LHCBDEV/nightly and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php
>
>
Send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v25r0) is available in $LHCBDEV/nightly and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php.
 

Prepare the tag collector for the next release

Changed:
<
<
Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to do it, if not already done.
>
>
Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to do it, if not already done.
 
Go to the tag collector and Click on New Project'. Enter 'DecFiles' as name of the project and the next version. Add the explanation on how to add a new change in the tag collector (you can cut and paste the one of the previous version).
Changed:
<
<
Once the new DecFiles (e.g. v25r1) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v25r1.
>
>
Once the new DecFiles (e.g. v25r1) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v25r1.
 

Request the deployment

After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://savannah.cern.ch/task/?group=lhcbdeployment) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Mark.Whitehead@cernNOSPAMPLEASE.ch in the cc at the bottom.

Update the documentation for the release and announce it

Changed:
<
<
Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
>
>
Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
 
python make_df_doc_new.py v25r1
Line: 107 to 107
 Finally send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.

Set the version as released in the tag collector

Changed:
<
<
The very last thing to do is to go to the tag collector and hide the DecFiles v25r1 version. When asked if you want to declare the project released answer yes.
>
>
The very last thing to do is to go to the tag collector and hide the DecFiles v25r1 version. When asked if you want to declare the project released answer yes.
 

-- GloriaCorti - 14-Nov-2011 \ No newline at end of file

Revision 52011-12-07 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 7 to 7
 

Get a local copy of the package

First you have to get a copy of the package as you will need to make some changes. In case it is for the latest development get the head revision.
Changed:
<
<
getpack DecFiles HEAD
>
>
getpack Gen/DecFiles HEAD
 

Verify the status of the package

Revision 42011-11-17 - GloriaCorti

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 98 to 98
  update the soft link releases/latest to point to v25r1 then edit releases/v25r1/description.html with some explanation (you can look at the examples for previous versions.
Added:
>
>
Finally got into the MC11a subdirectory and put a soft link to introduce this version in the MC11a category and also update here the soft link to the latest version
ln -s ../v25r1 v25r1
ln -s ../v25r1 latest
 
Finally send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.
Added:
>
>

Set the version as released in the tag collector

The very last thing to do is to go to the tag collector and hide the DecFiles v25r1 version. When asked if you want to declare the project released answer yes.
  -- GloriaCorti - 14-Nov-2011 \ No newline at end of file

Revision 32011-11-16 - PatrickRobbe

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 43 to 43
 python $LHCBHOME/group/gauss/releases/DiffDecFiles-dk.py dkfiles-vs-v24r1.log You will have first a report of the files with real differences: they should correspond to those that have been fixed in the metadata part for example. Then you will have a list of files only present in your local copy (the new one) and those only present in the version v24r1. Check this against the tag collector and the release notes.
Changed:
<
<
For the files only present in version v24r1 or for which the event type code has been changed, verify they are listed in the file doc/table_obsolete.py: if not check if they are in the list of events present in the book-keeping (a list of event type not used in the book-keeping, i.e. with no data sample, is available at $LHCBDEV/Gauss/MC11/EventType/notusedeventtypes.csv). If the event type is used by the book-keeping and not in the table_obsolete.py put it there.
>
>
For the files only present in version v24r1 or for which the event type code has been changed, verify they are listed in the file doc/table_obsolete.py: if not check if they are in the list of events present in the book-keeping (a list of event type not used in the book-keeping, i.e. with no data sample, is available at $LHCBDEV/GAUSS/MC11/EventType/notusedeventtypes.csv). If the event type is used by the book-keeping and not in the table_obsolete.py put it there.
 
You then have to check the difference between the new options produced and those in the latest version. A dedicated script exist also in this case:

Revision 22011-11-15 - GloriaCorti

Line: 1 to 1
 
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Line: 65 to 65
 

Put the tagged version in the nightlies, update the documentation and announce the availability of the pre-release for final checks

Added:
>
>
Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to put the version in the nightly.
 Go to the directory $LHCBDEV/nightly/DBASE and remove or rename the Gen/DecFiles that is there. Check out the tagged version and make the options:
Line: 80 to 82
 Send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v25r0) is available in $LHCBDEV/nightly and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php

Prepare the tag collector for the next release

Added:
>
>
Note: Only Gloria and Patrick have the privilege to do so at the moment. Ask one of them to do it, if not already done.
 Go to the tag collector and Click on New Project'. Enter 'DecFiles' as name of the project and the next version. Add the explanation on how to add a new change in the tag collector (you can cut and paste the one of the previous version). Once the new DecFiles (e.g. v25r1) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v25r1.

Revision 12011-11-14 - GloriaCorti

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="LHCbSimulation"

Preparing a release of DecFiles

Get a local copy of the package

First you have to get a copy of the package as you will need to make some changes. In case it is for the latest development get the head revision.
getpack DecFiles HEAD

Verify the status of the package

You will need to check the status of the package with respect to
  • the previous version
  • what is expected from the tag collector
and that the release notes reflect the status of the package.

In order to check the status of the package you first must build the options with the default settings of the script. It may be useful to dump in a file the messages as to be able to review them by

cd Gen/DecFiles/cmt
source setup.csh >& make.log

You can now check that the error messages are all of the type expected, i.e. missing known keyword.

Checking the status with respect to the previous version are those expected from the tag collector

There are two scripts setup to help you do this. They are located in $LHCBHOME/group/gauss/releases First do a diff of all subdirectories of your local copy vs the previous release excluding the svn path. For the dkfiles and options directories save them in files, e.g.
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/cmt cmt
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/doc doc
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/dkfiles dkfiles | tee dkfiles-vs-v24r1.log
diff -r --exclude ".svn" $LHCBRELEASES/DBASE/Gen/DecFiles/v24r1/options options | tee options-vs-v24r1.log

The differences in the various packages should be those expected (e.g. you know that the create_options.py has been modified as listed in the release notes and in the tag collector).

Now check the differences in the subdirectory you expect them. A script exist to list the real differences, new files or removed files in the dkfiles and options directory.
For dkfiles do:

python $LHCBHOME/group/gauss/releases/DiffDecFiles-dk.py dkfiles-vs-v24r1.log
You will have first a report of the files with real differences: they should correspond to those that have been fixed in the metadata part for example. Then you will have a list of files only present in your local copy (the new one) and those only present in the version v24r1. Check this against the tag collector and the release notes. For the files only present in version v24r1 or for which the event type code has been changed, verify they are listed in the file doc/table_obsolete.py: if not check if they are in the list of events present in the book-keeping (a list of event type not used in the book-keeping, i.e. with no data sample, is available at $LHCBDEV/Gauss/MC11/EventType/notusedeventtypes.csv). If the event type is used by the book-keeping and not in the table_obsolete.py put it there.


You then have to check the difference between the new options produced and those in the latest version. A dedicated script exist also in this case:

python $LHCBHOME/group/gauss/releases/DiffDecFiles-opts.py options-vs-v24r1.log
Again you will see if people modified options (check if this make sense, i.e. does not change the meaning, for example the association eventtype-nickname or settings to produce exotic even types without this having been agreed on), new options and removed options. They should be consistent with what expected from the differences in dkfiles. Note that you can have more then one options produced from one single decay file.

Clean up obsolete decay files

Check the list of files with errors and for which the options have not been produced. The easiest is to look at the error messages produced by the script and that you may have saved in cmt/make.log. Keep those for which an explicit request has been sent to the lhcb-gauss-manager@cernNOSPAMPLEASE.ch and remove from svn all others. Check if those you removed are used by the book-keeping (see point above) and if they are enter them in the doc/table_obsolete.py. Don't forget to updated the release notes and the tag collector!

Change version and put an header in the release notes

Make sure the version in the requirements file correspond to the one you are preparing the release for (e.g. v25r0) and put the header line with the version and date in the release notes Commit to svn and tag with
tag_package Gen/DecFiles [vXrY]
e.g. 
tag_package Gen/DecFiles v25r0

Put the tagged version in the nightlies, update the documentation and announce the availability of the pre-release for final checks

Go to the directory $LHCBDEV/nightly/DBASE and remove or rename the Gen/DecFiles that is there. Check out the tagged version and make the options:
getpack Gen/DecFiles v25r0
cd Gen/DecFiles/cmt
source setup.csh
To update the documentation go to $LHCBDOC/decfiles and remove the directory releases/dev with all its contents, then make it again for the new version you just did:
python make_df_doc_new.py dev

Send a mail to lhcb-mc-production@cernNOSPAMPLEASE.ch and gauss@cernNOSPAMPLEASE.ch announcing that the pre-release of DecFiles vXrY (e.g. v25r0) is available in $LHCBDEV/nightly and will be picked up by the Gauss nightly builds and the list of decay files produced is available on the web at http://lhcb-release-area.web.cern.ch/LHCb-release-area/DOC/decfiles/releases/dev/table_evttype.php

Prepare the tag collector for the next release

Go to the tag collector and Click on New Project'. Enter 'DecFiles' as name of the project and the next version. Add the explanation on how to add a new change in the tag collector (you can cut and paste the one of the previous version). Once the new DecFiles (e.g. v25r1) is listed in the tag collector, edit the generic entry GSDCTNXU, myDecayFile and click on Show/Hide of Extra associated project. Click on new version of DecFiles and de-select the old version. The entry should now appear in the new DecFiles v25r1.

Request the deployment

After at least one successful use of the new version in the nightly you can ask for the deployement in the release area and on the grid. Go to savannah (https://savannah.cern.ch/task/?group=lhcbdeployment) and once you logged-in submit a new task. Put the name and version in the subjects, choose the package and ask for a grid deployment. Also put Gloria.Corti@cernNOSPAMPLEASE.ch, Patrick.Robbe@cernNOSPAMPLEASE.ch, Mark.Whitehead@cernNOSPAMPLEASE.ch in the cc at the bottom.

Update the documentation for the release and announce it

Once you receive the notification that DecFiles has been deployed on the grid, you should update the documentation: go to $LHCBDOC/decfiles and type
python make_df_doc_new.py v25r1
update the soft link releases/latest to point to v25r1 then edit releases/v25r1/description.html with some explanation (you can look at the examples for previous versions.
Finally send an announcement to the lhcb-gauss@cernNOSPAMPLEASE.ch & lhcb-mc-production@cernNOSPAMPLEASE.ch mailing lists with a short explanation.

-- GloriaCorti - 14-Nov-2011

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback