It's always good to see a team that is clearly very passionate about their mission.

It's nice to see how Flynn evolved overtime within the HC community starting with the original crowdfunding. For a while some people didn't understand what Flynn does, and the updated website makes it very clear to me today.

I was interested to see that Flynn is using tup[0] for their build system. I always thought it seemed interesting, but hadn't really noticed any high-profile projects using it.

[0] http://gittup.org/tup/

Yeah, tup is neat. Much lower friction than the equivalent Makefiles as it can auto-detect dependencies and outputs in many cases. We've run into a couple issues, but for the most part it's been smooth sailing.

I'd be interested to hear some of the common issues you've had with tup and the solutions if you're ever looking for a blog post topic :)

Here are our current issues to date: https://github.com/flynn/flynn/issues?q=label%3Aupstream%2Ft...

It would be a good blog post topic, I'll make a note of that.

Hey Flynn team, quick question: I noticed that in the past, flynn dependencies like slugbuilder/slugrunner were separate git repos. Some time ago, everything was merged into the single flynn repo. What is the reasoning behind this move?

I see it as a disadvantage for other developers wanting to build on top of individual components. It also makes issues noisy.

Hey, Flynn cofounder here. We merged the repos (there were a few dozen!) after encountering a ton of friction landing project-wide changes and managing the build system (vendoring dependencies in every repo got ridiculous).

Contributors were also having a lot of trouble figuring out where to report issues and submit patches. On the whole the unified repo and build system has been a massive improvement to our productivity and the quality of the project. Unfortunately using components in a modular fashion can be harder, and we haven't come up with a great solution to that. We're still committed to keeping our components independently useful and would love to get feedback on what we can do better.

Okay, that makes sense. Thanks for the response!

Not on the Flynn team, but having a single repository instead of many makes it easier to make changes that cross packages without having to worry if you broke some remote thing.

Here's an article that discusses this idea: https://www.digitalocean.com/company/blog/taming-your-go-dep...

I'm still a bit confused about the pros/cons of using Flynn vs. Deis as they seem to try to solve the same problem. Can someone tell me what the main differences are?

Flynn cofounder here. The primary difference between Flynn and cloudfoundry, dawn, deis, dokku, octohost, openshift, tsuru, etc is that Flynn is designed to run everything itself, not just 12 factor web apps. Most immediately this means that you can run databases inside of Flynn alongside other apps. In fact we've already wrapped up postgres.

Flynn also tries to be more technology agnostic, for example we don't depend on CoreOS or Docker.

It's worth noting that several of the other platforms including Deis claim to be production ready today while Flynn is still a few months out.

The difference in both features and goals will be a lot clearer in the coming months. What we have today is just the foundation and minimum viable feature set. Once that's rock solid, the real work gets started.

You can run databases inside of cf as well: https://github.com/cloudfoundry/cf-mysql-release