[postgis-devel] [WKT Raster] Porting Wiki and documentation

[Mateusz Loskot]

Pierre Racine wrote:
> This is great Mateusz,
> 
> I was to do something similar after easter but you`re just too
> quick...
> 
>> 3. "Translate" all micro-Beta versions to Beta versions:
>> 
>> 0.1a -> wktraster-0.1 0.1b -> wktraster-0.2 0.1c -> wktraster-0.3 
>> ... 0.2a -> wktraster-0.8
> 
> What would you think about:
> 
> 0.1a -> wktraster-0.1.1 0.1b -> wktraster-0.1.2 0.1c ->
> wktraster-0.1.3 ... 0.2a -> wktraster-0.2.1 0.2b -> wktraster-0.2.2
> 
> instead?

Whatever that is close to popular version
numbering based on Major.Minor.Patch works for me.

http://en.wikipedia.org/wiki/Software_versioning

> I would suggest we translate just a couple of them and keep a general
>  planning page so we don't pollute too much the system with our
> tickets and we leave room for major changes in the planning.

I just suggested tickets to gain decent level of maintainability.
A ticket is like a record in a database, so it's easier to change single
record to update the whole report, instead of digging the report itself.
I don't think that number of tickets makes PostGIS Trac more/less
polluted. Simply, WKT Raster will get own reports.

> We never know, maybe at some point we will merge everything with
> PostGIS.

That's what I'm saying, Tickets will make it easy.

> This would make us benefit much from the system now and keep a plan
> (easily modifiable) for the future. This is a bit what I did in the
> actual wiki.

If you are going to maintain the big table on Wiki, go for it.
I've found it more time consuming than Ticket'ing, so I just suggested
my preferred option.

> There is only two planned milestones and all the rest is in a single 
> page that we can divide in more versions later.

OK

>> 4. Submit each task specified in the planning & funding as a
>> separate Ticket. Such tickets could include all corresponding
>> details like
> schedule,
>> timing, funds, status and could be easily assigned (and reassigned
>> if needed) to partic0.2)  and to developers using Trac features.
> 
> Then we would not need the specifications pages?

Not really. I mean that we can generate planning/roadmap pages.
If we store all tasks as tickets, then we can just generate
roadmaps per milestone automagically using Trac custom reports:

http://trac.osgeo.org/postgis/report

and Trac Roadmap:

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

> Can we just modify a ticket entry?

For tickets, you can:
- submit new ticket
- modify content of ticket
- modify status of ticket
- modify ownership
- add comments - make a kind of specific and focused discussion
- close
You can not delete ticket, because ticket should be archived.

> Or we can just add replies?

Replies? You mean comments?
Yes, you can comment but you can still modify existing ticket.
And you can track changes to such ticket.

For instance, see this ticket I maintain for libLAS:

http://liblas.org/ticket/52

I changed description number of times, recently I changed also summary
(title) of the ticket after I extended the idea.
Tickets also are versioned, see diff's for ticket updates.

> A wiki spec page has the advantage of resulting in a more readable
> document. If we can edit the first entry of a ticket then propably it
> would be better to convert wiki spec pages into tickets.

I've just proposed that if planning is about keeping files/records,
and generating reports then perhaps tickets and Trac reporting
features will work:

[1] http://liblas.org/wiki/TracRoadmap
[2] http://liblas.org/wiki/TracQuery

>> 5. The Roadmap and milestone TracLinks can generate reports
> automatically,
>> so there is no need to craft complex tables on the Wiki page.
> 
> Can we get our own milestones? Or we will have to follow PostGIS
> ones?

This is what I originally asked PostGIS folks, if we can maintain
WKT Raster milestones along, meaning add them to the Milestone drop-down
box:

wktraster-0.1.0
wktraster-0.1.1
wktraster-0.2.0
...

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org