2.18 Goals

[Gervase Markham]

> Another part of this is the moving of the localconfig enumerations into
> the database, and giving them descriptions, sortkeys, isactive flags and
> IDs, also preventing the enumeration deletion problem.  This will
> probably be the second part, and is bug #146104.

Doesn't moving localconfig to the DB fit in with customised fields?

> The administration rewrite is fully templatised and taint mode enabled. 

I am of the view that total templatisation and l10nability should be a 
hard 2.18 target. If admin can be done, I've got the rest under control.

> I believe it isn't "customised fields" but rather "customised
> enumeration type fields".  

IMO, any decent custom fields patch should be able to support:
- enumerations (multi and single)
- text
- email address

As far as I can see, these are the three most common requested types.

> A big issue with this is how they interact with templates.  Requiring
> admins to edit templates when fields are added or removed, is, I think,
> unacceptable long term.  I believe we can make our templates adjust to
> new fields, given there's a fixed set of field _types_.

I think this is unlikely to please anyone. I don't think it's 
unreasonable to ask an admin to add the UI for a new field type to e.g. 
the query template, as long as we do _everything_ else (notice it's 
there, do the right thing etc.) Any sort of auto-generated layout is 
bound to suck.

[Generic Graphing]
> This can't be checked in before customised resolutions because it
> expects resolution IDs, but they only arrive with customised
> resolutions.  

That's not actually true - it'll store query URLs, which will still use 
the resolution name (like query URLs involving products still use the 
product name.) We can get this in before custres.

> Customised Reports
> ------------------

In hand, patch posted, review requested. Shouldn't take too long.

> I don't know whether he's planning to support stored reports for 2.18,
> but this should probably be a subsequent patch since it might require
> refactoring stored query code.

Stored will be a subsequent patch.

> I have plans to support customised indentation type reports, which are
> basically like query.cgi but grouped together.  They would have scope
> for group counts and sums, and also with the ability to only show the
> top X within a group, but not for 2.18.

You need to check out my current implementation and make sure I haven't 
used any too-generic names or burned any bridges that'll make this 
difficult.

> Along with this, I have changed the resolution set for new installations
> to { FIXED, INVALID, FEATURENOTBUG, NOTWORTHIT, DUPLICATE, WORKSFORME,
> MOVED, MISSING, CAREFACTORZERO }.  

MISSING? And what's the difference between NOTWORTHIT and CAREFACTORZERO?

[Total Localisability]
> I have no idea what Gerv is doing here, but I suppose we can claim we
> have good I18N capability even if the implementation is horrid.

There are several strands to this:
- Templatisation of everything. We need the admin CGIs done, and email - 
apart from that, we are there.
- Error message localisation. We have done all the calls which use 
Throw*Error; we now need to convert the 100+ calls to DisplayError. That 
won't take more than a few hours.

So the big blocker to total l10nability is the admin CGI templatisation. 
If that happens, this will all happen in 2.18.

> Long term we need to reconsider gettext or similiar, and also think
> about whether we want field value names and descriptions to also be
> I18Nable in the database.

We don't need gettext - we are getting along perfectly well without it. 
Field names should not be localisable; field descriptions should be in 
the templates (centralised; currently they aren't, I noticed last night) 
and not the database.

> Mail Templatisation
> -------------------

I'll take responsibility for this, but we should resolve the major mail 
bug first (84876).

> Mail Transport Rewrite
> ----------------------
> 
> Bug #84876, #65101 Responsible: JayPee/Gerv?

Dave needs to assess the two possible implementations and make a 
decision. He's needed to do that for ages :-) We recently refreshed the 
patches, and are still waiting. :-P

> Will hopefully fix our sendmailnow problems?

Yep.

Gerv