Greetings, I'd like to take a chance, now that 0.10 is out, to make a point in favor of using submodules rather than having all bindings in the same repository.
I think qpid-proton has reached the point where it's mature enough to have some of the bindings promoted to having their own repos. More importantly, I believe these bindings are mature enough and ready to build a community on their own. Lets take the python bindings, for instance. I've been contributing to the python bindings quite a bit in the last couple of months. The bindings went from depending on cmake for tests to having their own, still dependant on proton-test, test suite that is self-maintained. Furthermore, the python bindings went from depending on cmake to be built to being self-built using python's internal build system. It's still possible - and in fact, it still happens - to build these drivers running cmake, although it's, in my personal opinion, not recommended. As you can see from the above, the python bindings depend on proton-c but they don't need to live in the same codebase. Therefore, I've prepared a small POC to show case this repo structure: - https://github.com/FlaPer87/test-python-qpid-proton The above repo contains the python-qpid-proton code. As you can tell from the commit history, not many changes were required to set it up. The relevant bits of this repo, I believe, are the ones related to the submodule. The qpid-proton submodule points qpid-proton's master branch in the test-python-qpid-proton branch, whereas in the 0.10 branch, it tracks qpid-proton's 0.10.x. This is important for the bindings to keep track of the right code/release/tests. - https://github.com/FlaPer87/qpid-proton/tree/submodules The above is a fork of the qpid-proton repo we use already but rather than having the python-qpid-bindings in tree, it just tracks the master branch. (I created a `submodules` branch because I didn't want to mess with the master branch in my fork). I don't think tracking the binding in the qpid-proton repo is necessary but I see how it's useful to avoid introducing breaking changes on drivers. To be more precise, I don't think the above is necessary because if we are testing bindings in cmake to make sure we don't break backwards compatibility, we could simply install the latest stable version and test against that, rather than testing against the latest binding's master, which could, but shouldn't, be broken. I wouldn't probably advocate for the above to applied to every binding we have since some of them might not be ready for this but I definitely want to advocate to make this happen for the python binding (and other bindings). This structure will make it easier to mainting bindings, to build a community around these bindings - I contribute more to the python binding than proton-c. It'll also help keeping a clean history for each project and to issue binding releases, therefore creating tags for bindings, as needed. I get it's worked well so far and probably some of you won't be happy with this proposal but, git is powerful enough to support the above structure, which is ideal for these kind of projects. Correct me if I'm wrong but I believe the current structure also comes from the old times when qpid-proton used to be in subversion. Hope the above makes sense and I'm sorry for such a long email, I should've drunk less coffee. Flavio P.S: I'm more than happy to help setting this up and to bring it back if the experiment fails. -- @flaper87 Flavio Percoco
pgptypAhofUUf.pgp
Description: PGP signature
