Re: 3.113 vs 4.0

[Rick Macdonald <rickm@vsl.com>]

On Thu, 13 Jan 2000, Wasserman, Sherry wrote:

> I was recently charged with the task of incorporating some custom changes
> into the gnats system my company has been using for many years.  Apparently,
> years ago, my predecessors managed to get 3.2 (I can hear your groans!)
> working and made enough changes that upgrading was not desirable.  

Groan!   ;-)

> I have suggested upgrading to the current gnats before adding any new
> features, and have gotten the ok.  I have started working on 3.113, and know
> that we can make use of many of the added features.  However, I'm beginning
> to wonder if I should hold off with customization until I can go to 4.0? 

It's probably an issue of timing. I'd wait if I could.

> Do you have a good estimate of when 4.0 will be released?  

The very first usable release could be real soon now, at least that was
the plan a week ago.

> What are the major changes? 

I'm not sure if this is written up in a single doc anywhere yet.

> Is there a fairly stable 4.0 that I could start looking at now?

I don't think there is a current tarfile snapshot. There is cvs access to
the source tree, and instructions on the Cygnus web page.

> We will want to incorporate a web interface.  Will a new version of gnatsweb
> be required?  If so, is there any info on when that will be ready?

New version, yes. The V4 author mentioned that he has updated gnatsweb, if
I understand his passing comment correctly.

> And finally, the change we are planning, in case you might be thinking along
> these lines: 
> 
> We need to track PRs by software release.  We want to have multiple release
> number fields, where the release number is validated (send-pr as well as
> edit-pr) by checking a file.  Then,  for each release there must be an
> associated state.  As a PR is acted on for a specific release, the
> associated state will be changed. When all releases have been taken care of,
> the PR is closed and an overall state would be set.  (Of course, we will
> have to be able to query by release number and state and the query will
> check all of the release fields.)

The first release may not actually allow adding and removing fields, but
that's certainly the intent. Just about everything is configurable. You
could, I hope, do something at least as good as this:

Others please jump in here if I'm wrong or missed out some possibilities.
I'm just going by past plans and talk but haven't worked with the current
sources yet.

Configure gnats with some number of release fields. Each of these could be
a simple text field where you type in a release number which would be
validated against a regular expression (by gnats), or, they could be
enumerated fields which would appear as radio buttons or a listbox in the
front-end GUI in which case validated is redundant since the GUI choices
were built on the fly from a fresh config fetched from the server. (Of
course the sever is going to validate the choice anyway.) From
time-to-time you would diddle the enumerated list of release numbers for
these fields.

My choice would be the enumerated fields, not simple text.

Similarly, you would define some enumerated release-state fields to match
the release fields. Gnats will supply query capabilities for all of these
new fields.

If I got the above right, you haven't had to change the gnats core at
all! Pretty cool, eh? Like I said: I'd wait if I could!

...RickM...