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. > > 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. > 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
