Mircea, what exactly are the problems that we want to achieve by moving everything back in a single repository?
To me, the biggest problem right now is that builds take way too long, and if I integrate something in master it will take almost an entire day for TeamCity to update the status on all the open pull requests. I don't think moving everything to a single repository will fix that, TBH. BTW, Maven rebuilds every module in the reactor every time you run a build. On my machine, it takes 6 minutes to build everything in the Infinispan reactor. Would you really want to wait 6 minutes every time you want to test something in the server? Cheers Dan On Mon, Nov 18, 2013 at 10:26 PM, Mircea Markus <[email protected]> wrote: > I've created ISPN-3728 to track this. > > On Nov 18, 2013, at 2:16 PM, Tristan Tarrant <[email protected]> wrote: > > > +1, also only the gui-demo should be in the main repo. All other > > examples/demos should be moved to quickstarts or their own repos. > > > > Tristan > > > > On 11/18/2013 09:15 AM, Galder Zamarreño wrote: > >> On Nov 15, 2013, at 2:02 PM, Sanne Grinovero <[email protected]> > wrote: > >> > >>> +1 > >>> (as I've always been, damn my "pessimistic" opinions) > >>> > >>> However there is an alternative. If I recall correctly, one of your > >>> motivations for the split was to not keep maintaining all the > >>> non-essential components. > >>> I really like that idea, I just think it was implemented the wrong way. > >>> > >>> If you identify which components are non-essential (and you don't need > >>> them on the release day), you should keep them out but unlock them to > >>> a different version numbering, and especially never ever depend on > >>> snapshot versions. > >>> > >>> Let's try define the requirements: > >>> - any project should compile successfully out of the box > >>> - last minute "surprises" before a release needs to be done is not > manageable > >>> > >>> You could get this easily if you allow the projects which are in a > >>> different repository to lag behind: you can't require to release those > >>> other projects each time you release an Infinispan "core" version. > >>> Which inherently implies that if you have something which is essential > >>> for a core release, it needs to be moved back to catch failures early > >>> on and keep them in perfect sync. > >>> > >>> Other module maintainers would then catch up on compatibility breaking > >>> changes of Infinispan core as (and when) they can. We can of course > >>> have a goal of keeping aligned quickly, but it should be optional > >>> (i.e. non-blocking for innovation and progress on the core module). > >> + 1 to all said above and Mircea's suggestion. > >> > >> The thing is that Infinispan Server, and a subset of the cache stores > really need to be released at the same time as Infinispan core. All those > modules would benefit from living in same repo, making the compilation, CI > and release much easier. Some examples: Level DB store needs to be brought > back, whereas Cassandra cache store can live on its own. > >> > >>> It's perfectly doable, all our other projects depending on Infinispan > >>> have lived well so far, with the occasional pain to fix some backwards > >>> compatibility issue but that's part of the dance. For example Search > >>> depends on Hibernate ORM, JGroups and Infinispan.. we try to catch > >>> backwards compatibility with ad-hoc CI jobs but it's not going to > >>> catch all problems, nor it's our intention to "block" other projects > >>> from innovating: it's rather for us to be aware of possible problems > >>> asap.. but none of these problems are allowed to prevent us to release > >>> early and often. > >>> > >>> [BTW the reason the Search case isn't perfect is because we target > >>> specific platforms like AS/Wildfly, not necessarily the latest > >>> Infinispan] > >>> > >>> Cheers, > >>> Sanne > >>> > >>> > >>> On 15 November 2013 12:43, Mircea Markus <[email protected]> wrote: > >>>> Hi guys, > >>>> > >>>> Given all the compiling problems we had since we've split in multiple > github repos (server, stores and embedded) makes me think that the split > wasn't such a great idea after all( and that I was hmm, wrong). Shall we > move everything back into a single repo? We can still keep different CI > runs for cache stores, server etc, but at least all this builds will > compile everything. > >>>> > >>>> wdyt? > >>>> > >>>> 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 > >> > >> -- > >> Galder Zamarreño > >> [email protected] > >> twitter.com/galderz > >> > >> Project Lead, Escalante > >> http://escalante.io > >> > >> Engineer, Infinispan > >> http://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 >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
