I tentatively scheduled 4.3.0.Beta6 (which is looking likely to be the
first CR) for November 6th which is the 4 week timebox. Trouble is,
that this is the day I am scheduled to fly back from Rome.
So all in all, this release is likely to happen early or late.
__
I thought I remember someone (Brett? Strong?) going through an cleaning
up references to logging libraries we no longer use. But I still see
entries in libraries.gradle in master for:
slf4j_api: "org.slf4j:slf4j-api:${slf4jVersion}",
slf4j_log4j12: "org.slf4j:slf4j-lo
I don't have much stake in the specialized method vs context object
debate as indeed the interface is very specialized and prone to changes.
But as Sanne mentioned, there are memory pressure consequences if this
call is in the hot path.
It is correct that the current use of ForDeletion requires to
On 8 Jan 2013, at 1:38 PM, Sanne Grinovero wrote:
> Guys let's put this into perspective.
> These arguments I'm hearing against adding a method in a power-user
> oriented SPI are way outbalancing the harm they do to the project in
> terms of release delays and our very own time, there are defini
Guys let's put this into perspective.
These arguments I'm hearing against adding a method in a power-user
oriented SPI are way outbalancing the harm they do to the project in
terms of release delays and our very own time, there are definitely
more interesting issues to dedicate our time on.
I appr
2013/10/8 Sanne Grinovero
> We'll need to time cap this discussion as we're way too late, of
> course this will need to be tagged @experimental.
> Having said that, let's try to find the best proposal possible by
> lunch time, as one of the approaches needs to be merged: it's very
> clear that th
On 8 Jan 2013, at 11:56 AM, Sanne Grinovero wrote:
> Having said that, let's try to find the best proposal possible by
> lunch time, as one of the approaches needs to be merged:
I think we very well could go w/ the current state right now and evolve in
future versions.
I would like to explore
We'll need to time cap this discussion as we're way too late, of
course this will need to be tagged @experimental.
Having said that, let's try to find the best proposal possible by
lunch time, as one of the approaches needs to be merged: it's very
clear that there is big practical value for the use
On 8 Jan 2013, at 10:08 AM, Gunnar Morling wrote:
> I'm not sure whether it has been considered before, but maybe we could unify
> the methods and work with a parameter object as a middle ground:
It has been. I suggested before to combine the methods. I think it is a good
approach, but Sanne
Sanne,
As you say adding yet another interface makes things even more difficult to
grok; So I'd vote for adding the method for the deletion use case to SIP
directly.
I'm not sure whether it has been considered before, but maybe we could
unify the methods and work with a parameter object as a midd
10 matches
Mail list logo
