Attendees
| IRC nick
|
Real name
|
| Firefishy |
Grant Slater
|
| iandees |
Ian Dees
|
| pnorman |
Paul Norman
|
| RichardF |
Richard Fairhurst
|
| zere |
Matt Amos
|
Summary
- JSON OSM format
- Seems like the array-of-type approach has more support.
- Needs some work to include other types of return (e.g: osmChange, diffResult, etc...)
- "two trackers for the same component is stupid"
- We have a lot of "components" in trac which have moved elsewhere.
- Some projects maintain both trackers, but others are obsolete or only use a different tracker (e.g: github).
- General procedure - clean up tickets, close obsolete as "wontfix", move any relevant ones which have a newer tracker to the other tracker.
IRC Log
17:08:17 <zere> http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2013-08-19 is the last full meeting we had
17:08:47 <zere> the last couple of weeks have been holidays in US/UK and there wasn't really anything discussed.
17:09:13 <zere> it seems there's 2 items for the agenda: JSON formats, and "two trackers for the same component is stupid".
17:09:31 <zere> #topic JSON OSM format
17:10:29 <zere> what do we need to discuss here? there was the issue over the array-of-untyped vs. type-array thing
17:10:52 <zere> is that basically resolved, or is there something more to discuss?
17:11:08 <pnorman> jfire has weighed in, and if none of the other implementors care to respond to my request on dev for more eyes, that kind of answers it
17:11:27 <zere> cool.
17:11:42 <Firefishy> Hack day still going on
17:11:57 <Firefishy> h4x0r1ng FTW
17:12:00 <zere> what other bits need to be discussed? perhaps changesets / support for history?
17:12:30 <pnorman> history is in a different format, largely the same
17:13:37 <zere> well, really? it's the same format in XML. i think it's simpler if we call it one format, and just make a note that IDs are unique when history isn't present, otherwise [ID, version] is unique.
17:13:42 <pnorman> or could define one as a subset of others, but if you look at OSM XML there's lots of software that doesn't support history
17:14:26 <zere> yup. and i'd prefer if we "promoted" the history abilities so that people writing libraries or tools were more aware of the issue.
17:15:05 <zere> not that it would guarantee support - and sometimes that's not an issue - but it means we won't get into the debate around ".osm / .osh"
17:15:42 <zere> my view is that "current" files with unique IDs and no deleted versions are special cases of the more general OSM format.
17:16:41 <zere> in the sense of "implementations SHOULD NOT assume IDs are unique" meaning that implementors can treat IDs as unique if they're aware that it will potentially cause breakage on some documents.
17:16:42 <iandees> agreed. the json format spec pnorman is working on could mention that [id,version] is unique and leave it at that
17:17:05 <pnorman> and that id is unique among visible elements
17:17:25 <zere> yup.
17:17:37 <iandees> is there a more general discussion of how OSM history works? thre's the Elements wiki page, but would that be adequate to point to in the spec?
17:19:02 <pnorman> changesets, I'm not sure about. I know the planet includes them
17:19:49 <zere> i think we might need to write some better documentation on the data model and how that maps to the various representations...
17:21:31 <zere> changesets i guess are fairly simple - they're just going to map to an array of elements just like nodes/ways/relations.
17:21:46 <zere> i'll try and put a PR in for that so we can discuss it on github
17:22:25 <zere> is the intention to have a representation defined for all the XML returns?
17:22:42 * pnorman is not yet awake enough to parse that
17:23:08 <pnorman> you mean for the change formats? yes, but as a different format spec
17:23:43 <zere> i.e: osmChange, diffResult, comments/notes?
17:23:54 <pnorman> already a notes json I think
17:24:51 <zere> possibly a documentation bug, then? http://wiki.openstreetmap.org/wiki/API_v0.6#Search_for_notes_on_text_and_comments:_GET_.2Fapi.2F0.6.2Fnotes.2Fsearch
17:25:17 <pnorman> returned in several different forms (e.g. XML, RSS, json or GPX)
17:25:45 <zere> only /api/0.6/notes?bbox=
17:25:56 <pnorman> that was under /api/0.6/notes/search
17:26:35 <zere> ah, ok. then i shouldn't have been paying attention to where it says "Return type (in bold): application/xml"
17:28:05 <pnorman> that's not to say that there isn't some value in documenting the format
17:28:18 <zere> yup.
17:29:29 <zere> hmm /capabilities, /user/details and /user/preferences have their own little microformats too... easy enough to map to JSON, but they're really only implicitly documented ;-)
17:30:11 <pnorman> i don't really think those belong in the JOSM format :)
17:30:20 <pnorman> OSM JSON format
17:31:12 <zere> no, i don't think so either
17:31:41 <zere> despite them being wrapped in <osm></osm> i don't really consider them part of the OSM XML format either.
17:32:46 <zere> but we'll still need to define / document the format so that we can do those calls in JSON too. would be kinda odd to have map?bbox= and friends return JSON, but user/details only in XML.
17:33:30 <pnorman> maybe we'll find out all the different formats the API returns :)
17:35:17 <pnorman> Okay, I think that gives me enough to go on once we open up the changeset discussion
17:35:45 <pnorman> pencils down date for code is tommorow, then I have a week to do documentation (GSOC schedule requirements)
17:36:37 * pnorman finally figured out a way to do what was desired with apache
17:38:09 <zere> cool
17:38:18 <pnorman> anyways, issue trackers?
17:38:38 <zere> #topic "two trackers for the same component is stupid"
17:38:55 <pnorman> that was the comment in #osm and... I'm not sure I can disagree
17:38:58 <zere> i'm guessing this is about using github issues and PRs as well as trac?
17:39:06 <pnorman> yes
17:39:58 <zere> i don't think i can disagree either. although i think TomH felt that there was a different use for each.
17:40:18 <pnorman> it's hard enough figuring out where to open an issue where there aren't multiple options, where there are it's confusing and you don't know which is right
17:40:57 <zere> i don't remember what he was saying exactly, but i think it was along the lines that trac didn't require a github account, and was more suitable for issues which weren't "close" to the code.
17:41:17 <zere> i.e: github issues was better for technical discussion, trac better for bug reports.
17:41:47 <zere> i don't know if it's possible to have non-github-users submit issues to a github project.
17:42:16 <pnorman> well with their enterprise edition hosted seperately it is... but that's not really an option
17:43:31 <iandees> it's certainly easier to have a discussion about code on github
17:43:49 <iandees> trac is slowish (not as slow as josm.osm.de)
17:43:56 <iandees> neither are really disqualifiers though.
17:44:35 <pnorman> we also have components other than the rails port on trac where tickets against those components in trac actually aren't being accepted, but it's still technically possible to create them
17:44:56 <iandees> are they still "live" components?
17:45:11 <pnorman> I was thinking of "mapnik" in trac
17:45:31 <iandees> ah, yea that seems like it should go away.
17:46:00 <zere> i think by this point we're clearly not going to give up the benefits of github... so the remaining question is whether it's better to "close" the rails_port component on trac and require people to have github accounts to submit issues (unpopular) or find some other way for them to report issues (simple web form, perhaps?)
17:46:20 <pnorman> fyi I think https://trac.openstreetmap.org/wiki/OsmComponentReports is a full list of trac components
17:46:53 <zere> i'd love to get a group together to triage incoming issues and report the verifiable ones to github... but in practice i think it would fall into disuse quite quickly
17:47:14 <zere> hahahaha "applet"
17:47:29 <pnorman> ogr2osm isn't on trac anymore.
17:47:41 <iandees> what sort of anonymous bugs are people submitting via trac?
17:48:12 <zere> i thought it had been patched to use OSM logins?
17:48:42 <pnorman> it does, but it tends to log you out for one reason or another
17:49:08 <iandees> are bug reports where we can't interact with the reporter very helpful?
17:49:14 <pnorman> also relevant: https://github.com/gravitystorm/openstreetmap-carto/issues/96 (can I have my pony?)
17:49:49 <zere> well, indeed. hence "unpopular" ;-)
17:50:32 <iandees> i don't know that we'll solve the greater issue here, but perhaps an action could be taken to clean up the trac.osm.org components?
17:51:05 <iandees> i'm happy to send a list to tom for removal. the question is what do we do with old bugs?
17:51:14 <zere> given the constraints: we want to use github. github will never support OSM logins. we probably want some sort of login to allow interaction with the original reporter. - it seems very difficult to find a solution which isn't bad for someone
17:51:41 <pnorman> from a technical side, can we close a component to new issues where the maintainer has said they are not accepting tickets via trac? e.g. ogr2osm, mapnik/osm-carto
17:51:48 <zere> i guess "wontfix", since the component is going away
17:52:09 <zere> certainly i don't think anyone has any intention of updating the applet any more.
17:52:15 <iandees> yea
17:52:35 <zere> where there are other trackers to move them to, perhaps worth triaging again and seeing if any are still valid.
17:52:42 <pnorman> well that's a different case - the software is dead. ogr2osm is active
17:52:56 <iandees> i feel like we did this once before (triaging old trac tickets)
17:52:58 <pnorman> zere to go through all trac tickets and triage them, and close as necessary?
17:53:25 <zere> at least all the trac tickets for which there is a live project with a different tracker
17:53:48 <pnorman> fyi, 1.4k active tickets
17:54:26 <zere> basically one of three options: 1) the component is staying, the issues will stay too. 2) the component is going, but there's a live project to move the useful issues to, 3) the component is going, and the project is dead.
17:55:15 <zere> so each ticket (1) nothing happens, (2) is re-triaged in the live project and close in OSM trac, (3) closed "wontfix".
17:56:20 <iandees> i'll take action to dump a list of active tickets and work them into those 3 categories
17:56:30 <iandees> perhaps i'll put it on a google doc or something so others can help
17:58:20 <iandees> the trac wiki front page probably could be cleaned up to point in the right directions, too: https://trac.openstreetmap.org/
17:58:41 <pnorman> it's probably the rails port that's the big one. I have no idea if andy has interest in doing triage of trac tickets for mapnik to convert them to osm-carto tickets
17:59:52 <zere> well, 439 in component "mapnik"
18:00:11 <zere> 96 for "nominatim"
18:00:21 <pnorman> afaik nominatim still uses trac
18:00:37 <zere> 117 for "potlatch (flash editor)"
18:00:50 <zere> 191 for "potlatch2"
18:01:13 <zere> onl7 129 for "website"
18:01:19 <iandees> csv export doesn't include component
18:01:21 <zere> s/7/y/
18:02:14 <zere> and 35 for "api"
18:02:30 <zere> iandees: is https://trac.openstreetmap.org/query?status=accepted&status=assigned&status=new&status=reopened&group=component&max=1400&col=id&col=status&col=component&col=time&col=changetime&order=priority helpful at all?
18:03:13 <zere> there's a CSV download of that at the bottom, although i haven't tried it
18:03:32 <iandees> yea, i tried it on an earlier query and didn't get component. will try this
18:03:35 <pnorman> I just did the ogr2osm tickets (there weren't many). We can now get rid of or do whatever to prevent new ones from being opened
18:03:52 <iandees> that worked, thanks zere
18:05:13 <RichardF> fwiw I'm planning to move P2 tickets to github at some point (and don't really see any point in keeping P1 tickets open at all)
18:06:08 <pnorman> is there something we can do short-term to prevent new tickets from being opened while we're cleaning them up?
18:06:14 <zere> yup. not sure how to close a component. i'll ask TomH when he's back from the hackday.
18:06:18 <pnorman> k
18:09:00 <pnorman> probably want to discuss retaining people from the hack day next week, but nothing else on my list
18:10:27 <pnorman> and me and zere probably have cgimap stuff to discuss
18:13:54 <iandees> https://docs.google.com/spreadsheet/ccc?key=0AsVnlPsfrhUIdG1KVW5IZnhjNndqZFl6Z3pKUXJramc -- anyone should be able to edit that.
18:14:30 <zere> pnorman: cool. in the meeting, or after it?
18:14:36 <pnorman> after
18:14:54 <pnorman> iandees: if we wanted to change stuff about tickets, wouldn't we, oh, change the tickets? :P
18:15:15 <zere> awesome. as for retaining people - might be better to wait until next week so that those who were there can give us a better idea of what went on.
18:15:29 <zere> does anyone else want to discuss anything?
18:17:10 <iandees> not i
18:18:07 <pnorman> fyi, apache 2.4 has mod_proxy_fcgi which may be of interest.
18:18:17 <zere> cool. thanks to everyone for coming! and hope to see you next week :-)