[Rivet] List of Rivet routines

[Jonathan Butterworth]

Emily Nurse wrote:
> ok, I've made a new component (AnalysisRoutine) and a new report that 
> selects on this component.
> http://projects.hepforge.org/rivet/trac/report/9

great! Other people who are planning to write, or requesting routines, 
please add tickets using the same format /fields as Emily has used here.

Cheers,
Jon

> 
>> It might be nicer to keep them separate from normal tickets and 
>> exclude them
>> from normal views, but to refer to active tickets that affect those 
>> analyses.
>> Otherwise we'll never get to close analysis tickets - just move them, 
>> which is
>> a bit artificial - and the tickets will become long and full of expired
>> information.
> 
> I can do this by actively requiring that the other reports don't list 
> anything with AnalysisRoutine as the component, do you want me to do that?
> 
> I'd like to be able to group these by experiment, the only way I can 
> think of implementing this without adding more custom fields is to put 
> the expt. name in the key words of the ticket. Does anyone know of a 
> better way than this? It would be better if it were a drop down menu but 
> I don't want to mess with the other tickets too much.
> 
> 
> Cheers,
> Emily.
> 
> On 4 Aug 2008, at 12:53, Andy Buckley wrote:
> 
>> Jonathan Butterworth wrote:
>>> Hum.
>>>
>>> Using the ticketing system was my idea. This is supposed to be a sort of
>>> to do list (at least in my understanding) so the ticketing seemed to be
>>> appropriate. They can reported as tasks rather than bugs, and there are
>>> then email notifications for people interested (can add themselves to
>>> the cc field) in a given routine etc. Plus we can use prioritisation,
>>> assign them to milestones/release etc etc.
>>>
>>> For user documentation of analyses, I think doxygen comments should be
>>> used. I'd resist having a wiki page too, too many sources of
>>> (potentially inconsistent) info to maintain.
>>
>> Yes, I agree with that: synchronisation is best done by keeping 
>> documentation
>> close to the code. Actually, I think we should put a lot more metadata 
>> in the
>> analysis classes themselves. For example, a nice feature would be for each
>> analysis to have a "long description" or comment field, in which all 
>> current
>> issues, generator settings etc. are described, which could then be 
>> queried on
>> the rivetgun command line or via the API.
>>
>> I would prefer to have this than either a set of always-open tickets or
>> outdated wiki pages.
>>
>>> I was thinking a component like Emily suggests would be good, then we
>>> can set up a DB query which gives all analyses in progress or requested,
>>> with people assigned to them (if any) and progress/priority. And once
>>> they are written, the ticket could just refer people to the doxygen page.
>>>
>>> Does that make you happier Andy?
>>
>> Okay, I'll be open minded for once and see how it pans out!
>>
>> It might be nicer to keep them separate from normal tickets and 
>> exclude them
>> from normal views, but to refer to active tickets that affect those 
>> analyses.
>> Otherwise we'll never get to close analysis tickets - just move them, 
>> which is
>> a bit artificial - and the tickets will become long and full of expired
>> information.
>>
>> I think another more substantial thing that would be very useful would be
>> periodically-generated plots from all Rivet analyses, available from 
>> the Web.
>> But that a) requires a lot of CPU and b) is replicating a lot of JetWeb
>> functionality (has anything happened on JetWeb, by the way?) Any comments?
>>
>> Andy
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prof. Jonathan Butterworth,              http://www.hep.ucl.ac.uk/~jmb/ 

Physics and Astronomy Department                  Tel: +44 20 7679 3444
University College London                 Gower St, London WC1E 6BT, UK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~