- rails_port install instructions
- Pushing PostgreSQL version to 9.1+ would probably simplify install instructions, and seems to be in most distros / packaging systems.
- /changes deprecation
- No complaints on dev@
- Review at next meeting
17:05:17 <zere> minutes of the last meeting: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-06-24
17:05:30 <zere> let me know if there's something which needs changing in there.
17:06:14 <zere> anyone have any status updates on the post-hackday questionnaire, rails docs, carto stuff?
17:07:27 <gravitystorm> I submitted a pull request for the rails docs, and TomH gave feedback on a couple of minor points
17:08:13 <gravitystorm> It would be great to get more feedback / requests on https://github.com/openstreetmap/openstreetmap-website/pull/317
17:09:49 <gravitystorm> https://github.com/openstreetmap/openstreetmap-website/pull/317#discussion_r4862713 is the biggest thing among the minor points. Does anyone (RichardF or shaunmcdonald) have a feeling for how much INSTALL.md will be different on MacOSX?
17:10:29 <gravitystorm> https://github.com/gravitystorm/openstreetmap-website/blob/docs/INSTALL.md if anyone wants to skim read
17:10:56 <pnorman> I have a status update on changes API, which originated out of andy's rails doc stuff
17:16:03 <pnorman> do we still work with ruby 1.8.7?
17:16:40 <gravitystorm> pnorman: there's 4 unit tests that currently require 1.9, but that's all. I was planning on changing that, unless TomH beats me by upgrading to rails 4
17:18:25 <TomH> rails 4 will be a while - there's nothing massively wrong (the front page loads for example) but we will need rails 4 compatible versions of the oauth and composite_primary_keys gems to go much further with it
17:23:31 <shaunmcdonald> Is it worth upping the Postgres requirements for simplicity, stating the older legacy ones are still available over there ->
17:24:06 <shaunmcdonald> The install of the packages would be different on OSX
17:24:23 <gravitystorm> shaunmcdonald: I don't understand what you're proposing wrt postgres
17:25:07 <pnorman> postgres 8.3 is now into unsupported
17:25:21 <shaunmcdonald> as in upping the minimum requirements from 8.3 to 9.0+
17:25:25 <TomH> to channel RichardF, "Postgres.app FTW"
17:25:36 <shaunmcdonald> thus simplifying the install there.
17:26:16 <shaunmcdonald> TomH: which gives you 9.2.4, though I have to be different and use homebrew ;-)
17:27:26 <shaunmcdonald> It's need to be postgres 9.1+ to be able to simplify the instructions.
17:28:23 <gravitystorm> shaunmcdonald: technically I can just strip out the pre 9.1 stuff, because there's no supported version of Ubuntu that ships with anything less (ignoring 10.04 LTS). When I started writing them, 11.10 was still supported.
17:30:11 <pnorman> i'm all for 9.1+, I can't see someone starting dev work on 8.4
17:31:10 <gravitystorm> pnorman: remember, it's all about what's packaged on the distros that we're targetting. If there's a current Fedora that ships with 9.0, then we'll write the install notes based on that.
17:31:27 <gravitystorm> Same goes for MacOS, but I suspect it doesn't ship with postgres in any case.
17:33:07 <zere> i suspect the current fedora ships with something more recent
17:33:24 <TomH> 9.2.4 in both F18 and F19
17:33:43 <zere> although "current" centos ships with 8.x, i'm pretty sure. although calling any version of centos "current" is a bit much
17:33:57 <pnorman> the advantages of having tom lane on fedora :)
17:34:03 <TomH> 9.1.9 in F17
17:34:13 <TomH> 9.1.7 in F16
17:34:45 <gravitystorm> Given centos is a RHEL-wannabe, I'm staying well clear of that. I might not even be on ruby1.8 yet :-)
17:35:45 <zere> ok. so it seems like we can assume 9.x really.
17:36:34 <TomH> so you have to go back two years to find a release with 9.0 or earlier
17:36:55 <zere> pnorman: what were you saying about /changes?
17:37:25 * pnorman is basically assuming 9.1 for cgimap pgsnapshot, not that I think I'm depending on it yet
17:37:44 <pnorman> no one replyed to the dev@ message saying they used it or had a use or object to removal or anything
17:38:19 <zere> http://lists.openstreetmap.org/pipermail/dev/2013-June/027136.html
17:39:08 <zere> i guess the next question is - how long is a reasonable amount of time to leave that up before we can make the change removing it?
17:40:51 <zere> a couple of weeks? a month?
17:41:55 <zere> hmm... well, i guess we can come back to it.
17:42:23 <zere> was there anything else anyone wanted to discuss?
17:42:59 <pnorman> back to developing developers, any updates on hack weekend survey?
17:43:35 <zere> i can't see any change to the hackpad - although it's possible apmon isnt' using it.
17:43:50 <zere> how about we think of some questions now...?
17:44:05 <zere> (link to hackpad: https://hackpad.com/OpenStreetMap-sprint-followup-questionaire-JzH1Bmv0ncJ )
17:44:08 <gravitystorm> zere: we could switch it off, wait until John Doe appears, then switch it back on for a few weeks to help him with his migration.
17:45:01 <gravitystorm> Since we've posted a message in our filing cabinet in the disused toilet with no appreciable effect, then it doesn't matter if we leave it a day or a month, it'll still be a nasty surprise.
17:45:14 <zere> i guess it's a one-liner to take it out of routes, maybe we should just try that. although perhaps a little unfair only 6 days after the email went out?
17:45:35 <pnorman> do the pull request at a week, accept the pull request at 2 weeks?
17:46:23 <zere> you're probably right. damned if you do, and damned if you don't. and if it were done when 'tis done, then 'twere well it were done quickly.
17:46:51 <gravitystorm> Look at it more like we're trying to make contact, rather than how long the deprecation period is. If we can't find out how to make contact, then there's no point in having any deprecation period at all.
17:46:53 <zere> people can comment on the PR or on the mailing list.
17:47:39 <zere> yup. ok. i think we're pretty close to agreed - let's take it out. anyone volunteering to wield the knife?
17:48:08 <gravitystorm> Yeah, let's make a pull request, mention it again on dev, then kill it in 7 days. If any of that prompts contact with John Doe, then we can re-establish for a formal deprecation period.
17:48:33 <pnorman> I mean, it's not like we're ignoring feedback, we're just not getting any. If we want to search wider for the user, I can ask sly to contact the french lists since it is the french ovh datacenter, but your guys call
17:49:03 <zere> i have a feeling that this is some logger / cron process which has been forgotten about anyway.
17:49:23 <gravitystorm> zere: I have a feeling it's someone still running t@h :-)
17:50:45 <zere> if that's the case then they might object more strongly. but i think the next step is to make the PR, announce on dev. then as pnorman says, we review it at the next meeting. if there's no objections then we merge it. (fsvo "we").
17:50:58 <TomH> gravitystorm: I half suspect that as well
17:52:16 <TomH> gravitystorm: timbl is complaining about the lack of contours north of 60 degrees in #osm-dev ;-)
17:52:50 <zere> anyone feel like volunteering to rip out /changes, submit the PR and post again on dev@?
17:54:07 * pnorman is grabbing water; zere, should touch base after the meeting
17:59:20 * pnorman returns; anything else for the meeting?
17:59:34 <zere> cool. i guess that's the end of the meeting. next time we'll start by looking at that questionnaire... cheers to everyone for coming!