Re: Bug tracker tool we need - Mailing list pgsql-hackers

Am 18.04.2012 14:28, schrieb Robert Haas:
> So I think Greg has exactly the right idea: we shouldn't try to 
> incorporate one of these systems that aims to manage workflow; we 
> should just design something really simple that tracks what happened 
> and lets people who wish to volunteer to do so help keep that tracking 
> information up to date. 

I tested a lot tools for bug / issue tracking and I figured out that 
almost all of them either have had
too much overhead or not really were made for database business.
Additionally more often the sentence "we support PostgreSQL" just was a 
marketing trap.
Means I figured out that the PostgreSQL support totally sucked.

My opinion is that a tool should mirror your business and not that you 
build your business around the
given tool.

Looking for a bug tracking too - there are some points that are 
mandatory for us:
1. it should run on PostgreSQL
2. it should be open source - if possible BSD license - if possible 
there shouldn't be a
single company behind it
3. it should be user friendly - no need to click here and there to get 
all informations
4. It should be able to communicate with our version control system    - when we get the idea to move away from git to
somethingelse - it 
 
should be able by just a few     changes that the tool will communicate with the new system
5. it should be possible to do almost all via email

My personal dream would be that it would be possible to do almost all 
via irc bot but that is fiction.

I think a tool should be slim and simple. It should exactly do what you 
want to do.

You should be able to change the tool code that way that it exactly is 
doing what you want to do.

Let me give you an example:
bugs.mysql.com might be far away from being perfect.
It is slim - and on developer side it has had all that the development 
needed.
My information is that originally they took the code from the php bug 
tracking system and
recoded it / implemented features so that it was doing a good job on 
database bugs.
When the developers needed tool changes or additionally features then 
they just were coded.
I never heard a developer saying that he hates the system. There just 
were lots of ideas how
this or that could be solved better. That is normal - when you are 
working with the tool every
day - of course you will get ideas what could be solved better.

So yes - I think Greg is right. We should design something really simple 
that exactly is doing
what we need. With some luck we might not need to start from scratch. 
Maybe there is a tool
outside that is slim and good enough to deliver the base code on which 
we can start recoding.

Just my 2ct,

Susanne

-- 
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com