Interesting is the comparison with Maven:
Gradle has been in "Assess" since July 2011 (first appearance), now
promoted to "adopt"
Maven first appeared in March 2012 scoring "Hold" because of it's lack
of flexibility and never made any progress... never!
Sanne
On 9 July 2013 21:53, Hardy Ferentsc
On 9 Jul 2013, at 22:48, Steve Ebersole wrote:
> Amen brother! ;)
Lol
>
> On Tue 09 Jul 2013 03:08:11 PM CDT, Hardy Ferentschik wrote:
>> hi,
>>
>> I guess especially Steve might like this. In the latest edition of the
>> ThoughtWorks Tech Radar
>> Gradle moved into the adopt zone in the to
I guess we have been talking up requests from within the team. At least I have.
IMO they are generally a different beast with other things to consider.
--hardy
On 9 Jul 2013, at 22:48, Steve Ebersole wrote:
> I am curious if y'all are talking about all pull requests, whether that be
> from
hi,
I guess especially Steve might like this. In the latest edition of the
ThoughtWorks Tech Radar
Gradle moved into the adopt zone in the tools section whereas Maven is now on
hold :-)
http://thoughtworks.fileburst.com/assets/technology-radar-may-2013.pdf
--Hardy
I basically like what I hear. Some wise words :-)
On 9 Jan 2013, at 9:00 PM, Emmanuel Bernard wrote:
> There has been a tendency to let PR sit a bit longer than it should as
> we all try to get our stuff done before diving into other's PRs.
> I have been particularly guilty and Hibernate OGM is
Some random thoughts
There has been a tendency to let PR sit a bit longer than it should as
we all try to get our stuff done before diving into other's PRs.
I have been particularly guilty and Hibernate OGM is a particularly bad
example. I did not see too much lagging PRs on other projects but I
Comments inline:
On 9 Jan 2013, at 5:56 PM, Sanne Grinovero wrote:
> I also don't think we can nail down precise "rules" .. I will just ask
> to use common sense and try hard to merge pulls quickly.
what do you want, a review or an automatic merge? Some pull requests can
be merged quickly, som
I think we all agree that PRs have many merits: it's almost pointless
to try highlighting them as we're all experienced developers, and I
guess we all have some horror stories from back in the dark ages when
we couldn't use them.
When we moved to git very few of us had some experience with it, but
+1
We need to test it, not just for the functional aspect of our code but
to make sure the _build_ works fine in both configurations.
Also, I'm pretty sure the server mode and embedded mode can not
guarantee to be using the same MongoDB version so it's possible that a
fix made by someone is verifi
2013/7/9 Emmanuel Bernard
> Custom configuration is not something you would exercise for example.
> I'm talking about hostname, ports, the ability to forbid plain "table"
> scan.
>
> Gunnar's proposal for an additional slave job only running the mongodb
> module with the non embedded mode seems t
Custom configuration is not something you would exercise for example.
I'm talking about hostname, ports, the ability to forbid plain "table"
scan.
Gunnar's proposal for an additional slave job only running the mongodb
module with the non embedded mode seems the easiest solution.
Emmanuel
On Tue
I just don't get the point. AFAIU the embedded version is nothing else than a
downloaded mongodb,
installed in a given directory and started by the plugin. Where is the
difference to a "proper"
mongodb instance? Installing MongoDB is nothing else than getting the
distribution and running the
dae
12 matches
Mail list logo
