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

Re: Should we keep using trac?

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Should we keep using trac?
Date: 2012-06-18 08:35:38
Message-ID: CA+OCxowniPHpB_p79-GECHACwTUE5DqM+gY8KnQcHrwjazeinw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Mon, Jun 18, 2012 at 9:30 AM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> On Sun, 2012-06-17 at 12:15 -0300, Dickson S. Guedes wrote:
>> 2012/6/17 Guillaume Lelarge <guillaume(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.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgadmin-hackers by date

Next:From: Dickson S. GuedesDate: 2012-06-18 11:35:41
Subject: Re: PoC: Little improvements to EditGrid - Enum ComboBox
Previous:From: Guillaume LelargeDate: 2012-06-18 08:32:40
Subject: Re: Odp: pgAdmin website commit: Ugh, fix for a huge mistake

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