providing a stable output for iD

[andrewharvey]

Snipping a quote from openstreetmap/iD#5412 (comment)

...it can't happen currently because ELI doesn't actually issue stable releases like all the other software that iD depends on. I'll probably end up rewriting it someday. Anyway faster turnaround on imagery attribution text changes is not really a huge priority for most people.

Currently the imagery index in iD is only updated each iD release. It's almost been 2 months now since the last iD release which means their imagery index is almost 2 months out of date. I'd like to see that improved, but not sure on the best path forward.

@bhousel you said this is because ELI doesn't issue stable releases, from my understanding after each commit Travis CI will test and rebuild the index, so is https://osmlab.github.io/editor-layer-index/imagery.geojson not considered the stable up to date release which iD could pull each day or so for updates?

[bhousel]

@bhousel you said this is because ELI doesn't issue stable releases, from my understanding after each commit Travis CI will test and rebuild the index, so is https://osmlab.github.io/editor-layer-index/imagery.geojson not considered the stable up to date release which iD could pull each day or so for updates?

Sometimes the build is broken - this is just a fact of development. It happens to this index sometimes. When it happens, Potlatch doesn't work.

For iD, I'm much more comfortable depending on software that's been published by a human. Someone should take a quick look at it and say "ok looks good" before incrementing the version number and typing npm publish. That's not really asking a lot. This index doesn't really change much.

Before I publish a new version of iD, I grab the latest copy of ELI, run my script on it, and do a git diff to see what actually got changed.

Instead - when ELI does change, semantic versioning can be used to signal to downstream projects how disruptive the change is.

• A change to an imagery source in the index could be a patch release, and iD could pull these automatically.
• A new property added to the schema could be a minor release. It would be easy to handle but I'd probably want to prepare for it.
• Renaming / removing a property / changing the schema would be a major release, and would break downstream projects. ELI should be allowed to do this for good reasons.

[andrewharvey]

Sometimes the build is broken - this is just a fact of development. It happens to this index sometimes. When it happens, Potlatch doesn't work.

If we worked to improve the testing, do you think we could ever reach a point where it's good enough to feed straight into iD? After all each PR would go through that automated testing, plus a second pair of eyes as part of the review. Even if it broke, it wouldn't be long before someone noticed and either reverted or corrected it.

Even with a release, there's always a chance bugs make it through.

If we versioned ELI and effectivly did a new patch release after each PR, would that release process give any more QA over the regular PR merge process?

Instead - when ELI does change, semantic versioning can be used to signal to downstream projects how disruptive the change is.

That's a fair point, I hadn't considered schema changes. I guess for that we would need semantic versioning. Perhaps we could build this into the PR process, so that we do new patch releases for each PR which we want to go through to iD straight away?

[bhousel]

I feel like you are not even listening to me. This project doesn't have a version number. It has a robot that just runs make for people who forget to do it themselves. The robot introduces conflicts when people actually do run make.

It's a ruby script that runs make in a Travis hook to smoosh together JSON files with python. ELI might just be the hackiest nonsense I've ever seen. This is not how reliable software is built. "Adding more checks" is missing the point. Anyone with osmlab rights could just delete all the files. That we could "fix it quickly" is also missing the point. I'm sure I'd be the person responsible for fixing it quickly.

We will never take the autogenerated output on the master development branch of ELI and push it directly into iD. Never ever. Stop asking.

Let's close this issue, so I can get on with my weekend.