[Rivet] Fwd: List of Rivet routines

[Emily Nurse]

Hi - for those not at the meeting yesterday..
  Please remember to add a ticket with the component AnalysisRoutine  
when you are planning on writing a Rivet routine. We don't want to be  
wasting time writing the same routine twice so its quite important we  
are all kept informed.

You can look at the report:
"List of Analysis Routines"
to see what routines are being worked on (this currently includes the  
closed tickets too, but I can change this if people want).

Any other tickets related to Analysis routines should continue to go  
under the component Analysis.

Cheers,
Emily.

Begin forwarded message:

> From: Jonathan Butterworth <jmb at hep.ucl.ac.uk>
> Date: 7 August 2008 13:07:31 BST
> To: Emily Nurse <nurse at fnal.gov>
> Cc: Andy Buckley <andy.buckley at durham.ac.uk>, rivet at projects.hepforge.org
> Subject: Re: [Rivet] List of Rivet routines
>
>
>
> 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
> ~ 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.hepforge.org/lists-archive/rivet/attachments/20090130/aceee2dc/attachment.htm