On Wed, May 4, 2016 at 4:33 PM, John Sanda <jsanda(a)redhat.com&gt; wrote: Data Mining also listen on the bus.

On 4 May 2016, at 21:12, Michael Burman wrote: Having one repo certainly makes the release process and interdependency changes easier. With the many repos we have, we have a pretty complicated setup to get a final release out with many operations that need to happen in special ordering.

Yes, the overhead with releasing and synchronization of changes grows substantially with the number of component git repos. Splitting strictly by business domains leads to many small git repositories: going that way, e.g. the nowadays commons would have to be split to as many as 7 component repositories: Nest, Bus, Embedded Cassandra, Email, Inventory Paths, Rest Status and Templates. Clearly, we want neither this extreme, nor one (or too few) huge repos. To find a good balance, there are several aspects to consider. Here are my favorite ones: (1) The intensity of development. This can be measured by e.g. the number of developers working concurrently in the given git repo, the number of new PRs daily, etc. (2) The usual time from sending a new PR to its merge. This consists of the time the CI needs to run all tests and the time needed for review. Clearly, the bigger a git repo the more engineers will work on it and the more PRs will be sent daily. And also, the bigger repo, the more tests and the longer CI run times, and the longer PR queue and the higher probability of conflicting PRs. I do not know what is the max acceptable CI run time for other team members, my subjective value is 25mins. Furtermore, in the world I wish to live in, PRs are merged within 8 business hours. If we are under these numbers somewhere, we have potential to merge repos. For the specific case of Alerts and Metrics: While adding the ~4 Metrics devs to 2 Alerts devs seems to be OK, the summed CI times do not look acceptable to me. Alerts CI time: Travis 34 mins Metrics CI time: Travis 12min, Jenkins 30min (running in parallel) By merging the two repos, probably only the Travis times would have to be summed together: ~40min (3) The most devs assigned to the repo should be able to fix problems in all its parts. In other words, if my change in Metrics breaks Alerts (assuming they live in the same repo), am I able to fix Alerts? I would not want to wait for Jay or Lucas to fix my PR before it can be merged. Thanks, Peter On 2016-05-04 22:03, Lukas Krejci wrote:

I agree with Lucas, I'd rather see us package alerts+metrics together if that makes sense, but maintain separate repos/releases. Note that H Alerting development/release is now on an on-demand need for a fix or enhancement that directly supports an external need, and the ability to release quickly is useful. Overall, I don't see enough reward for a repo restructuring investment. On 5/5/2016 8:50 AM, Lucas Ponce wrote: