Matthew Wigginton Bhagat-Conway

Deploying to the Node server is not a long-term solution.

We currently push things out to servers, and then have very little idea what happens to them after that.

Right now we use the hash of specific bits of the file to compare, which was done for speed. But ZIP files have stable format, so changing, say, only stops.txt...

For some reason it's possible to upload the same feed twice in a row.

When we create the deployment bundle, we should use the `store` compression technique for GTFS and OSM, as they are already compressed.

If feed fetch takes longer than the nginx timeout, the spinner spins forever.

In a deployment, the feed versions of the sources that could not be loaded are updated when nothing else is

1

Steps to reproduce: 1. load a totally broken feed to a new feed source (easiest way to get a broken feed: `dd if=/dev/urandom of=brokenFeed.zip bs=1024 count=12`) 2. create a deployment....

Sometimes, feed sources that could not be added don't show up in the deployment view. Whenever I try to fix it, the problem goes away, but leaving this here because...

Little maps showing the bounds of feeds and deployments would be useful.

The timeout on graph build should be really long. Maybe a single HTTP connection isn't the way to do this.