<div dir="ltr"><div>Mircea, what exactly are the problems that we want to achieve by moving everything back in a single repository?</div><div><br></div><div>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.</div>
<div><br></div><div>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?<br>
</div><div><br></div><div>Cheers</div><div>Dan</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 10:26 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've created ISPN-3728 to track this.<br>
<div class="HOEnZb"><div class="h5"><br>
On Nov 18, 2013, at 2:16 PM, Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br>
<br>
> +1, also only the gui-demo should be in the main repo. All other<br>
> examples/demos should be moved to quickstarts or their own repos.<br>
><br>
> Tristan<br>
><br>
> On 11/18/2013 09:15 AM, Galder Zamarreņo wrote:<br>
>> On Nov 15, 2013, at 2:02 PM, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br>
>><br>
>>> +1<br>
>>> (as I've always been, damn my "pessimistic" opinions)<br>
>>><br>
>>> However there is an alternative. If I recall correctly, one of your<br>
>>> motivations for the split was to not keep maintaining all the<br>
>>> non-essential components.<br>
>>> I really like that idea, I just think it was implemented the wrong way.<br>
>>><br>
>>> If you identify which components are non-essential (and you don't need<br>
>>> them on the release day), you should keep them out but unlock them to<br>
>>> a different version numbering, and especially never ever depend on<br>
>>> snapshot versions.<br>
>>><br>
>>> Let's try define the requirements:<br>
>>> - any project should compile successfully out of the box<br>
>>> - last minute "surprises" before a release needs to be done is not manageable<br>
>>><br>
>>> You could get this easily if you allow the projects which are in a<br>
>>> different repository to lag behind: you can't require to release those<br>
>>> other projects each time you release an Infinispan "core" version.<br>
>>> Which inherently implies that if you have something which is essential<br>
>>> for a core release, it needs to be moved back to catch failures early<br>
>>> on and keep them in perfect sync.<br>
>>><br>
>>> Other module maintainers would then catch up on compatibility breaking<br>
>>> changes of Infinispan core as (and when) they can. We can of course<br>
>>> have a goal of keeping aligned quickly, but it should be optional<br>
>>> (i.e. non-blocking for innovation and progress on the core module).<br>
>> + 1 to all said above and Mircea's suggestion.<br>
>><br>
>> 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.<br>
>><br>
>>> It's perfectly doable, all our other projects depending on Infinispan<br>
>>> have lived well so far, with the occasional pain to fix some backwards<br>
>>> compatibility issue but that's part of the dance. For example Search<br>
>>> depends on Hibernate ORM, JGroups and Infinispan.. we try to catch<br>
>>> backwards compatibility with ad-hoc CI jobs but it's not going to<br>
>>> catch all problems, nor it's our intention to "block" other projects<br>
>>> from innovating: it's rather for us to be aware of possible problems<br>
>>> asap.. but none of these problems are allowed to prevent us to release<br>
>>> early and often.<br>
>>><br>
>>> [BTW the reason the Search case isn't perfect is because we target<br>
>>> specific platforms like AS/Wildfly, not necessarily the latest<br>
>>> Infinispan]<br>
>>><br>
>>> Cheers,<br>
>>> Sanne<br>
>>><br>
>>><br>
>>> On 15 November 2013 12:43, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
>>>> Hi guys,<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> wdyt?<br>
>>>><br>
>>>> Cheers,<br>
>>>> --<br>
>>>> Mircea Markus<br>
>>>> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
>> --<br>
>> Galder Zamarreņo<br>
>> <a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
>> <a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
>><br>
>> Project Lead, Escalante<br>
>> <a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
>><br>
>> Engineer, Infinispan<br>
>> <a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
Cheers,<br>
--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>