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

[Mircea Markus]

On 10 May 2013, at 00:48, Sanne Grinovero wrote:

> On 10 May 2013 00:24, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>> On 9 May 2013, at 23:47, Sanne Grinovero wrote:
>> 
>>> 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.
>> They shouldn't be tested on every build the same we we don't test 3rd party cache stores on every build. Once a day should be enough IMO.
>> Also we'll have the FileCacheStore and the RemoteCacheStore that run on every build.
> 
> Ok that clarifies the goal. Use profiles?
> 
>>> 
>>> Admit it: you plan to not run all tests all the time, or if a
>>> CacheStore fails to fix it "later".
>> no :-) fix it as soon as it is spotted and ad a test in the core suite to make sure it won't happen again.
>> 
>>> At the very best such a fix
>>> happens after the damage is done.
>> Possibly. Things should improve with time though, as unit tests are added to catch the failures.
>> 
>>> 
>>> 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.
>> that's quite clever
>>> 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" ?
>> The main reason is: if we fix a critical bug e.g. JDBC cache store we can release it immediately without an full release cycle and people can take advantage of that sooner.
> 
> -1
> Release it all often.
I don't think it's practical to release a new version of infinispan if something critical is fixed in the jdbcaches store.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)