On Tue, 03 Jul 2012 04:15:45 -0400 (EDT)
Kamil Paral <kparal@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
