Skip to end of metadata
Go to start of metadata

Agenda Items:

  1. what is up
  2. svn is down film at 11
  3. svn access post osgeo
  4. styles upgrade
  5. GeoAPI release with JSR-275
  6. 2.5 branch

Action Items:

  • pmc: discuss options for moving svn to OSGeo or Codehaus hardware
  • jgarnett: Create [Switch from JSR 108 to JSR-275 for Units] proposal
  • eclesia: Create a migration plan for styling

jgarnett: let us start the meeting
jgarnett: agenda topics?
acuster: svn is down, film at 11.
sfarber: ok, let me think a bit. The circularity of it is making the code hard to read, and I think hard to implement/use correctly. Let's talk more later. Yes, the performance gain is important, heck it's neccesary...but I think there's a cleaner conceptual way to make it click together.
jgarnett has changed the topic to: 0) what is up 1) svn is down 2) svn access
jgarnett: I like the way acuster said it
Ed [] entered the room.
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo
Eclesia: styles upgrade
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade
desruisseaux [] entered the room.
jgarnett: I assume the #geoserver crowd is not around today? they were trying to do some planning last week ... let's keep that topic.
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade 4) 2.5 branch
desruisseaux has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade 4) GeoAPI release with JSR-275
jgarnett has changed the topic to: 0) what is up 1) svn is down film at 11 2) svn access post osgeo 3) styles upgrade 4) GeoAPI release with JSR-275 5) 2.5 branch
jgarnett: acuster did we need to chat about the remaining osgeo issues?
jgarnett: or is email fine for that ...
acuster: I have nothing to add; work needs to be done.
jgarnett: okay ...
jgarnett: stupid question; is there a wiki page with the list of work on it? or can I update the proposal page based on your last email?
acuster: I have not written a wiki page
acuster: only the email, which is kind of self explanatory
acuster: ie. maintainers need to deal with their review. txt
jgarnett: okay I will try and update the tasks on our wiki page; even just to make sense of your email.
jgarnett: and we need a back up plan; ie kick things out of the build/release...
jgarnett: shall we start the meeting?
jgarnett: 0) what is up
acuster: !svn
jgarnett: jgarnett - reviewing styling work; relaxing after a busy week; trying to sort out communication
gdavis_: gdavis: working on and off on the wps module, getting the "execute" request working
***Eclesia working on styles GeoAPI/GeoTools and go module, raster function tests and vector tests
desruisseaux: Martin: testing and bug fixes in ImageMosaicReader. Starting the upgrate to JSR-275.
jgarnett: nifty ...
jgarnett: 1) svn is down film at 11
jgarnett: what is to say here?
jgarnett: do we think rsync caught it out?
jgarnett: or what ...
desruisseaux: I can try to stop rsync again and see if thing come back to normal.
desruisseaux: But we have verified that it is really run only once a day.
desruisseaux: And the next execution is scheduled in about 8 hours...
desruisseaux: Do I stop rsync?
acuster: what do the admins have to say?
vheurteaux: hello all Jody you can look if this IP address is flooding
vheurteaux: or this one
jgarnett: I am not the person looking at this; can you email the question to
vheurteaux: ok I'll do that
jgarnett: we lease this server from a company in Vancouver; and we are on the phone with them sorting stuff out... I will send email when we have something useful.
jgarnett: near as I can tell everything is down;
jgarnett: and the long term solution is to upgrade things like svn right?
desruisseaux: One solution could be to move to OSGEO svn...
jgarnett: On a related note Thuens has been trying to set up a mirror of svn and a mirror of our repo in south africa (where the network delay and bandwidth costs are crazy)
jgarnett: so yeah; we can look at moving to OSGEO svn...
jgarnett: personally I would prefer to move to codehaus
jgarnett: for the simple reason that nobody in the community has to maintain it.
vheurteaux: svn 1.4 would be great
vheurteaux: it include's svnsync
jgarnett: (OSGeo == GeoTools as far as keeping the server alive goes right?)
jgarnett: you guys could also set up svn 1.4 and move things over to europe...
desruisseaux: I though that OSGEO has its own SVN. Don't they maintain it?
jgarnett: but we have all the codehaus premissions etc we need ... and it would give us single sign on for wiki + svn + jira ... that may be worthwhile?
jalmeida left the room (quit: "Miranda IM! Smaller, Faster, Easier.").
jgarnett: OSGeo has servers available
acuster: berk
jgarnett: but we are OSGeo; ie it is not a big thing like Codehaus
jgarnett: only volunteers on projects like ours.
jgarnett: (so OSGeo option; as far as I understand it = they provide a server and we set up svn ...)
jgarnett: Let me ask on the osgeo channel
jalmeida [n=Miranda@] entered the room.
jgarnett: I will wait for a reply ...
jgarnett: So this svn situtation cannot go on; while this is not as bad as the SF days it is not good.
acuster: hg
jgarnett: I am going out of the loop for weeks and cannot take this on; does anyone have facilities / time / interest?
acuster: for what?
jgarnett: (or in acusters case alternatives)
acuster: to host the svn?
jgarnett: for making a migration plan; either to codehaus or to osgeo hardware.
desruisseaux: Vincent?
jgarnett: or to elsewhere...
vheurteaux: yes
vheurteaux: desruisseaux: shoot
desruisseaux: SVN on pulsar?
jgarnett: ... I can also ask if Refractions can upgrade svn to 1.4; but do we honestly expect that to help?
vheurteaux: no problem
acuster: refractions can't move
acuster: for some internal project
acuster: we should move to
jgarnett: refractions can spend money and move ... or lease another server.
jgarnett: I can ask.
jgarnett: I am intersted - why the interest in Is it for the domain name? (that is a good reason).
desruisseaux: I'm hesitant between OSGEO and Codehaust. I can see the advantage in Codehaust. I was interrested in OSGEO only for the "symbol"
acuster: yeah, and maybe it's got a more recent svn
acuster: in which case we could mirror transparently
vheurteaux: yep sounds great
jgarnett: codehaus seems the better option for me; they are good about keeping their hardware going and svn etc... is up to date.
jgarnett: geoserver has had good luck with them.
acuster: let's move on; we won't resolve this tonight
desruisseaux: I'm not objecting against Codehaus
jgarnett: okay; but the question I had is
jgarnett: can we look into this? and the answer seems to be - yes.
jgarnett: and I expect we can swap notes on email?
desruisseaux: Fine.
jgarnett: 3) styles upgrade
jgarnett: Eclesia the floor is yours?
jgarnett: My first question is can you respond to the subject from last weeks meeting. We were trying to do planning and did not know your project timeline.
jgarnett: opps I missed agenda topic 2) I will come back ...
Eclesia: 2 or 3 ?
CIA-33: acuster * r30739 /trunk/modules/unsupported/jts-wrapper/src/ (20 files in 9 dirs): Copyright headers: unsup/jts-wrapper, change and add headers, add review.txt
CIA-33: acuster * r30740 /trunk/modules/unsupported/geomedia/ (3 files in 3 dirs): Copyright headers: unsup/geomedia, change and add headers, tweak review.txt
CIA-33: acuster * r30741 /trunk/modules/unsupported/jts-wrapper/review.txt: Copyright headers: unsup/jts-wrapper, this time with the review.txt
jgarnett: let me do 2
jgarnett: we can do that quickly
jgarnett: 2) svn access post osgeo
jgarnett: We have a list
jgarnett: should I shut off access based on this list?
jgarnett: so far a few people have asked for more time
jgarnett: and Jan Jezek missed signing the papers he sent.
acuster: Bryce should not be cutoff
acuster: since we can use his work wether he signs or not
acuster: it being in the public domain and all
jgarnett: okay; I will make a note of that ...
jgarnett: If you are under the impression you have sent in your paperwork; can you please check the above link.
jgarnett: I am not sure I saw one for Eclesia for example ...
jgarnett: sounds like I should send out a second round of nag letters...
jgarnett: 3) styles upgrade...
jgarnett: Eclesia the floor is yours
Eclesia: thx
Eclesia: so I believe I have a 1month timelimit
Eclesia: I can start working very soon if needed
Eclesia: everyone depends on geoserver and others deadlines
jgarnett: geoserver has branched away; my question is if you think we need to make a branch of GeoTools 2.5 before you commit? Or basically what should be done ...
jgarnett: I think the idea last week was to either a) branch just before you switch the interfaces over ... or b) ask you to wait until geotools 2.5 is ready for release.
desruisseaux: So the question is related to: what is the schedule for GeoTools 2.5 release.
jgarnett: yes.
jgarnett: GeoTools 2.5 was supposed to target one major change; the feature model switch - and it has accomplished that goal.
desruisseaux: Can we do 5 first and come back to 3 after?
acuster: and meanwhile martin is talking us over to JScience units this week
acuster: so why can't we release 2.5 today?
jgarnett: I think this is okay? I would like to know what Eclesia's timeline is; so we can have a good discussion about 2.5
acuster: what is blocking?
jgarnett: thinking ...
desruisseaux: Hela!! Referencing is not ready for a release!!
jgarnett: what is not blocking?
acuster: okay, we have one blocker: referencing
***Eclesia waits for vheurteaux advice, I'm not the boss
jgarnett: uDig is on trunk for the first time in years and the datastore events are mostly missing
acuster: what else?
jgarnett: it is okay Eclesia; you have your timeline
jgarnett: it is up to us to figure out how we can arrange the geotools 2.5 release so you can work.
acuster: jody: can you draw up a list of blockers and then we can get a list of manpower
jgarnett: so tell us know what you know...
acuster: and see what that looks like?
jgarnett: acuster++ that is a good idea. I don't think there is much; but there is a lot of stuff that we were supposed to do (martin has referencing code reviews from last year for example) that we may need to let slide a while ...
***acuster doesn't understand this mythical month
acuster: we can't schedule a release for which we have no idea what work is to be done
jgarnett: acuster? a month is what eclesia said; so that is what we got ...
Eclesia: As you have seen I have barely duplicate the style implementation in the go module (I needed them) But going further is .. stupid. upgrading geotools styles classes woulmd be really nicer
jgarnett: well we can; we just need to cut scope to make the release ...
jgarnett: sugestion
jgarnett: Eclesia can you udpate the style methods now?
acuster: I thought the GS crowd wanted a month of leeway?
jgarnett: and then after we branch make the classes implement the correct interface?
jgarnett: GS crowd made their geoserver 1.7 branch last week
Eclesia: it's not so easy, some returns types have changes, and it will break backward compatibility
jgarnett: I am doing my best to let them work on geotools trunk for both their 1.7.x branch and their 2.0.x branch ...
jgarnett: but that is incompatible with API change; basically some QA time is needed right?
jgarnett: Eclesia++
jgarnett: can we go through and study the return types? We do have Java 5 type narrowing that may help us ...
Eclesia: returns types changed from arrays to collections, that's the problem
desruisseaux: Java 5-style for loop could help...
jgarnett: ie when LineSymbolizer.getMark() can return the geotools interface Mark; when we change geotools Mark to implement opengis Mark the method will be correct...
Eclesia: no, geotools have 2 arrays where geoapi have one collection for this
Eclesia: and a superclass for mark and ExternalGraphic
jgarnett: Eclesia good call about the arrays; I think we will find that most code uses a couple of methods like addFeatureTypeStyle to avoid the pain of using arrays...
jgarnett: so even regardless of branching; we need a migration plan ...
jgarnett: and it would be much smarter to know that plan now; so we can deprecate the methods that are going to be harmed now for geotools 2.5
jgarnett: does that make sense?
Eclesia: yes
jgarnett: Martin how did you handle the transition from arrays to lists for metadata?
jgarnett: (aside: svn is back!)
desruisseaux: If I remember right, most methods was already collections. Only a few was array, and we though that their number was suffisiently low for suffering an API break.
Eclesia: there are 0 collections currently in geotools style classes
jgarnett: agreed
jgarnett: as an example FeatureTypeStyle.getRules()
jgarnett: most code uses fts.addRule( rule )
jgarnett: we could update our code now to use for loops when processing getRules
CIA-33: desruisseaux * r30742 /trunk/modules/ (9 files in 3 dirs): Coverage I/O MosaicImageReader: bug fix in the detection of overlapping tiles. Utilities package: added an additional exit code.
jgarnett: for( Rule rule : fts.getRules )

Unknown macro: { ... }

jgarnett: and thus be ready for the change from array to list
jgarnett: or we could make a new method
jgarnett: getRuleList(): List<Rule>
jgarnett: and thus avoid the conflict...
desruisseaux: Yes, this is the "Java 5-style for loop" I was suggesting a little bit sooner.
Eclesia: renaming is not the solution.
desruisseaux: Well, I would prefer "getRules()"
jgarnett: yes; you are correct martin - I am catching up ...
jgarnett: can we have fts.getRuleArray() now? ie run two methods ... that way code that expects array has something to migrate too during the transition.
jgarnett: (I also have to confess; we totally screwed up the transition for Filter; which is one of the reasons everyone is scared this time out ...)
desruisseaux: getRuleArray() in the current (to be deprecated) interfaces? Could be...
jgarnett: ie three years later we are still using the old interfaces internally; and since the project that paid for the transition is done ... everything else is on volunteer time
jgarnett: so far I like the getRuleArray() approach ...
jgarnett: I will put one other idea out here...
jgarnett: use java collections style naming....
jgarnett: fts.getRules(): Rule[]
jgarnett: fts.rules(): List<Rule>
Eclesia: ?
jgarnett: the java collections naming is a bit more fasionable; the result forms a "domain specific lanague" ...
desruisseaux: Yes, rules() make sense too (especially if we decide that collections are "live" like Map.entrySet(), List.sublist(...), etc.)
jgarnett: - (for the example)
jgarnett: so we have 2 good options
gdavis_ left the room.
jgarnett: I would like an answer to this before we let 2.5.x go out the door; since it has some consequence for what we do to the geotools interfaces prior to release.
jgarnett: we have 5 mins left... moving on?
jgarnett: 4) geoapi release with JSR-275
jgarnett: woot!
jgarnett: so when does geotools trunk get to change?
desruisseaux: JSR-275 has been uploaded to today.
desruisseaux: So I'm adding the dependency to GeoAPI and I'm begining the replacements.
desruisseaux: I expect to be done before the end of this week.
desruisseaux: It seems to me that this change should be part of GeoTools 2.5 release, if it is workable for GeoServer and uDig guys.
jgarnett: I think so too
jgarnett: this should be part of our transition to Java 5;
desruisseaux: Yes.
jgarnett: so how do we do this martin? we asked a couple weeks ago - did we make a proposal page yet?
desruisseaux: Oups! I have not wrote a proposal page (well, we only have the JIRA task).
desruisseaux: Will look on the wiki tomorrow.
jgarnett: okay so if you can do that; and ask for a vote via email.
desruisseaux: okay.
jgarnett: sweet. I am really looking forward to retiring jsr-108.jar
jgarnett: 5) 2.5. branch
***Eclesia go home +++
Eclesia left the room.
jgarnett: I think we had a couple good discussion already (thanks for putting up with us Eclesia). The branch will need to happen soon; I would like to see the migration plan for styles and jsr-275 make the cut.
jgarnett: I think some of the other work; like referencing may not make it in time?
jgarnett: what are your thoughts?
acuster: martin would really not like a release of the current referencing stuff
acuster: a release without his review makes him nervous
desruisseaux: I will see if I can spend a few time on referencing after the jsr-275 work...
jgarnett: understood
jgarnett: jgarnett would like to complete the user guide section on styling; but would kind of like to wait for Eclesia's work (so I am stuck)
jgarnett: I would also like to see osgeo sorted out; so this can be the first offical osgeo release.
jgarnett: is that too crazy?
jgarnett: acuster this page had our list:
jgarnett: for udig the only remaining stuff is me to do some QA on the classification functions.
jgarnett: any other comments? If not I can close the meeting ...
acuster: do you know the GS time frame for this?
jgarnett: it was all in last weeks meeting was it not?
jgarnett: they made their first release candidate
jgarnett: when they are ready to release they will make a release of geotools 2.5.0
desruisseaux: When do they plan to make this release?
acuster: everyone has a mythical month floating around
jgarnett: they are worried that 2.5.0 is not ready; but they needed to start their ship sailing (before their code sprint)
acuster: and no firm dates
jgarnett: okay the first firm date already passed
jgarnett: it was last week.
jgarnett: geoserver branched.
jgarnett: nobody felt comfortable making another firm date until we did some cross company / project plannning.
desruisseaux: So, if a JSR-275 upgrate is performed this week, can they update?
jgarnett: between the two meetings we now know a fair bit.
jgarnett: desruisseaux; I think they can.
desruisseaux: Thanks.
jgarnett: geoserver 1.7.0 has not made it out the door yet; we are making their life hard by changing this now ...
acuster: changing what?
acuster: units?
jgarnett: I know you first talked about it some weeks ago; I should of reminded everyone about the release train leaving the station.
jgarnett: changing units.
jgarnett: so in terms of geotools 2.5.x scope
jgarnett: - we met our goals
desruisseaux: I'm 1-2 week late compared to what I said.
jgarnett: - we have some QA to do (on all sides)
jgarnett: - style interfaces shoudl be reviewed as part of a migration plan
jgarnett: - jsr-275 should go ahead
jgarnett: - categorization functions need test cases
jgarnett: that is all the stuff I know about?
desruisseaux: opportunist target (i.e. if we can): referencing
jgarnett: would it help if we set a deadline for ourselves?
desruisseaux: we could try, but I'm probably the worst guy in the whole geotools community about respecting deadline.
jgarnett: we understand; we know you
acuster: the only deadline I care about is graduating
jgarnett: I think the person I am most worried about here is Eclesia; I don't want him stressed out again ...
jgarnett: acuster++
jgarnett: so martin we may just miss out on doing some of the work we wanted for 2.5.x right?
jgarnett: JSR-275 and styling represents the only pending API change; and only the JSR-275 one has any chance of impacting geoserver.
jgarnett: (ie they need to include a different jar...)
jgarnett: So martin how can we help you meet this deadline ...
desruisseaux: Some of the work wanted for 2.5 (referencing) may be missing, yes. Actually it is not a huge issue for me if we can warm peoples that some class will changes. My issue is that I would like to avoid a heavy "deprecated, then delete" cycle (we have some pre-threaded factory classes around).
jgarnett: From the perspective of people using that CRS utility class nothing will be different ...
desruisseaux: Right.
jgarnett: So I suggest we "relax" about that one?
desruisseaux: If peoples agree, we can do thaT.
desruisseaux: In such case I would at least put big warning in the javadoc...
jgarnett: you are the module maintainer; I am happy to agree - but I want to make sure you are happy.
jgarnett: that is within your power; I also suggest putting a warning in the user guide
desruisseaux: My only issue is to avoid to heavy "deprecate, then delete" cycle.
jgarnett: still if we don't have time, we don't have time, and the users suffer ... sad but true.
jgarnett: So this is your call; can you make this work before eclesia is done his style migration plan?
jgarnett: you could always make him drink beer at work and slow him down ...
jgarnett: (that is a joke)
desruisseaux: No problem . I will try to at least start a little bit of work after jsr-275 and will let people known.
jgarnett: I found a GeoAPI Jira task for switching to JSR-275; but nothing for geotools...
desruisseaux: There is one for GeoTools too.
jgarnett: maybe you can hide the classes you are worried about; make them only package visible or protected visible ...
jgarnett: I did not see it in email; I am making you a proposal page now ... if that is okay?
desruisseaux: Sure, thanks a lot
jgarnett: oh they are linked; silly me ...
desruisseaux: In the GeoAPI JIRA task, you have the link to the GeoTools task.
jgarnett: okay thanks for the meeting guys; I know planning is tough.
jgarnett: I will post the logs.
desruisseaux: Thanks a lot for driving the IRC
desruisseaux: Bye all

  • No labels