[infinispan-dev] moving (some) cache stores in a different github repository

[Sanne Grinovero]

On 9 May 2013 23:18, Mircea Markus <mmarkus at redhat.com> wrote:
>
> On 9 May 2013, at 22:13, Sanne Grinovero wrote:
>
>> On 9 May 2013 21:38, Mircea Markus <mmarkus at redhat.com> wrote:
>>>
>>> On 9 May 2013, at 16:03, Sanne Grinovero wrote:
>>>
>>>> On 9 May 2013 15:10, Manik Surtani <msurtani at redhat.com> wrote:
>>>>> This is something we discussed last year.  IIRC we agreed that all cache stores (except the 0-dep FCS) and hot rod clients will move out of the infinispan repo, and have their own repos.  They will also have their own release cycles, so will only be released as and when there is a change in their code.
>>>>
>>>> I remember the discussion, but never agreed on it being a good idea.
>>>> I'm not strictly against it, just that I am not understanding the
>>>> point if it, while there are drawbacks.
>>> pros: reduce distribution size, keep build time for the core manageable, allow a per/cachestore upgrade.
>>
>> Is that the only advantage?
> indeed the first one I mentioned could be achieved through packaging, but not the last two.

I don't understand the merit on the last two either:

# "keep build time for the core manageable"

Manik mentioned that all CacheStore s would be tested after each core
change, even rising the question of how to let the CORE build fail in
case one would have problems, so you still have to run tests for all
modules: the build time doesn't change neither for pull request
reviewers nor CI server.

Admit it: you plan to not run all tests all the time, or if a
CacheStore fails to fix it "later". At the very best such a fix
happens after the damage is done.

Note that the MongoDB CacheStore - even if just in pull request state
- self activates its own build (and tests) only if the runtime
provides a MongoDB instance., so partially applying this idea to
simplify build requirements (i.e. not mandating a MongoDB installation
to build infinispan core tests). Of course this would be still
expected from team members and CI server.
It's an example of another approach to disable some modules - if you
really want that - without changing the source structure.

# "allow a per/cachestore upgrade"

I'm confused on this one. Do you mean "allow the team to forget
updating some cachestore" ?

To me it looks like a proposal to downgrade importance of maintenance
of some (all?) cachestores; we could discuss that if you prefer? It
just looks like a different subject.

>> Because the source control should have
>> nothing to do with how the distribution is assembled.
>> I still don't see why it's worth the effort,
> it's a pretty straight forward task to move them out. Same to add CI job :-)
>> and the pain.
> If you're referring to the possibility of the cache store build to fail, I don't think this is negative thing as the core test suite should only get better.

Not every change is an improvement; I don't think the test suite will
improve automagically if we make the wrong choices. But by "pain" I
was referring to the need to keep multiple repositories in sync
without cross-tagging capabilities nor anything similar; you'll need
releases of one to move forward with the other, etc..
Or is the plan to use git modules?
Usually people resolve such problems by merging multiple projects in a
single repo..

In summary, I'm not strictly against it as technically I won't
maintain either side of the integration, just that I see *exclusively*
disadvantages for you so I'm quite confused by the suggestion.

Cheers,
Sanne

>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev