<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 30, 2017 at 1:36 PM, Gordon Sim <span dir="ltr"><<a href="mailto:gsim@redhat.com" target="_blank">gsim@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree with the view that we should evolve towards fewer repositories than we have now.<br> <br> To my mind, breaking things down by the deployment or address-space type doesn't feel right.<br> <br> While I can certainly see that a single repo would simplify the CI, I instinctively dislike that also. There would seem to me to be a whole range of fairly unrelated things all bundled together. In a way it is avoiding the effort of trying to find the right division. Had we started off that way, it might have made sense, however while I think this is an important conversation to have, I wouldn't want to rush in to that decision.<br> <br> I could see a couple of smaller changes that would reduce the number of repos, without making any radical change. e.g.<br> <br> * combine ragent and routilities<br> <br> * combine router-image and router-metrics<br> <br> * combine artemis-image and topic-forwarder<br> <br> * combine mqtt-gateway and mqtt-lwt<br> <br> I think putting subserv into routilities would make sense as a short term step also, as there is some code that can be shared. However longer term I think we need to rethink the implementation of that component and it could end up in a very different form.<br> <br> If we did all that, we could eliminate 5 repos from the current set.<span><br> <br></span></blockquote><div><br></div><div><br></div></div>I agree it's a work-around in that sense, and I don't think we'll find the right division between the components in the near future, as it is likely to evolve. For instance, we've discussed things like a) combining functionality of router agent and queue scheduler in a 'address manager', b) making the console work standalone as well as in enmasse, c) creating a 'standard-controller' that handles the 'standard' address space, and d) documenting and testing the API between components.</div><div class="gmail_extra"><br></div><div class="gmail_extra">There will probably be more of these kinds of consolidation and moving of functionality, and I argue that having the components in the same repository would ease that work significantly. We can then define certain requirements to be met by a component before we split it into its own repo again. For instance, it could be that the "level of independence should be at level of qpid dispatch or artemis" in terms of:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> * having its own release cycle</div><div class="gmail_extra"> * a versioned and documented API of protocols and configuration tunables</div><div class="gmail_extra"> * being packaged and bundled as a 'standalone' application that can be easily put in a container</div><div class="gmail_extra"><br></div><div class="gmail_extra">We'll have to solve the CI 'problems' when splitting out repos eventually, but I think that a single repo will help the developer experience short term as well. I'd really like for the developer experience to be this:<br></div><div class="gmail_extra"> </div><div class="gmail_extra"> * start local openshift cluster</div><div class="gmail_extra"> * check out enmasse (and create your branch)</div><div class="gmail_extra"> * modify source code of component X</div><div class="gmail_extra"> * run a single command, i.e. 'gradle check pack deploy systemtest'</div><div class="gmail_extra"> * git commit && git push && git pull-request</div><div class="gmail_extra"><br></div><div class="gmail_extra">And, the CI should run the exact same commands so that builds are reproducible. Today, the list is much longer for doing more than a build and unit test:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"> * start local openshift cluster</div><div class="gmail_extra"> * checkout component X repo</div><div class="gmail_extra"> * modify source code of component X</div><div class="gmail_extra"> * follow component X build instructions and push docker (push docker can be skipped if you can run it directly against OpenShift)</div><div class="gmail_extra"> * checkout enmasse repo</div><div class="gmail_extra"> * modify enmasse config to include your custom component (may be skipped if you run it outside of OpenShift, but you may have to undeploy the one running already)</div><div class="gmail_extra"> * deploy enmasse from modified config (or original component if you run outside OpenShift)</div><div class="gmail_extra"> * checkout systemtests</div><div class="gmail_extra"> * follow systemtests build instructions and run</div><div class="gmail_extra"> * git commit && git push && git pull-request</div><div class="gmail_extra"><br></div><div class="gmail_extra">And thats if your work involves modifying 1 component only. When starting to split out repos, we can focus on keeping a good developer experience, which I think involves using a common build tool (i.e. gradle plugin to deal with the hard stuff) for instance.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Ulf</div></div></div>