Weekly IRC 2008 May 19

1. what is up
2. we're moving to mvn 2.0.9
3. Graduation work: headers, review.txt
   #"Fix Versions" in JIRA

. desruisseaux has changed the topic to: Weekly IRC 0) what is up 1) we're moving to mvn 2.0.9 2) Graduation work: headers, review.txt 3) "Fix Versions" in JIRA
<desruisseaux> Shall we start?
<aaime> sure
<desruisseaux> 0) What is up
. aaime bug fixing for the releases, running CITE tests, and making the releases
<desruisseaux> Martin: MosaicImageReader again (working on the special case where the grid is regular - no need for an RTree in this case)
<acuster> acuster — starting on isogeometry module; looking into Hg -> subversion pathways
. groldan is hacking hard on ArcSDE, implementing per connection command queue
<acuster> chorner, dwins elizard ggesquiere hbullen mgrant pramsey vheurteaux ?
<pramsey> ?
<vheurteaux> yep ! hello
<desruisseaux> What is up
<vheurteaux> boring things non GT related
<acuster> weekly IRC meeting if you all want to pitch in
<acuster> going twice....
<desruisseaux> 1) We are moving to mvn 2.0.9
<acuster> we have cedric's patch waiting
<acuster> I'm planning to apply it tomorrow so I don't have to think about it anymore
<acuster> so everyone should be using maven 2.0.9 now
<acuster> that's all
<groldan> does it mean the build won't work anymore with < 2.0.9?
<groldan> ah ok
<desruisseaux> It is likely to continue to work
<acuster> not sure
<desruisseaux> (I means likely to continue to work with 2.0.8)
<acuster> but 2.0.9 will be our default
<desruisseaux> But using 2.0.9 would be more determinist.
<groldan> okay, cool
<desruisseaux> 2) Graduation work
<acuster> We are ready for the final push
<acuster> module maintainers will be responsible to update all headers and the review.txt files
<acuster> also I'd like to review where the data in sample data came from
<acuster> and get data with overlapping data with non-identical projections in the shapfile group
<acuster> sorry
<groldan> yeah, I got rid of all sample data in sde some time ago just because I didn't remember where it came from
<acuster> and get overlapping data with non-identical projections in the shapfile group
<acuster> for the modules of you three what's a reasonable deadline for this work?
<aaime> Eh, officially I'm the maintainer of postis-versioning only
<aaime> and can help on rendering and jdbc
<aaime> but that's it I guess
<acuster> okay, the plan is to push a bunch out now and use that to pressure the slower folk
<acuster> that's all I guess
<groldan> at one time I thought the review was meant to be done by someone else than the module maintainer?
<groldan> but I might be wrong
<acuster> ooo, I like the idea
<acuster> okay, so we'll revisit this once we get some modules done
<acuster> next?
<groldan> sure
<groldan> ?
<groldan> desruisseaux: I guess floor is yours?
<desruisseaux> JIRA
<desruisseaux> More precisely "Fix version" in JIRA description.
<desruisseaux> Can we let it to "unknown" when the reality is that we don't know?
<groldan> so your concern on the ml makes sense
<groldan> and yes, we seem not to have a policy about that?
<desruisseaux> A while ago the policy was to always set a fix versions on the basis that task without fix version fall in a black hole.
<desruisseaux> Maybe it is true for task without assignee.
<groldan> I wonder how much more work that would be for someone like andrea, who gets almost every issue reported assigned to him
<groldan> but that's in geoserver
<groldan> in geotools things may be a bit different
<aaime> From where I stand they are exactly the same
<aaime> I have so many issues assigned to myself
<aaime> that everything not exactly in the next release jira will be completely ignored
<aaime> black hole effect
<aaime> Stuff in the next release will be at least looked at, not necessarily fixed, mind that
<groldan> what I can say is that it is already hard to go thru the next version list and decide what one can actually achieve
<desruisseaux> Not sure if we are allowed to have a "maintainer-by-maintainer" policy. But on my side, I look from time to time to the list of tasks I'm assigned too. So even if they are not scheduled for every releases, I see them.
<desruisseaux> I also tend to look at every tasks reported against metadata and referencing modules, so tasks for those one do not fall in black hole neither.
<aaime> I don't see a problem with a "maintainer to maintainer" approach
<desruisseaux> May take a long while however (unfortunatly...)
<aaime> Yeah, for me it's different, my main responsibility is to keep GeoServer going forward
<aaime> anything that's not 100% in that topic basically does not exist
. simboss_ is now known as simboss
<aaime> also, I'm not maintainer of anything besides postgis versioning
<aaime> but in fact I keep up other modules whose main maintainer is missing or is someone else
<desruisseaux> Then, if nobody object, I will try to setup more accurate "fix versions" for metadata and referencing. It may implies many "unknown" fix versions. I would suggest to keep them as is if nobody object...
<groldan> right, you do, and its worring there are such a number of almost-orphaned modules
<aaime> I surely won't complain
<aaime> each maintainer is free to manage the issues of his modules as he sees fits imho
<desruisseaux> Thanks. I'm done then...
<groldan> and what about the main ones
<groldan> which have various maintainers
<aaime> groldan, same
<groldan> same thing?
<groldan> I see
<aaime> too many maintainers, no maitaner
<groldan> so in the end it would be just a mean of being more picky, just like what you were asking about issue reporting aaime
<groldan> ie, just do care
<aaime> Eh, yeah, the thing is that the number of issues vs the number of developers is simply overwhelming
<aaime> while the devs are already filled solid of other work
<aaime> so basically stuff that's moving is stuff that some way or the other has some commercial sponsoring behind it
<aaime> like it or not...
<groldan> right
<aaime> desruisseaux, stupid question
<desruisseaux> Andrea, yes?
<aaime> do you think it would be possible to make streaming renderer participate in the go-1 architecture?
<desruisseaux> I can ask to Johan
<aaime> you have pluggable renderers, right?
<desruisseaux> Yes
<desruisseaux> There is a "Renderer" interface for that.
<desruisseaux> Johan has separated "Canvas" and "Renderer" exactly for the purpose of plugin different rendereR.
<aaime> and "renderer" is something that can draw anything, like decoration, north arrow, map scale?
<desruisseaux> Renderer is basically a collection of implementation-dependant Graphic (this is the GO-1 design), and a Graphic can draw anything like a decoration, north arrow, map scale.
<desruisseaux> Canvas take care of referencing stuff (which is renderer-independant, so can be leverage accross different renderer).
<aaime> so it may be sitting in geographic space, or in "paper" space
<desruisseaux> One or the other.
<aaime> Ok, interesting
<aaime> thanks for answering
<desruisseaux> The renderer give the opportunity to draw in "objective" or "display" space (again the "objective" and "display" are GO-1 terminology)
<desruisseaux> As Graphic choice.
<desruisseaux> (typo: At Graphic choice)
<acuster> we done?
. acuster decides we are and goes to post the logs
<desruisseaux> Yes on my side.
<aaime> done