Merge solo and master - Githubissues

vmware-archive / dispatch

Dispatch is a framework for deploying and managing serverless style applications.

http://dispatchframework.io

Apache License 2.0

532 stars 58 forks source link

Merge solo and master #696

Closed berndtj closed 5 years ago

berndtj commented 5 years ago

Feature Request

Detailed Description

The two repositories have as of yet not diverged much. Is there any downside to merge solo into master and delete the solo branch? We could cut a v0.1.x branch to preserve master as-is, but I'm not sure we need to yet. The downside is that we may break compatibility with current (master) dispatch in the near future as we add features and align with Knative. However, right now, we should be pointing folks towards dispatch-solo as it's a good way to get started.

The second question is if we should remove k8s support from solo then? Or if that support should change? This is debatable as it largely depends on the maturity of Knative and the dispatch-Knative branch.

Context

Possible Implementation

Complexity

[ ] Low - Simple enhancement or bug fix, no architectural changes or refactoring
[ ] Medium - Change requires some thought, but is relatively isolated
[ ] High - Significant architectural change or large refactor

kars7e commented 5 years ago

My thoughts:

If we are decided on going solo + knative, my understanding is that we will have the same APIs, just different underpinnings, reduced feature set, and different installation method. if so, we should strive to merge everything into single branch, and go from there. This means more upfront work but will reduce the pain later.
I'm all in on making the hard decision here and removing the k8s support. It's tempting to keep it, but IMHO focusing on one (well, two things) is more important.

markpeek commented 5 years ago

Typically master is used for the core development which for dispatch longer term is likely the knative branch. Per what @kars7e mentioned, if there will be commonality is solo and knative then do that in master. Otherwise, switching master to solo in the interim doesn't make as much sense to me. Oh, and keep in mind needing to merge the knative branch at some point.

berndtj commented 5 years ago

OK, so I'm hearing a few things:

merge the knative branch to master, accept that it's not full featured yet.
remove k8s support from solo (k8s support will be from knative)

So, should we then just keep solo as a branch (sounds like yes)?

berndtj commented 5 years ago

One more question, should we move the CLI to a dispatchframework repo?

imikushin commented 5 years ago

Sounds like a good idea. API / client library as well.

kars7e commented 5 years ago

For me, merging everything to master (including solo). I'm not sure how separate branch for solo helps here. I'm neutral on whether CLI should be a separate repo.

berndtj commented 5 years ago

We could also move the client out, though I'd probably hold off on that. I think we should have an in-person/zoom chat about whether to combine the servers into a single branch, though I can say from experience, switching branches right now is painful.

neosab commented 5 years ago

I like the idea to use knative branch as master.

But for solo if we don't plan to merge it back to future master (read knative) then we could as well move it to a new repo dispatch-solo. Any shared code can be later moved to another repo say dispatch/pkg. CLI / Client could follow the suite.

berndtj commented 5 years ago

I can create a new repo if that makes sense (I think it does). I have to go through OSSTP anyway for solo. Do we need to chat more, or is this a plan?

tenczar commented 5 years ago

I also like the idea of knative as master and removing k8s from solo. My only concern is making sure that changes to the cli don't break e2e tests in the knative or solo repos.