[postgis-devel] Tickets

Paul Ramsey pramsey at opengeo.org
Thu Nov 12 10:43:20 PST 2009


Well let me officially propose a "FUTURE" milestone then, and a policy
that tickets in the numbered milestones get put there because someone
*commits* to closing them for release.

P.

On Thu, Nov 12, 2009 at 10:37 AM, Chris Hodgson
<chodgson at refractions.net> wrote:
> Paul I nearly suggested a "future" milestone when you originally complained
> about this problem, but then I thought that it was the fact that the tickets
> were "open" that bothered you. I think that a 'FUTURE' milestone is a good
> idea, and perhaps should be the default for feature requests/improvements.
>
> I think other projects (I know mapserver does) propose the list of things to
> include in the next release, rather than using trac exclusively to plan the
> roadmap. But really, if you have a "future" milestone, I can't see why trac
> can't be used to define the roadmap.
>
> Chris
>
> Paul Ramsey wrote:
>>
>> On Wed, Nov 11, 2009 at 2:57 PM, Mateusz Loskot <mateusz at loskot.net>
>> wrote:
>>
>>>
>>> For WKT Raster, I've recently started submitting tasks from our roadmap
>>> as tickets on Trac, as preparation for development works, because:
>>> - tickets can be assigned, then it's clear who does what
>>> - tickets draw a timeline of development, past and future
>>> - tickets archive discussion on particular topic on single page,
>>>  it's easier to keep it focused, so clear to reader and maintainer
>>> - tickets directly link to events in source tree
>>> Does the sanity thing mean we should stop using Trac for the purposes
>>> described above?
>>>
>>
>> No, because you are creating tickets that are going to be assigned,
>> completed and closed. These are "wouldn't it be nice if..." tickets.
>>
>> I think having a FUTURE milestone might help. I want to be able to
>> take a numbered milestone and *close* all the tickets and then
>> release. Instead I have to re-negotiate the same set of tickets that
>> are of low priority each and every time and push them forward and
>> forward and forward. I'd rather have people argue for putting
>> particular tickets *into* a milestone than have to argue about moving
>> tickets *out*.
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



More information about the postgis-devel mailing list