2.18 Goals

[MattyT]

On Thu, 2002-09-12 at 22:29, Bradley Baetz wrote:

>> Rewrite of graphing so that you can graph anything (but not
>> retrospectively).  This also involves moving the graphing parameters and
>> results into the database.
> Why not retrospectivly? We have a patch for collectstats + regeneration 
> sitting in bugzilla...

Retrospectivity merely isn't part of the customised graphs project. 
That's not to say it won't be done, but that it won't be done here.

I do however have misgivings about retrospectivity, given bug activity
has numerous bugs, both the truncation bug we had, and the lack of
recording renamings by administrators.

>> This can't be checked in before customised resolutions because it
>> expects resolution IDs, but they only arrive with customised
>> resolutions.  Unfortunately, customised resolutions can't be checked in
>> before customised graphs either, so they need to go in at the same time.
> Why can't custres be checked in before this? The other way arround would 
> proably be painful, but getting the current charting to work with custres 
> would just involve some resolution_id_to_name calls somewhere

The problem is that the current system keys things of name rather than
ID, and it would be very difficult for custres to try and touch this
stuff.  I forget the specifics, but I remember this way was a lot better
(or so I thought before tonight).

>> We could split these apart, but one of them would need transitional code
>> that would be going away.  Normally this would be OK, but it involves
>> schema changes.
> It would need transitional code, but I'm not sure that it would need a 
> lot.

Maybe, but I reject the idea of transitional schema changes we have to
support but never actually use.  There are probably plans that could
avoid this, but I've yet to hear a good one.  Now is probably a good
time to discuss this, I suggest you look at the old charting system.

> the patch on that bug is really incomplete,

That's because it's old, the work moved onto CUST_RES_BRANCH a long time
ago.  The branch is the latest, except for the admin architecture which
I might have changed on my hard disk for the keywords rearchitecture. 
However it is out of date with HEAD, for example stuff is still in
template/default.  Most of my energy is hence on the admin rewrite of
keywords ATM.

> but that description sounds 
> like its trying to do quite a lot. I think that you should leave out MOVED 
> for the moment - theres a bug open somewhere on allowing moving to 
> multiple installations, not to mention that move.pl is probably in want of 
> a rewrite soonish.

It's all done - I originally envisaged DUPLICATE and MOVED having
hardcoded IDs, but I discovered it was actually so much work to do well
it was easier to do things this way.  Separate moving work can happen on
separate patches.

>> This also possibly cannot be checked in before quicksearch is rewritten
>> in perl, because the current quicksearch uses a hardcoded file called
>> localconfig.js which the admin needs to update manually (but this is
>> possibly not a problem because there is currently the same issue with
>> keyword renaming I believe).
> Well, we could just have the js not do validation....

I believe the problem isn't validation, it's taking a piece of text and
understanding what field it's from.  I could be wrong, however.

> Not unless a patch appears. We want 2.18 this year.... :)

It is pretty much ready.  The hard part is everything keeps shifting,
and it would break things by being checked in.

> The DBI will, to a large extent, make discovering what is being done hard. 
> Not impossible (and fairly easy for LOCK, in fact), but in general its 
> Hard.

This worries me a bit, but we can always add front end subs for special
situations, especially for transactions/locking as my original plan
was.  The hard part would be ensuring we use the front ends, however.

> Its not actually a rewrite, its more a removal. This is done, and awaiting 
> myk's testing.

I call adding code and removing code that do pretty much the same thing
a "rewrite".  Kind of like new and old email tech coexisted for a time.

-- 
         Matthew Tuck: Software Developer & All-Round Nice Guy        
 My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award
1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic
         Emperor 1998 Released From Smith Psychiatric Hospital