I checked, and 1% of our last 500 commits touched more than 30 tests. Of
those 1%, over half touched more than 100 tests. So I'd guess somewhere
around .5% of prs will fall under the proposed changes.
My preference would be to just raise the threshold given that we already
raised the timeout. That
I think we should look at it from the standpoint of an SPI. The proxy work
should be pluggable. One implementation we will provide out of the box is SNI.
With this in mind geode-core (or better yet geode-proxy-spi) should only define
a few interfaces. ProxyConfiguration and ProxyFactory.
The
After some side discussions, I think different SniProxyConfiguration,
SocksProxyConfiguration, etc. interfaces are more than we need. Just having
a type, host and port should support any proxies we might see in the
foreseeable future.
I like this better: Option A
setProxy(ProxyType type, String h
To recap, the original question was: should we change StressNewTest to pass
ONLY if it is able to successfully run all new/changed tests 50 times
(eliminating the existing loophole exempting PRs that touch 25 or more files)?
So far a handful of people have expressed support, but many have
quest
The other reason I like setProxy(SniProxyConfiguration) is that it makes it
clear to the user what a legal value to pass in is. with
setProxy(ProxyConfiguration) the user can be mislead into thinking they are
supposed to implement ProxyConfiguration, but at runtime our code will
break if the object
On Tue, Mar 10, 2020 at 10:51 AM Robert Houghton
wrote:
> @dsmith
> The file change for determining the merge base was due to changing the
> Concourse resource. The file encodes the merge-base SHA, regardless of
> depth of the git checkout.
>
> Makes sense. But maybe the file is inaccurate? Seems
@dsmith
The file change for determining the merge base was due to changing the
Concourse resource. The file encodes the merge-base SHA, regardless of
depth of the git checkout.
On Tue, Mar 3, 2020 at 10:06 AM Dan Smith wrote:
> What's the current timeout for StressNewTest? Maybe if we just up th
Again, we should keep the API footprint *small* and quit adding overrides
for every type of Proxy we would (potentially) support. What is the point
of an abstraction/type-hierarchy if you don't use it?
The Enum would give users the possible range of currently supported Proxies
anyway.
Additional
I disagree.
I think /setProxy(ProxyConfiguration)/ is 1st prize.
If we are concerned that users will not know WHAT options are
available.. We could always have a static builder for our supported
options.
--Udo
On 3/10/20 10:07 AM, Dan Smith wrote:
Ok, how about this?
setProxy(SniProxyConf
Ok, how about this?
setProxy(SniProxyConfiguration config)
interface SniProxyConfiguration extends ProxyConfiguration {
static SniProxyConfiguration create(String host, int port);
String getHost();
int getPort()
}
The main difference here from John's proposal being that setProxy takes a
10 matches
Mail list logo
