|
[Rivet] List of Rivet routinesEmily Nurse nurse at fnal.govThu Aug 7 04:26:19 BST 2008
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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.hepforge.org/lists-archive/rivet/attachments/20080806/bf68eb17/attachment.htm
More information about the Rivet mailing list |