==Primary Contact== Name: Brennan Ashton Fedora Account Name: bashton Group: Bugzappers Infrastructure Sponsor:
==Secondary Contact== Name: John Poelstra Fedora Account Name: poelstra Group: Bugzappers
==Project Info== Project Name: TriageWeb Target Audience: Bug Triagers, Developers, Quality Assurance. To some extent this might include the general public, as a way to see how fedora is managing bugs and developing. Expiration/Delivery Date (Required): 06/06/2009
==Description/Summary==
TriageWeb is a turbogears application that automatically queries and processes bugzilla bugs to generate user defined reports on triage related activities. Base reports include: Number of bugs of each work flow status changed for Fedora product as a whole over time Number of bugs of each work flow status changed for component D over time Number of bugs of each work flow status changed for component group E over time Number of bugs of each work flow status changed by user F over time * Number of bugs of each work flow status changed by user group G over time
Data is presented in both tabular and graphical displays (these lack some UI changes for customizing queries): Here are some samples: http://bashton.fedorapeople.org/personalstat.png http://bashton.fedorapeople.org/mainlist.png
Tabular data can be sorted and date ranges can be selected. Graphical data can have data ranges limited, as well as statuses.
Refreshes of bug data would be updated at the end of each day, as processing the few hundred bug reports changed each day take a fair amount of time.
FutureFeatures (not so far away): Will integrate with FAS so that users can store there queries for later, they also can create custom user and component groups here. Send weekly reports on rawhide bugs, and well as top reporters, triagers, and bug closers. A Look Into Rawhide --This is an idea that I discussed with jlaska, the idea is that this is a work bench that people can visit to see how we are progressing with blockers as milestone are reached. This would also include a section that more effectively then bugzilla, shows the top duplicated bugs, so that developers and traigers spend less time having to sort through 50 dup bug reports filed when component X failed today. Create a section where FAS groups and users can create a monitor goals that are compared to standard queries. What this means will be partially determined by feedback on what people use and how they use the core features.
==Project Plan== Currently the project is locally hosted and is in a nearly usable state already. There is still one known bug in the scripts that pull data from bugzilla, this just requires going back and tracing what types of bugs cause the error and then fixing the script to process these correctly. In a week or as soon as the RFR is granted, people are wanting to start testing the app, the triage group is especially eager to start using it, this will give me significant feedback as to what needs to be changed or added. After this has become stable, I will request that the application be pushed live as a release application. I need to start looking into optimizing the database queries and format, as the application is database intensive. * Once the core app is running smoothly I will start to integrate and develop the tasks outlined in FutureFeatures in the order that I have listed them. The development of these features will mostly take place during the months of June and July, and then continue at a slower pace during the school year where the focus will be primarily maintenance and bug fixes as I will have more limited time.
==Specific Resources Needed== Webspace to run the turbogears application Ability to create cron jobs for daily data fetching scripts (no more then an hour each day) --When rebuilding the database to introduce feature requests a script will take around 10-12 hours. This should happen only very occasionally, and does not take much processing power as most of the time is spent doing xmlrpc communications with bugzilla. Database space to store metrics data as well as user preferences. The metrics data right now in a sqlite db is only a few MB, I would not expect it to grow beyond 50MB even with heavy user usage. I have no preference between MySQL and postgresql Package wise all dependencies are in fedora already, with the exception of traigeweb itself. --Python --TurboGears --python-turboflot --python-fedora --python-bugzilla --python-sqlalchemy --python-numeric --httpd There may be a few others, but that should be a very representative list.
==Goals==
The point of this project is to give the traige, packaging, and QA groups some new tools so that they can better measure there status as well as monitor critical areas. This should especially help with the development cycles once some of the FutureFeatures have been introduced. This also allows fedora to better recognize the commitment of some members in the community who spend there time in the drudgery of processing, reporting, and solving bugs.
==Other Notes== * I am looking for someone in the sysadmin-web group to sponsor me.
As mentioned at https://www.redhat.com/archives/fedora-infrastructure-list/2009-May/msg00188.html, the Expiration/Delivery date is being pushed to July 6, 2009.
Hey, could we get a quick status update on this since it's almost July 6th? (Don't worry, we're not going to take everything down all of a sudden at that point.) I hope everything has been going well with this project.
We are moving forward with this. I have been rewriting core parts of this so that it will allow it to progress in the direction that the community wanted after seeing the initial release. In the next few data I will be updating this to a version that include FAS connection, as well as fix many of the bugs that were identified. After a short period of testing this should be able to go live. I will need assistance in tweaking the configuration files and such for the full fedora infrastructure system.
Hey, you're still using publictest14 for this, right? We'd like to rebuild it once you're done with it, since the machine is about 9 months old now (no rush at all though, we just won't be putting any new projects on it).
Whats the status here? Over 2 years without a comment. :)
Can you reopen this if it's still (or again) in progress, or file a new RFR if you want to persue it down the road?
Sorry I saw this on the that infra agenda items and forgot to reply. I thought I had closed this RFR, we are still wanting to do this, however the approach is being changed. Rather then running yet again another service, I am working on integrating this work into fedora community. I spoke to Luke about this a few weeks ago and we agreed it made some sense. This will also tie into the AMQP work that I have been wanting to get going on.
Login to comment on this ticket.