gnats v4 -- the Big Question

gnats v4 -- the Big Question

[Kenneth H. Cox]

Hello folks,

I have taken a look at the latest gnats in CVS (the squirrel2 release).
Before I embark on the relatively large project of changing gnatsweb to
support gnats v4, I'd like to ask the Big Question: What are the design
goals of v4?

I like gnats.  I use gnats.  But I have 3 big problems with gnats,
make that 4, only one of which I think is being solved by gnats v4.

1. I want to have some new or modified fields, e.g. version should be
   enum, and I'd like to have a "fixed in" field which contains the
   version number which contains the fix.  This I think is well handled
   by gnats v4.

2. There are things which I'd like to do which I can't, which would
   work better in an RDBMS.  For example, after Joe leaves the project

	update bugs set responsible='kenstir' where responsible='joe'

   Or for reporting the bugs within the last 7 days

	select id,creation_date from bugs
	where creation_date < CURRENT_DATE() - 7

   Not that I can't do this inside gnatsweb; I can.  But now we're using
   gnats as a support call tracker, I have the feeling that I'll be
   asked to supply such stats on a weekly or monthly basis.

3. I have to maintain gnats myself.  It doesn't require a whole lot of
   work.  I'm guessing that if gnats were implemented on top of an RDBMS
   like MySQL, then I could interest somebody else in learning it and
   handling the maintenence.  That way, while they were learning gnats
   they would also be learning MySQL which would help them in other
   areas and which they could write on their resume etc.

4. Gnatsd is not blazingly fast.  I attribute this to the fact that
   gnatsd is started up from inetd for each connection.  As of v3
   there was no other way to do it.  Is this addressed in v4?

Regards,
Ken

Re: gnats v4 -- the Big Question

[Paul Traina]

Actually, Bob has been doing major restructuring under the covers
so that in a future release of gnats, we can make it run under a
RDBMS like MySQL.  We decided to *not* complete that until after
4.0 shipped (4.0 needs to get out the door).

I have never noticed gnatsd being slow at start, but didn't really
pay attention.  There is a lot of stuff going on when init_gnats()
is called, which hopefully will become more streamlined as we go.

Does gnatsweb open up a new gnatsd every time a HTTP request comes
in?  I'll assume the answer is yes...?  Since http 1.1 and later
have persistance, is any of that around in Perl5 modules so that
you can easily keep context between cgi invocations?

On Thu, Dec 16, 1999 at 11:07:01PM -0500, Kenneth H. Cox wrote:
> Hello folks,
> 
> I have taken a look at the latest gnats in CVS (the squirrel2 release).
> Before I embark on the relatively large project of changing gnatsweb to
> support gnats v4, I'd like to ask the Big Question: What are the design
> goals of v4?
> 
> I like gnats.  I use gnats.  But I have 3 big problems with gnats,
> make that 4, only one of which I think is being solved by gnats v4.
> 
> 1. I want to have some new or modified fields, e.g. version should be
>    enum, and I'd like to have a "fixed in" field which contains the
>    version number which contains the fix.  This I think is well handled
>    by gnats v4.
> 
> 2. There are things which I'd like to do which I can't, which would
>    work better in an RDBMS.  For example, after Joe leaves the project
> 
> 	update bugs set responsible='kenstir' where responsible='joe'
> 
>    Or for reporting the bugs within the last 7 days
> 
> 	select id,creation_date from bugs
> 	where creation_date < CURRENT_DATE() - 7
> 
>    Not that I can't do this inside gnatsweb; I can.  But now we're using
>    gnats as a support call tracker, I have the feeling that I'll be
>    asked to supply such stats on a weekly or monthly basis.
> 
> 3. I have to maintain gnats myself.  It doesn't require a whole lot of
>    work.  I'm guessing that if gnats were implemented on top of an RDBMS
>    like MySQL, then I could interest somebody else in learning it and
>    handling the maintenence.  That way, while they were learning gnats
>    they would also be learning MySQL which would help them in other
>    areas and which they could write on their resume etc.
> 
> 4. Gnatsd is not blazingly fast.  I attribute this to the fact that
>    gnatsd is started up from inetd for each connection.  As of v3
>    there was no other way to do it.  Is this addressed in v4?
> 
> Regards,
> Ken

Re: gnats v4 -- the Big Question

[Kenneth H. Cox]

On Fri, 17 Dec 1999, Paul Traina wrote:
> Actually, Bob has been doing major restructuring under the covers
> so that in a future release of gnats, we can make it run under a
> RDBMS like MySQL.  We decided to *not* complete that until after
> 4.0 shipped (4.0 needs to get out the door).

That is quite encouraging, and I agree with your decision to not hold up
4.0 for that reason.

Bob: are you on this list?  I'd like to have your opinion on these
matters before I do any work.  I want to make sure that I understand your
goals for 4.0, so that possibly gnatsweb and I can "support" these goals
through appropriate code changes.

> Does gnatsweb open up a new gnatsd every time a HTTP request comes
> in?  I'll assume the answer is yes...?  Since http 1.1 and later
> have persistance, is any of that around in Perl5 modules so that
> you can easily keep context between cgi invocations?

Yes it does.  I don't know of any appropriate Perl modules.  I use
Apache w/mod_perl here, so that the gnatsweb code itself is
loaded.  However, there is no gnatsd connection caching done.  I assume
something like Apache::DBI database caching is possible, since repeat
connections from the same user/database could be reused.

> On Thu, Dec 16, 1999 at 11:07:01PM -0500, Kenneth H. Cox wrote:
> > Hello folks,
> > 
> > I have taken a look at the latest gnats in CVS (the squirrel2 release).
> > Before I embark on the relatively large project of changing gnatsweb to
> > support gnats v4, I'd like to ask the Big Question: What are the design
> > goals of v4?
> > 
> > I like gnats.  I use gnats.  But I have 3 big problems with gnats,
> > make that 4, only one of which I think is being solved by gnats v4.
> > 
> > 1. I want to have some new or modified fields, e.g. version should be
> >    enum, and I'd like to have a "fixed in" field which contains the
> >    version number which contains the fix.  This I think is well handled
> >    by gnats v4.
> > 
> > 2. There are things which I'd like to do which I can't, which would
> >    work better in an RDBMS.  For example, after Joe leaves the project
> > 
> > 	update bugs set responsible='kenstir' where responsible='joe'
> > 
> >    Or for reporting the bugs within the last 7 days
> > 
> > 	select id,creation_date from bugs
> > 	where creation_date < CURRENT_DATE() - 7
> > 
> >    Not that I can't do this inside gnatsweb; I can.  But now we're using
> >    gnats as a support call tracker, I have the feeling that I'll be
> >    asked to supply such stats on a weekly or monthly basis.
> > 
> > 3. I have to maintain gnats myself.  It doesn't require a whole lot of
> >    work.  I'm guessing that if gnats were implemented on top of an RDBMS
> >    like MySQL, then I could interest somebody else in learning it and
> >    handling the maintenence.  That way, while they were learning gnats
> >    they would also be learning MySQL which would help them in other
> >    areas and which they could write on their resume etc.
> > 
> > 4. Gnatsd is not blazingly fast.  I attribute this to the fact that
> >    gnatsd is started up from inetd for each connection.  As of v3
> >    there was no other way to do it.  Is this addressed in v4?
> > 
> > Regards,
> > Ken
> 

--
Kenneth H. Cox
Software Guy
Sente, Inc.