2.18 Goals

[Bradley Baetz]

On 12 Sep 2002, MattyT wrote:

> Back End Separation
> -------------------
> 
> Bug #162613  Responsible: No One/Multiple?
> 

We're slowly doing this. I have half of a set of pages to make everything 
which just reads bugs (ie show_bug) use Bug.pm, and have removed 
bug_form.pl. Its only half, and my bugzilla hacking time is limited for 
teh next few months.

Some of the stuff lke moving tempaltes into modules can be done after 
that.

> [processmail rewrite]

My personal opinion would be to do the below as an evil evil hack, then rm 
Bugzilla/ProcessMail.pm (or whatever we call the thing) and start from 
scratch. Do this either before or after emailprefs table goes in.

Seriously, this code sucks so badly, and is so filled with evil evil
hacks, that a rewrite of most of the stuff is probably the best way to go.  
Keep some stuff like myk's recent filtering rewrite, but redo it totally
to use the activity log, now that we have it It would _greatly_ simplify
the code, and make later modifications a _lot_ easier.

> bbaetz's modularisation of processmail (bug #124174, #140782) also
> probably comes under this heading.  This will help windows and probably
> be done for 2.18.
> 

JayPee was going to trake this over, IIRC. I have very little time...

> Configurable Access Policies
> ----------------------------
> 
> Bug #110947 Responsible: No One
> 

joel had most of this going before I got him to remove some of the 
features from his groups patch so that it would be reviewed this year...

> Customised Graphs
> -----------------
> 
> Bug #105491 Responsible: Gerv
> 
> 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...

> 
> 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

> 
> 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.

> Customised Resolutions
> ----------------------
> 
> Bug #95434 Responsible: MattyT

Bug 94534, actually.

> 
> This aims to allow you to define your own resolutions.  There are 4
> classes of resolution - { successful, unsuccessful, moved, duplicate }. 
> Note you can define more than one dupe and moved resolution.  It also
> adds inactive resolutions and sortkeys as it uses the new admin system.

the patch on that bug is really incomplete, 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.

> 
> 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....

> This should be a 2.18 goal, we have waited long enough, and bmo wants
> this too.

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

> mod_perl Support
> ----------------
> 
> Bug #87406 Responsible: BBaetz?
> 
> This is a pretty substantial change to our architecture, in get the
> performance benefits of running under Apache's mod_perl.
> 
> I don't think much has been done in the way of this so far, and I think
> it should be a 2.20 goal, although new 2.18 work should attempt to be
> mod_perl compliant.

Yeah, I'm slowly moving us there, in my free time (Ha!)

> Postgres Support
> ----------------

> Secondly, there is a need to handle the simple SQL dialectal issues, by
> using ANSI SQL and by inserting subroutines to return the relevant
> dialectical SQL.  For example, regexps and date handling are different
> between the databases.

We need to remove the timestamp fields, but we should do that anyway for 
other reasons - see the bug on it.

I don't think we use regexps anywhere, do we? The only place is the query 
screen, right?

> 
> Thirdly, the administration system needs to be changed to handle PgSQL. 
> PgSQL doesn't support some field types MySQL does, eg mediumtext I
> think.  One alternative is to use lowest common denominator types,
> another is to be specific and emulate field types with the closest
> possible field type.

It does, it just uses different names. There are some differences, but its 
nothign to be worried about, since we don't use any of the obscure tyeps 
with this problem.

> 
> Fourthly, PgSQL has a dramatically different locking & transaction
> system, that is incompatible with the code we use now.  I think bbaetz
> is mooting a move to requiring MySQL transactions at some stage,
> possibly requiring MySQL 4.  This would be quite unlikely for 2.18
> however, and would probably be 2.20 at the earliest.

Having the current locking code work is probably not that hard. Having it 
work performantly is. I think that after some of the backend separation 
shakes out, then this may be easier.

> 
> It's probably possible to get some transitional code in which does the
> appropriate transactioning when it discovers locks.  This wouldn't solve
> many of our lack-of-transaction problems, but it could get in for 2.18
> and work under PgSQL.  I'm not sure how compatible this is with bbaetz's
> DBI plans, however.

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.

> I don't think this should be a hard 2.18 goal, but we should definitely
> try hard here.

This won't make 2.18. For a start, we require the pgsql version currently 
in beta for modification stuff. This can, however, happen gradually, so 
we'll see.

> Shadow Database Rewrite
> -----------------------
> 
> Bug #124589 Responsible: BBaetz
> 
> The current shadow database easily gets too out of sync, and can get
> corrupted.  This aims to rewrite the shadow database using MySQL
> replication.
> 

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

> Watching Rewrite
> ----------------
> 
> Bug #76794, #14137, #34787, #128839 Responsible: Jake/Myk?

This should be done after the processmail rewrite for simplictly, 
although thats probably not required.

It needs emailprefs, but after that the code is trivial. The UI is not, 
though....

Bradley