trac milestone suggestions

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

trac milestone suggestions

Greg Troxel

Because of the recent discussion about remaining tickets for 2.2.2, I
went to look at:

  https://trac.osgeo.org/postgis/roadmap

and noticed that some of the dates didn't quite seem right.

I would suggest:

  Closing the 1.3.7, 1.4.3, 1.5.9 milestones.  There are no outstanding
  tickets and it seems really clear there will be no more releases on
  those branches, even if an egregious security bug arose.

  Maybe closing 2.0.8, after moving tickets forward to 2.2.2.  It's not
  clear if these are ok on 2.2, and need fixing on 2.0.8.  It seems
  fairly clear there won't be any more 2.0.x releases, but I'm not
  really sure.

  Similarly for 2.1.9.

  if 2.1 and 2.0 are kept, set dates ahead so that 2.2 sorts first, then
  2.1, then 2.0.

  Move the "management 2.0" date to about 5 years in the future, so it's
  ahead of "postgis future" but behind all actual planned releases.

  Figure out what "Postgis Future" vs "Postgis GEOG", etc. means and
  probably merge them.  It seems like these aren't really distinct and
  are just tickets not planned for any release.  The components of
  tickets and the milestone names don't seem entirely correlated..
  Having a date 10 years out for "future" makes sense to me, as a place
  to park unplanned work.

So we'd then have milestones in order:

  2.2.2 (with a realistic or at least plausible planned next release
  date)

  2.1.x (with a realistic date if planned, or if it's just there in case
  there is a serious bugfix, maybe 2years out)

  2.0.x (a month after 2.1.x)

  mananagement 2.0: maybe 9 years out

  postgis future: 10 years out

and that's it.  Presumably 2.1.x would have only tickets that are known
not to apply to 2.2 (fixed, or in 2.1-specific code), and I would think
most of those would get moved or closed.

This is not a big deal, but it would be pretty easy to clean up and then
roadmap would be easier to follow, 1 page instead of 2+.


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel

signature.asc (186 bytes) Download Attachment