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 something else - 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
