Re: Cluster Metrics project proposal
toggle quoted messageShow quoted text
If the project instead ties into a broader umbrella as part of another project, at least simple things like patches that fix version numbers and other minor-but-critical things will have a broader pool of committers to draw from to keep things moving. Obviously, there is some trade-off in that people my not be as experienced with the code, but in this case that seems unlikely since it's code the very much seems in line with existing controller/clustering code and dluxapps.
For what it's worth, it seemed like Abhijit, Alexis, and I all felt like it would be worth seriously considering having this code be contributed as new parts of the controller and dluxapps projects instead of a new project. That be said, the new project was approved, so you can and should do what you feel is right.My personal take on why is pretty simple: we have seen lots of new projects that were small in scope and had the goal of "doing one thing and doing one thing well" and then had decreased interest followed by falling behind and not only no longer contributing the value they hoped, but actually becoming a burden on our release process despite the best of intentions.
Robert argued that we don't want to be adding anything to controller, but that rings exceptionally hollow to me. Either we declare controller dead and create the projects we need to house the live code or we admit that controller is live for the parts we care about (including clustering) and take contributions like a healthy project should.
Jan seemed to think that the stats collected being beyond just the clustering means it needs it's own project. I can see that argument, but I don't see a huge reason why that means it can't be housed in controller.
Anyway, as I said above, it's in your hands, but I wanted to take the time to lay out my concerns.
On Wed, Oct 26, 2016 at 3:11 PM, Daniel Malachovsky -X (dmalacho - PANTHEON TECHNOLOGIES at Cisco) <dmalacho@...> wrote: