Summary of L2 Tagset Plan from Peter Wittich 
--------------------------------------------
	Feb 6, 2002


The recap of the discussion on Tuesday re: l2 tagsets is
attached. Please correct and amend as needed.

We will create a data base table (lingo?) with the following notation:

# L2 tagset number
* package tag 1, whose column label is the package name
* package tag 2, whose column ....
* package tag 3, whose column ....
* number of alphas
o retired

I hope I got the Oracle-speak right. 
--> There is a one-to-many mapping between a physics table and version
   number and a level 2 tagset.

Use cases
---------
I will try to outline the use cases below.

When generating a new trigger table or trigger table version
------------------------------------------------------------
In the process of creating a trigger table, we generate a new tagset
once all tests and validation is complete. This includes compiling
the alpha code.

-> Outstanding issue here: how to store default version of
information that goes into the tagset, so that the person generating
a new trigger table doesn't need to know what data base to use?

When updating the alpha source code
------------------------------------------------------------
There will be instances where we want to update the alpha code while
keeping the trigger table and version number constant. In this
instance, we would want to start with an existing tagset, update the
cvs tags associated with it, compile the new code and, on success,
generate a new L2 tagset.

When changing the number of alpha processors used
------------------------------------------------------------
I think this is bascially the same as before, except now, we are not
changing the CVS tags but changing the number of alpha processors
used in this tagset.


As far as how this would work operationally, here is a description, 
which is I think the implementation of the above. Thanks to Jonathan for 
this, with some slight modifications.
-- 

  1. GUI performs all checks and commits table to DB
  2. GUI opens L2 compile panel for user to specify L2 compiliation
     options. Every time I use it, I click use defaults
  3. Java code spawns process to create L2 exe(s). Perhaps exe is
     called by a temporary name. When compilation is complete, tagset
     is made in DB and exe name is changed to L2_T<tagset>_P<proc>.exe
     I'm not sure which element does the actual sql insert for the tagset.

When we want to generate a new L2 exe, or change the number of alphas we 
use, we could from the Trigger Tables panel have a button for "Recompile 
L2" which takes you to step 2 above.
--