Tickets

[Paul Ramsey-4]

Trying to clean down the tickets so we can get to a release state for
1.4.1 and 1.5.0 I'm struck my how many I'm just going to have to push
out to the next version. And the next. And the next.

There is a category of things that are "nice to have" that everyone
agrees are "nice to have" but yet never rise to the threshold of
someone actually *doing* them, and that list of things only grows and
grows and grows.

Kevins PIP enhancement http://trac.osgeo.org/postgis/ticket/75
Support for anonymous geometry collections in predicates
http://trac.osgeo.org/postgis/ticket/256

Both of these I examined and thought about the amount of new code and
code complexity cost was involved versus the amount of new
functionality, and put them aside again. And I'm the one most able to
do those tickets, in terms of experience with those bits. So are they
going to get done? Do we have the bloody-mindedness to drown the
kittens we don't want to keep?

I don't want to end up like Mapserver, with several hundred unclosed
tickets, being punted along year after year. I think if an enhancement
doesn't get done in two years, it should be closed out. There's a
threshold for defects probably too, though much higher.

P.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

Paul,
As long as you don't close out my favorite ones.  I can only see my dreams
shattered :)

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Friday, November 06, 2009 4:55 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Tickets

Trying to clean down the tickets so we can get to a release state for
1.4.1 and 1.5.0 I'm struck my how many I'm just going to have to push out to
the next version. And the next. And the next.

There is a category of things that are "nice to have" that everyone agrees
are "nice to have" but yet never rise to the threshold of someone actually
*doing* them, and that list of things only grows and grows and grows.

Kevins PIP enhancement http://trac.osgeo.org/postgis/ticket/75
Support for anonymous geometry collections in predicates
http://trac.osgeo.org/postgis/ticket/256

Both of these I examined and thought about the amount of new code and code
complexity cost was involved versus the amount of new functionality, and put
them aside again. And I'm the one most able to do those tickets, in terms of
experience with those bits. So are they going to get done? Do we have the
bloody-mindedness to drown the kittens we don't want to keep?

I don't want to end up like Mapserver, with several hundred unclosed
tickets, being punted along year after year. I think if an enhancement
doesn't get done in two years, it should be closed out. There's a threshold
for defects probably too, though much higher.

P.
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel



_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Kevin Neufeld]

I totally hear you and agree with you Paul.  There probably is some threshold where old tickets should get closed due to
lack of interest.  If the product has gotten by fine so far, a few unimplemented enhancements that hasn't escalated to
critical, is not going to be missed.

Sadly, this is the unfortunate reality of open source development - the coding usually falls to those that actually get
paid to do the work, or who have enough spare time to give some of it back to the community.

-- Kevin

Paul Ramsey wrote:

> Trying to clean down the tickets so we can get to a release state for
> 1.4.1 and 1.5.0 I'm struck my how many I'm just going to have to push
> out to the next version. And the next. And the next.
>
> There is a category of things that are "nice to have" that everyone
> agrees are "nice to have" but yet never rise to the threshold of
> someone actually *doing* them, and that list of things only grows and
> grows and grows.
>
> Kevins PIP enhancement http://trac.osgeo.org/postgis/ticket/75
> Support for anonymous geometry collections in predicates
> http://trac.osgeo.org/postgis/ticket/256
>
> Both of these I examined and thought about the amount of new code and
> code complexity cost was involved versus the amount of new
> functionality, and put them aside again. And I'm the one most able to
> do those tickets, in terms of experience with those bits. So are they
> going to get done? Do we have the bloody-mindedness to drown the
> kittens we don't want to keep?
>
> I don't want to end up like Mapserver, with several hundred unclosed
> tickets, being punted along year after year. I think if an enhancement
> doesn't get done in two years, it should be closed out. There's a
> threshold for defects probably too, though much higher.
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mark Cave-Ayland-3]

Paul Ramsey wrote:

> Trying to clean down the tickets so we can get to a release state for
> 1.4.1 and 1.5.0 I'm struck my how many I'm just going to have to push
> out to the next version. And the next. And the next.
>
> There is a category of things that are "nice to have" that everyone
> agrees are "nice to have" but yet never rise to the threshold of
> someone actually *doing* them, and that list of things only grows and
> grows and grows.
>
> Kevins PIP enhancement http://trac.osgeo.org/postgis/ticket/75
> Support for anonymous geometry collections in predicates
> http://trac.osgeo.org/postgis/ticket/256
>
> Both of these I examined and thought about the amount of new code and
> code complexity cost was involved versus the amount of new
> functionality, and put them aside again. And I'm the one most able to
> do those tickets, in terms of experience with those bits. So are they
> going to get done? Do we have the bloody-mindedness to drown the
> kittens we don't want to keep?
>
> I don't want to end up like Mapserver, with several hundred unclosed
> tickets, being punted along year after year. I think if an enhancement
> doesn't get done in two years, it should be closed out. There's a
> threshold for defects probably too, though much higher.
>
> P.

I think the problem here is that people are using trac to store things
that aren't bugs, such as feature requests and enhancements. For sanity
purposes, it would make much more sense to start discussions on -devel
rather than just blindly filing a ticket. Then if we decide it's valid,
that's the point at which we can ticket it.


ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mateusz Loskot]

Mark Cave-Ayland wrote:
> I think the problem here is that people are using trac to store
> things that aren't bugs, such as feature requests and enhancements.
> For sanity purposes, it would make much more sense to start
> discussions on -devel rather than just blindly filing a ticket. Then
> if we decide it's valid, that's the point at which we can ticket it.

Is it related to sanity of PostGIS Trac in general or postgis component
only? What's wrong with having non-bug tickets archived for long(er)
time, for example [1] ?

The front page says: "This Trac instance is used for bug, enhancement &
task tracking". Also, there are corresponding ticket types available.


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?

[1] http://trac.osgeo.org/gdal/ticket/227

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paul Ramsey-3]

On Wed, Nov 11, 2009 at 2:57 PM, Mateusz Loskot <mateusz@...> 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@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mateusz Loskot]

Paul Ramsey wrote:

> On Wed, Nov 11, 2009 at 2:57 PM, Mateusz Loskot <mateusz@...> 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.

Understood.

> 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*.

Understood again. Good idea this FUTURE milestone.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Chris Hodgson]

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@...> 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@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>  

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paul Ramsey-4]

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@...> 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@...>
>> 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@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mateusz Loskot-3]

Chris Hodgson wrote:
> 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.

FYI, GDAL does (at least it did a year ago) use Trac to plan
roadmap of future releases and dates, and it works well.

Best regards,
--
Mateusz Loskot
Senior Programmer, Cadcorp
http://www.cadcorp.com



****************************************************************************
This email is confidential and may be privileged and should not be used,
read or copied by anyone who is not the  original intended recipient. If you
have received this email in error  please inform the sender and delete it
from your mailbox or any other storage mechanism. Unless specifically
stated, nothing in this email constitutes an offer by Cadcorp and Cadcorp
does not warrant that any information contained in this email is accurate.
Cadcorp cannot accept liability for any statements made which are clearly
the sender's own and not expressly made on behalf of Cadcorp or one of its
agents. Please rely on your own virus check. No responsibility is taken by
Cadcorp for any damage arising out of any bug or virus infection.
****************************************************************************
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Kevin Neufeld]

I too think it's a good idea.  It follows the typical scrum agile software development methodology where one has a
backlog of tasks that are picked through to make up the current sprint, or in our case, the current release.
-- Kevin

Chris Hodgson 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@...>
>> 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@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>  
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mateusz Loskot]

Kevin Neufeld wrote:
> I too think it's a good idea.  It follows the typical scrum agile
> software development methodology where one has a backlog of tasks that
> are picked through to make up the current sprint, or in our case, the
> current release.

And that's the best rationale I could imagine :-)

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Paragon Corporation-2]

+1 .  I like that much better than keeping a side TODO that ends up being
filled with TODOs we've already done :)

-----Original Message-----
From: postgis-devel-bounces@...
[mailto:postgis-devel-bounces@...] On Behalf Of Paul
Ramsey
Sent: Thursday, November 12, 2009 1:43 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Tickets

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@...>
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@...>
>> 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@...
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel@...
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>

_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel



_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[Mark Cave-Ayland-3]

Paul Ramsey wrote:

> 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.

Yeah, that works for me. Otherwise we just have lots of
enhancements/non-fixable bugs hanging around in all of the various
milestones which is just plain messy.


ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel