[infinispan-dev] merging all the github projects back?

[Dan Berindei]

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 <mmarkus at redhat.com> wrote:

> I've created ISPN-3728 to track this.
>
> On Nov 18, 2013, at 2:16 PM, Tristan Tarrant <ttarrant at redhat.com> 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 <sanne at infinispan.org>
> 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 <mmarkus at redhat.com> 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
> >>>> infinispan-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> --
> >> Galder Zamarreño
> >> galder at redhat.com
> >> twitter.com/galderz
> >>
> >> Project Lead, Escalante
> >> http://escalante.io
> >>
> >> Engineer, Infinispan
> >> http://infinispan.org
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131119/976cc322/attachment-0001.html