Attendees
| IRC nick
|
Real name
|
| Firefishy |
Grant Slater
|
| gravitystorm |
Andy Allan
|
| pnorman |
Paul Norman
|
| TomH |
Tom Hughes
|
| zere |
Matt Amos
|
Summary
- Ruby versions:
- Currently we support 1.8 and 1.9, but Rails 4 will be 1.9-only, and Rails 5 will be 2.0 only. Will consider deprecation of 1.8 support as 1.9 gets more widespread.
- Shallow clones:
- The full repo requires transferring 150MB of data but a shallow clone only requires transferring 23MB.
- Shallow clone breaks "principle of least surprise", but useful for those on hack days or other bandwidth-poor environments.
- Post-hackday retention
- Survey/questionnaire: [1]
- Deprecation of /changes
- pnorman to message dev@ about /changes (undocumented) API call going away soon.
- Carto/hstore
- Discussion about whether to have some or all tags in hstore so that adding new tag references from the style doesn't require a re-load.
- Looks like there's a hardware blocker (controller/SSD not playing well)
- Other than that we are looking at being ready to trial the carto stuff soon
- If someone comes forward with an hstore PR, then that might make it, otherwise probably not for a while.
IRC Log
17:01:18 <zere> minutes of the last meeting: http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-06-17
17:01:27 <zere> please let me know if there's anything which needs correcting
17:01:44 <zere> #topic Actions of previous meetings
17:02:22 <zere> i've got to apologise again for the OWL stuff, i haven't been able to find the time. is anyone else willing to pick this up?
17:05:54 <zere> i'm guessing that's a "no". since neither gravitystorm nor apmon are here to update, i guess that finishes off that section.
17:06:29 <zere> there was nothing else queued up for the agenda today, so we'll go straight to: does anyone have anything they'd like to discuss?
17:10:05 <zere> gravitystorm: welcome. any update on the rails port docs stuff?
17:11:11 <gravitystorm> hmm. http://www.osmfoundation.org/wiki/Engineering_Working_Group needs updating. I thought I still had 50 minutes until the meeting...
17:12:00 <gravitystorm> my update is that I've started testing the installation docs, and fixing them up as I go along
17:12:01 <zere> yeah, sorry. contradicts http://www.osmfoundation.org/wiki/Working_Group_Minutes#Engineering_Working_Group
17:12:10 <zere> fixed now. thanks for pointing it out
17:12:34 <gravitystorm> zere: no worries, I could easily just remember the time instead of looking it up every week
17:13:24 <zere> sure, but it is vastly more helpful now that the times agree and are correct - in case you need to look it up again ;-)
17:14:00 <gravitystorm> Oh, I remember. There's some new tests that aren't ruby1.8 compatible, that's where I got to. I plan to submit patches to the rails port to bring it back to 1.8 compatibility, since I don't think it was a deliberate change.
17:14:32 <gravitystorm> If we ever move to ruby1.9 only, then we'll need to rework the install notes.
17:15:07 <TomH> guaranteeing to maintain 1.8 support is hard because I don't routinely test on it
17:15:20 <zere> yeah, i don't think it was intentional. but interesting that it seems almost everyone is on 1.9 now.
17:15:30 <gravitystorm> Also, I have a question for the group, what do we think about https://github.com/gravitystorm/openstreetmap-website/pull/1
17:15:47 <pnorman> /me waves
17:15:51 <zere> perhaps we need to think about deprecating 1.8 - and maintain compatibility for 6 months or so?
17:17:41 <gravitystorm> zere: well, if someone fires up their laptop (ubuntu, macosx, whatever) and has ruby1.8 installed, I'd rather it not be a world of hurt. As soon as we need it (e.g. having a 1.9-only gem) then fair enough, but until then I say we stumble on with no need to deprecate it.
17:17:48 <pnorman> I'm not opposed to a higher depth in the readmes, but someone following install instructions doesn't really need every bit of history to the beginning of time, and it's easy enough to git fetch it if they do
17:18:09 * Firefishy needs to pop out in 5mins.
17:18:18 <TomH> in fact in a few weeks my dev box will be on 2.0
17:19:00 <zere> gravitystorm: i'm not sure i fully understand the implications of the shallow clone, but i don't think that it would be a problem as long as it's well footnoted ("why am i missing all the history? how can i get the full clone?", etc..)
17:19:10 <gravitystorm> pnorman: so my thinking is least-surprise - it's unusual to find in install notes, and also breaks things like git log which is also unusual
17:19:20 <pnorman> hmm, git log is a good point
17:19:40 <zere> how does it break it?
17:20:36 * gravitystorm kicks RichardF for putting videos in git in the first place
17:21:00 <zere> videos? *boggle*
17:21:43 <gravitystorm> zere: because you don't get the history of what's going on. git blame is similarly affected. You only clone the last 2 commits (as written) in order to not download all the other blobs
17:22:23 <gravitystorm> is there a one-liner to fill in the history?
17:22:39 <pnorman> yes
17:22:42 <zere> git fetch --depth=1000000 apparently
17:24:01 <zere> hmmm... so the breakage isn't total - it's just confusing. i think if people are aware that it's a limitation, then shallow clone is ok
17:24:10 <pnorman> the sprint days made me think about bandwidth a bit more, and the full clone is 150MB and shallow is 23MB
17:24:49 <zere> just needs warning saying "btw, this is a shallow clone and you'll want to run this command to get the full history if you want log / blame / etc... to work properly."
17:25:38 <zere> but for development... it's probably ok. i don't use log/blame particularly often.
17:25:45 <gravitystorm> I'd rather flip it, since in most circumstances you don't care about waiting the extra few seconds for 150MB
17:26:20 <gravitystorm> anyway, we're probably bikeshedding by now
17:26:22 <pnorman> I could redo it to indicate you want --depth=1 on slow connections when you don't want history. Perhaps github was just being rather slow the day I did it :)
17:26:34 <zere> fsvo of "few"... with your 200Mbit/s connection?
17:27:19 <pnorman> fwiw, github was about 1MB/s, so it adds about 2 minutes to the clone
17:28:32 <zere> i think we're pretty much agreed that it's worth mentioning and i'm happy for gravitystorm to include it in whatever way he feels is most appropriate.
17:28:52 * pnorman is allowed to bikeshed his own pull requests :)
17:29:25 <zere> was there anything else anyone wanted to bring up for discussion?
17:29:28 <pnorman> yes
17:29:56 <pnorman> taking us away from more -dev matters to -ewg, did we have any progress on the questionaaire for sprint day registrants?
17:30:42 <pnorman> or did I miss that at the start? looks like I might of
17:30:43 <zere> apmon isn't here, but it looks from the hackpad doc like there wasn't. unless apmon worked on it elsewhere.
17:31:23 <zere> link to hackpad: https://hackpad.com/OpenStreetMap-sprint-followup-questionaire-JzH1Bmv0ncJ
17:32:14 <pnorman> deprecation of API calls? I don't mind if we do/don't discuss it, but I see it in last week's minutes. more of a -dev then a -ewg matter though
17:34:18 <zere> sure. what do you think is appropriate. announce on dev@, document on the wiki, and leave... 3 months notice?
17:35:09 <zere> i'm remembering last time something like this changed, there was much outcry that more notice hadn't been given. but that needs to be balanced against the desire to get it done in a reasonable amount of time.
17:35:47 <pnorman> well some of the API calls aren't documented in the wiki right now (like the crazy ones no one talks about)
17:36:28 <Firefishy> zere: for the agenda: when can I start pushing traffic to orm? limited regions
17:37:09 <zere> pnorman: you're right - this one isn't even documented.
17:37:27 <zere> anyone volunteering to write a message to dev@ saying this is going away?
17:38:38 <pnorman> I'd say if logs show *no* use and it's not documented in the wiki we can safely pull the calls. for the changes API call, I'd say dev@ would be good since someone uses it
17:39:11 <zere> there's some very light use - i think we found a single user who seems to be hitting it hourly on a cron or something like that.
17:39:13 <pnorman> I can do the message
17:39:34 <zere> pnorman: thanks!
17:39:53 <zere> #action pnorman to message dev@ about /changes (undocumented) API call going away soon.
17:40:06 <zere> #topic traffic to orm
17:40:08 <pnorman> gravitystorm: we should probably talk post-meeting about carto
17:40:21 <zere> i think that's what Firefishy wants to talk about too
17:40:26 <gravitystorm> eek
17:40:32 <zere> Firefishy: ^^ going live?
17:41:20 <Firefishy> When we are "ready" by some measure of ready, I'd like to start sending some real traffic to orm. eg: Australia.
17:41:38 <Firefishy> I can then see how the hardware + stack is performing.
17:42:04 <zere> what's still between us and "ready"?
17:42:05 <TomH> I want to wait for the hardware t be fully operational
17:42:23 <TomH> I have a few other tweaks but the hardware is the main blocker currently
17:42:36 <TomH> well that and a decision on whether to reimport with hstore?
17:42:55 <zere> what are we waiting on? Firefishy installed disks + ram - are we doing some other upgrade?
17:43:22 <TomH> fixing the second ssd
17:43:33 <Firefishy> SSD&Tile Disks + RAM installed. But 2nd SSD is playing up, but unknown why.
17:43:43 <zere> ah, ok.
17:43:48 <pnorman> gravitystorm: do you think we'll be rendering new tags via hstore in the near/mid-term future to osm-carto?
17:44:10 <Firefishy> I need to visit IC. I am considering getting an add-on PCI-E SATA controller.
17:44:34 <zere> you think the playing-up is controller-related?
17:44:49 <gravitystorm> pnorman: it's not on my time-horizon
17:44:58 <gravitystorm> so unlikely in next 3 months
17:45:10 <gravitystorm> and probably not in next 6
17:45:45 <zere> gravitystorm: when you said "eek", does that mean you think the carto stuff is a ways away from being "production"?
17:46:32 <gravitystorm> zere: not at all, just the reaction when I find out that everyone wants to talk about something I've been neglecting for a few weeks
17:47:32 <TomH> ah yes, guess we could do with a new tag with the updates from the sprint?
17:47:58 <gravitystorm> TomH: we could do with me reviewing the pull requests from the sprint first
17:48:44 <pnorman> The only PR open from the sprint is mine which switches to openstreetmapdata.com
17:49:06 <zere> ok. to summarise: looks like there's a hardware blocker, but other than that we are looking at being ready to trial the carto stuff soon. if someone comes forward with an hstore PR, then that might make it, otherwise probably not for a while.
17:49:11 <zere> is that about right?
17:49:14 <gravitystorm> also https://github.com/gravitystorm/openstreetmap-carto/issues/52 needs sorting before I do the next release - poor branch management by me
17:49:37 <gravitystorm> zere: hstore is a sysadmin/chef thing, not openstreetmap-carto
17:49:58 <zere> doesn't it need changes to the queries?
17:50:10 <pnorman> except that if put in sql that depends on hstore, they'll need it imported
17:50:10 <zere> (and documentation, of course!)
17:50:25 <gravitystorm> zere: in that I won't be adding stuff that relies on hstore before I know that it's available on osmf.org servers
17:50:50 <zere> i have a feeling it won't be available on osmf.org servers until it's needed ;-)
17:51:08 <gravitystorm> fair enough :-)
17:51:32 <gravitystorm> it's not a blocker now, and I don't see it coming up for discussion in the next few months. When it does... let's discuss then.
17:52:02 <TomH> zere: there are two modes, "everything in hstore" and "everything that isn't otherwise imported as a column in hstore"
17:52:10 <zere> gravitystorm: i was just trying to whip up some enthusiasm for someone to submit a PR with it.
17:52:24 <pnorman> how about this: no hstore for now, but look at simplifying the default.style and adding hstore in the mid-term
17:52:49 <zere> sure. i don't think anyone is against hstore - it's just the work needed to do it.
17:53:24 <zere> TomH: sure, but if you're going to pull out the columns which are interesting as real columns, then you've negated 99% of the point of hstore, haven't you?
17:54:04 <pnorman> zere: the thought was have natural, highway, etc as real column then stuff like generator:source in hstore
17:54:23 <pnorman> or that was one thought. there's been a few floating around
17:54:55 <zere> hmmm... my cartographic sense is tingling at the thought of needing generator:source in the renderer...
17:55:08 <pnorman> we use it right now
17:57:28 <zere> ah, (power='generator' and (\"generator:source\"='wind' or power_source='wind'))
18:01:04 <zere> thanks to everyone for coming - i hope to see you next week!