Skip site navigation (1) Skip section navigation (2)

Re: Should we keep using trac?

From: Erwin Brandstetter <brsaweda(at)gmail(dot)com>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Should we keep using trac?
Date: 2012-06-18 23:19:49
Message-ID: 84376e47-f97a-4e48-9597-6de22985e802@n16g2000vbn.googlegroups.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Jun 18, 10:35 am, dp(dot)(dot)(dot)(at)pgadmin(dot)org (Dave Page) wrote:
> On Mon, Jun 18, 2012 at 9:30 AM, Guillaume Lelarge
>
> <guilla(dot)(dot)(dot)(at)lelarge(dot)info> wrote:
> > On Sun, 2012-06-17 at 12:15 -0300, Dickson S. Guedes wrote:
> >> 2012/6/17 Guillaume Lelarge <guilla(dot)(dot)(dot)(at)lelarge(dot)info>:
> >> > Quick question: is trac the right tool?
>
> >> Which problems we are trying to solve using trac? Are they solved or minimized?
>
> > Good questions. I use it so that I don't forget a bug to fix, and a
> > feature request to work on.
>
> I think that's a reasonable and valuable use of it.
>
> >> > Maybe trac is not the right tool, and we should use something else?
>
> >> Maybe are we using it the right way?
>
> >> I like trac and redmine, the former to projects that are simple, with
> >> simple workflow, the second to more complex projects, with
> >> sub-project, ticket dependencies and, IMHO, a better notion of
> >> "progress" for tickets and milestones.
>
> >> Which goals we want to achieve?
>
> > For me, tracking bugs, and feature requests.
>
> If anything we'll move to Redmine eventually, purely because that's
> what we're using elsewhere in the project by default now.

I use trac to file the occasional bug and follow up on it. Redmine
would be just as well for me.

Regards
Erwin

In response to

pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2012-06-19 13:33:41
Subject: pgAdmin III commit: New fix for contraint trigger
Previous:From: pgAdmin TracDate: 2012-06-18 23:10:48
Subject: Re: [pgAdmin III] #360: Enum only showing as array type in new function dialog

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group