[Hawkular-dev] Collapsing of Repos ?

[Peter Palaga]

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:
> On Wednesday, May 04, 2016 03:12:09 PM Michael Burman wrote:
>> Hi,
>>
>> Why? More repositories is good. If something can be split to new
>> repositories, it should be done (like the rxjava-cassandra-stuff from
>> metrics).
>
> Twitter, Google, Facebook and others may disagree with you with their
> "monorepo" approach to development (a term I learned today :) ).
>
> I'm not sure how they manage to a) have everything in 1 repo and b) have
> independently versioned artifacts without it being exactly the same pain as it
> is with multiple repos, but there must be something to it (like
> http://danluu.com/monorepo/ or http://www.pantsbuild.org/why_use_pants.html).
>
> I'm a fan of granularity btw and I don't think we'd see much benefit in
> merging the repos unless we release all the components at the same time (which
> I don't think is a good idea).
>
>> What could be advantage of pushing alerts stuff to the
>> metrics-repository?
>>
>
> I don't see much of a benefit there either...
>
>>    - Micke
>>
>> ----- Original Message -----
>> From: "Heiko W.Rupp" <hrupp at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Wednesday, May 4, 2016 5:10:00 PM
>> Subject: [Hawkular-dev] Collapsing of Repos ?
>>
>> Hi,
>>
>> we do have a larger number of repositories and source trees.
>> Now that we have narrowed down the scope of our work a bit and also
>> have an idea of what we need for the "core services" package, I wonder
>> if we can collapse repositories and source trees into larger ones.
>>
>> As an example: alerts and metrics could go together into
>> hawkular-metrics and the forwarding of data to alerts could be
>> done with Java method invocation.
>>
>> What else could be done here?
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>