On 10 May 2013, at 00:48, Sanne Grinovero wrote: > On 10 May 2013 00:24, Mircea Markus <[email protected]> wrote: >> >> On 9 May 2013, at 23:47, Sanne Grinovero wrote: >> >>> On 9 May 2013 23:18, Mircea Markus <[email protected]> wrote: >>>> >>>> On 9 May 2013, at 22:13, Sanne Grinovero wrote: >>>> >>>>> On 9 May 2013 21:38, Mircea Markus <[email protected]> wrote: >>>>>> >>>>>> On 9 May 2013, at 16:03, Sanne Grinovero wrote: >>>>>> >>>>>>> On 9 May 2013 15:10, Manik Surtani <[email protected]> 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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
