-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
providing a stable output for iD #574
Comments
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 Before I publish a new version of iD, I grab the latest copy of ELI, run my script on it, and do a Instead - when ELI does change, semantic versioning can be used to signal to downstream projects how disruptive the change is.
|
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?
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? |
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 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. |
Snipping a quote from openstreetmap/iD#5412 (comment)
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?The text was updated successfully, but these errors were encountered: