From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Macdonald To: Bob Manson Cc: gnats-devel@sourceware.cygnus.com Subject: Re: proclamation of intent Date: Wed, 18 Aug 1999 14:15:00 -0000 Message-id: References: <199908182013.NAA02379@tristam.juniper.net> X-SW-Source: 1999-q3/msg00006.html On Wed, 18 Aug 1999, Bob Manson wrote: > >As a start, this format would want to be reasonable to parse as a list in > >Tcl and perl. Perhaps we need client-selectable formats: tcl, perl, sh, > >csh? > > I could see that. Want to make this as simple as possible to use, so > having that sort of flexibility would be important. > > I'm also not sure what exactly the clients would need to know, other > than the names of the fields, their datatypes, and probably > information about any restrictions on what values are valid (for enums > the set of enumerated values, regexps, etc.) Any further thoughts > would be most helpful. > > Oh, and there should be a human-readable description of the field. > Don't want to forget that! Yes, absolutely! I feel that most of the "client hint" stuff that I sent out a while ago still applies. IE which fields are to be shown in send PR, which trigger email and change reasons and audit-trail entries, etc. Have you seen all that? If not, I've pasted it at the bottom here. I think these items could just be additional fields in your proposal. eg: field "Release-Note" { multitext query-default exact-regexp send-suppress edit-requires-reason edit-requires-audit-trail mandatory } Or it could be like gnatsweb: flags "sendsuppress|editreason|audittrail|mandatory" Or whatever; I'm easy. > Ideally it would be possible for the client to get all of the data > that describes a field, but presenting this in a useful way is going > to be difficult (this quickly turnes into the traditional textual > database metadata problem). I don't see anything that the client _wounldn't_ want to get... > >It sounds like you might just use regexps. An exact match of "RickM" would > >need ^RickM$. An inexact (substring?) might be .*ick.*, *ick*, or just > >ick? > > Well, sometimes you really want to specify a string, even if it has > regexp characters in it. Obviously you can escape everything, but > that can be painful (especially for an unknowing user that's calling a > simple client like query-pr, and passing in abbreviations to search > for). > > I can also envision different search types for other data types, > primarily numeric fields. It'd be sorta nice to be able to select > ranges of PRs easily (without having to explain complex regexps to > users), or other types of numeric fields (numeric priorities? version > numbers or release qualifiers that are actual numbers?) If you have > that ability, then being able to specify string versus regexp searches > seems like a natural extension. > > As another example, perhaps we have several severity levels, and we > want all PRs that are less than serious. Yes, we can list all of the > less-than-serious priorities out in a regexp search, but it's far > easier and more accurate to specify that we want all PRs less than > serious. All of these cool things would be great. > As for the string versus substring match, query-pr currently has > varying behavior depending on what fields are being searched (some > fields trying to match with an exact regexp, others allow matches with > parts of the field). I'm not sure if this is good or bad (the choices > really seem quite arbitrary) but that's the way it's worked for a long > time. I'd rather give the user the ability to specify it, perhaps > with defaults specified in the configuration file. The current behaviour sucks; I can never remember when I need .*foo or just foo! > As for when this will be released... I was hoping to get something out > this week, probably without any of the configuration file code but > with a lot of the other changes I've been proposing. Did you pick up my file-pr changes? gnatsweb is actually broken without them. BTW - I have no idea how many of the regular contributors subscribe to this list. I hope they are all seeing this. Here's the client hint stuff. I think just the functionality of SUPPRESSED_FIELDS and FIELD_ALIASES would be obsolete with your great additions. The following are called "client hints" because front-end GNATS programs such as gnatsweb and TkGnats are free to support any and all of these configuration options. These options help give GNATS some degree of user-customizable fields until such time as the core GNATS code is modified for complete support. In the absence of the client hints, the default behaviour of any particular front-end client is up to the discretion of the client. The format is comma-separated field names. For example: MANDATORY_FIELDS="Category,Originator,Synopsis,Description" These optional parameters may be placed in the GNATS configuration file gnats-db/gnatas-adm/config. GNATS itself ignores these options. Where defaults are suggested, they are just a guideline to get the same behaviour as the gnats clients send-pr and edit-pr. Please note that GNATS currently has a limit of 255 characters per line in the config file, including the parameter name. FIELD_ALIASES: You can effectively rename any GNATS field with these aliases. The alias only affects the client interface. Behind the scenes, the GNATS PR field still has the original name. REQUIRE_AUDIT_TRAIL_ENTRY: Edits to these fields trigger entries in the Audit-Trail. "none" signals no fields. "all" signals all fields. REQUIRE_AUDIT_TRAIL_REASON: Edits to one or more of these fields triggers the prompt of one reason for all changes for the Audit-Trail. "none" signals no fields. "all" signals all fields. REQUIRE_AUDIT_TRAIL_EMAIL: Edits to one or more of these fields trigger the sending of email notification. "none" signals no fields. "all" signals all fields. MANDATORY_FIELDS: SendPR will insist that new PRs have values for these fields. EditPR will insist that editied PRs have values for these fields. "none" signals no fields. "all" signals all fields, but doesn't include Audit-Trail, Unformatted or Release-Note in EditPR because these fields are usually added by GNATS and are often blank for the first part of a PRs life. You can always add these fields if you wish. SUPPRESSED_FIELDS: Fields to suppress from view in all front-end views. SUPPRESSED_FIELDS override MANDATORY_FIELDS if a field appears in both lists. SUPPRESSED_SEND_FIELDS: See "unless" options below. Fields not to present in SendPR. Format: field[(unless)] Default: State,Responsible,Release-Note,Unformatted,Audit-Trail Example: State,Responsible(edit),Release-Note,Audit-Trail SUPPRESSED_EDIT_FIELDS: See "unless" options below. Fields not to present, or to present read-only, in EditPR. It is suggested that front-ends do not allow editing Arrival-Date, Last-Modified and Closed-Date, since these are maintained by GNATS. Format: field[(unless)] Example: Audit-Trail(admin) SUPPRESS "unless" options: Finer control over the showing of fields in SendPR and EditPR. In SendPR, the field is suppressed. In EditPR, the field is suppressed or shown read-only, at the discression or configuration of the front-end. Suppress fields: user - unless the user of the front-end asks for it. edit - unless the user has edit access. edituser - unless the user has edit access and the user of the the front-end asks for it. admin - unless the user has admin access. adminuser - unless the user has admin access and the user of the the front-end asks for it. ...RickM...