2.18 Goals

[MattyT]

On Thu, 2002-09-12 at 21:49, Gervase Markham wrote:

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

It could do, I hadn't really considered this.  My current plan is to get
the customised fields to use the administration rewrite if possible - so
it would be an alternate route to the same thing.

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

And there is also something to say for simple patches.  There's no need
to save the world in one patch.

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

It doesn't have to be perfect.  As BBaetz said elsewhere, admins are
free to fix up the template if they don't like it, all we need is a
reasonable layout to get an installation up to speed quickly.

We don't even need to put all unrecognised fields at the bottom. 
Grouping all fields of the same type together is a way of providing a
decent layout, possibly better than the one we have now.

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

Then I'm not sure why you said you could resolve the renaming problem. 
Sure, we could handle query URLs, but current custres doesn't do this
for stored queries for example.  Query URLs are a dead end that we
should be expunging from the code base, not adding to.  But I suppose it
is OK as a transitional thing.  It renews my enthusiasm for
rearchitecting query URLs, however.

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

I will hopefully get around to this.

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

MISSING means the URL referenced is 404 or such.  Perhaps it should
become part of NOINFO, a more general resolution for bugs that have sat
in NEEDINFO status with no info supplied.  But that probably shouldn't
be done until NEEDINFO is here, ie customised statuses are here.

NOTWORTHIT is for rejecting RFEs in non-OSS projects.  CAREFACTORZERO is
more of a plain insult.

> We don't need gettext - we are getting along perfectly well without it.

We also have had no experience with localisers keeping their templates
up to date or not.

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

I am referring to field _value_ names and descriptions, not field names
and descriptions.

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