Blocker Bug Tracking Draft Page

[Tim Flink]

On Tue, 03 Jul 2012 04:15:45 -0400 (EDT)
Kamil Paral <kparal at redhat.com> wrote:

> > > Can you highlight those items that are new in any of the
> > > categories in the last 24 hours?
> > 
> > There is a limit to what I can realistically do with static html +
> > js but I can think of two ways to do that off hand. I'll see what I
> > can come up with that's realistic.
> 
> The generator script can pickle information <bug number, time added>
> and then create rows with new/recent bugs with a specific css class.
> That way it's a static content, but the generator script have to
> store information somewhere.

As I'm going through the implementation, I'm starting to wonder about
scope creep. This is starting to get more complicated than originally
proposed and I'm starting to question our strategy here as we get
farther into 'application' territory.

At what point do we either drop features or give up on the idea of
script+html and write a webapp for this?

Of course, the downsides of using a webapp instead of a script are
complexity, required development time and maintenance. However, I can
think of three things that might make writing webapp at least somewhat
worth it.

1. We need to be able to change from alpha -> beta -> final
   - If we're going to ask infra to run the script, I can think of three
     ways to do this:
      1. Ask infra to change the args to the script after freeze
      2. One or more of us gets the needed privilages to change it
         ourselves after freeze
      3. Change the script to read config from some wiki/html page to
         get the current blocker bugs (this seems like poor design to
         me, though)


2. Time between updates
   - As I mentioned before, it currently takes about 20 minutes to pull
     all of the blocker information from bugzilla using python-bugzilla.
     From what I understand, this is due to poor API performance in
     bugzilla and may change in the future. However, until this happens,
     the rate at which we're updating the page is going to be limited.

   - I've figured out a way to get the execution time down by caching
     results and altering queries to only return bugs changed since
     the last run. However, this runs into caching method and using
     a database (even sqlite3) makes more sense to me than pickles or
     json.


3. Current and Future Features
   - I'm not saying that the highlighting of new blockers isn't
     possible with script+html, I'm just not so sure it's a good idea.
     I just don't like the idea of a html generating script that
     maintains state.

   - We might want to add other features in the future (charts,
     statistics, better links to blocker-fixing updates that need
     testing, indications of blocker-fixing update karma, etc.)

   - I'm not generally a fan of putting much effort into "well,
     we might need it in the future" but the bug highlighting feature
     makes me question the wisdom of not going the webapp route.

At the moment, I'm probably leaning more towards removing features but
I have been purposely writing the code such that migration to a webapp
would be relatively painless in the future.

Thoughts?

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20120703/38d4c303/attachment.sig>