corporate win--their requirements

Myk Melez myk at
Sat Sep 28 02:32:15 UTC 2002

Gervase Markham wrote:

> What sort of timeframe is Zippy looking at to get all these 
> enhancements made?

The schedule isn't in place yet, but current thinking is to finish 
development and get everyone using the system by May/June of next year, 
with periodic deployments before then to groups willing to use a moving 

>> Product and User Views
> Does this require some sort of explicit support, or can this be done 
> by Zippy replacing e.g. search.html.tmpl with a custom "distributor" 
> template which analyses the requirements for that CGI/user/product and 
> then PROCESSes the appropriate custom template?

There's two issues here: how to do it and whether to make it custom or 
check it in.  As to the first, a distributor template might work, 
although we have to come up with a better way to define views than the 
filename hacks we're doing for formats since views are multi-dimensional 
(in other words, we don't want to have 
search-developer-Browser.html.tmpl, search-developer-MailNews.html.tmpl, 
search-qa-Browser.html.tmpl, etc.).  Maybe TT's "views" feature can help 
us here.

As to the second issue, I don't see why this should be custom to their 
installation.  Wanting to customize the interface by product and major 
user type seems like a feature a lot of installations would find useful. 
 "show bug" is overcrowded as it is, and new fields keep pouring in; 
chopping it up into targeted pages (with an option to see everything if 
you want) is something I think b.m.o would also be interested in.

> I was struggling with this problem the other day for custom graphing. 
> Is there any way of getting JS to update form fields with values 
> fetched from a server, in a way that even works in Netscape 4?

It's hard to the point of not being worth it.

>> Custom Resolutions
> Sidenote: I think we should be making the Product the configuration 
> barrier for a lot of things. Combined with the third level of 
> categorisation, we can start to make a lot of settings product-specific.


The request tracker's implementation, with inclusions and exclusions 
lists, is a good start.

>> Reopened Count
> This seems like a fairly simple RFE. Would it only have to appear when 
> the bug was in the REOPENED state, or would it also appear in the 
> ASSIGNED state?

To be really useful I think the latter.

>> Pull-down Menu of Assignees
> This is a FRFE. We should do it by using a template to define the UI 
> for user selection wherever it occurs, and making that template do all 
> the work.

What's an FRFE?

> Would the list be a global list of Bugzilla users, or restricted in 
> some way?

The latter.  Probably it would be a list specific to a product and maybe 
also component.

>> Project Management Fields
> Can you be more specific about exactly which fields are required? 
> There's a patch for this, I know. Can we implement this in terms of 
> custom fields, or does there need to be an interdependence between 
> these fields?

I'm not sure what the logic of these fields needs to be, but I suspect 
it'll be more than custom fields can handle.  I'll try to find out more 
about it.

>> System Configuration Fields
> Can we not support this request using enter_bug.cgi comment-formatting 
> templates? Or do they want to query efficiently for all bugs filed by 
> anyone using a Pentium IV processor?

The latter.


More information about the developers mailing list