On Fri, Feb 10, 2017 at 11:54 AM, Davor Bonaci
wrote:
> I think Dan's framework of thinking is right -- what is the probability of
> something finding a real issue, vs. the cost of running that all the time.
>
> Obviously, we cannot run *everything* all the time. There's an infinite
> number of t
I think Dan's framework of thinking is right -- what is the probability of
something finding a real issue, vs. the cost of running that all the time.
Obviously, we cannot run *everything* all the time. There's an infinite
number of things to run and infinite matrix of configurations. Many tests
ar
Ok will create a JIRA and PR.
On Fri, Feb 10, 2017 at 11:23 AM Eugene Kirpichov
wrote:
> Yup, this is the part of the style guide I had in mind. As you probably
> know from the PR, I'm in favor of "elements" :)
> Note that here we're naming a family of transforms - elements, kvs and
> iterables
Since the discussion has returned to the thread rather than Dan's PR, I
want to paraphrase the point I feel strongest about here:
*For a new contributor, I want to minimize the distance between them
deciding to hack and becoming our friends.*
So I don't want them to have to learn much, if anythin
Yup, this is the part of the style guide I had in mind. As you probably
know from the PR, I'm in favor of "elements" :)
Note that here we're naming a family of transforms - elements, kvs and
iterables (potentially more in the future), so the naming should be
consistent between the different version
On Fri, Feb 10, 2017 at 8:45 AM, Dan Halperin
wrote:
> On Fri, Feb 10, 2017 at 7:42 AM, Kenneth Knowles
> wrote:
>
> > On Feb 10, 2017 07:36, "Dan Halperin"
> wrote:
> >
> > Before we added checkstyle it was under a minute. Now it's over five?
> > That's awful IMO
> >
> >
> > Checkstyle didn't
How about we change the slower verification profile from being opt-in to
being opt-out?
Instead of casual contributors having to know about the release profile,
have the default verification verify everything needed and regular
developers that want just to install without all the verifications will
Agree!
Here I'm just responding to clarify and reiterate, since the threading
might appear as though I am the "you" in "the extra minutes you want to add
here will cost me an hour daily" and "you can see where I stand and why"
but I don't hold that opinion of that "you". I have said many of the sa
The ToString.of() violates the new transform rules and we need to choose a
new name.
Here is the method for reference:
/**
* Returns a {@code PTransform>} which
transforms each
* element of the input {@link PCollection} to a {@link String} using the
* {@link Object#toString} method.
I'm with Dan on this. The iteration time should be cut down as low as
possible and we have Jenkins to ensure that tests pass.
As a side note, there are IntelliJ plugins for Checkstyle and Findbugs and
my personal setup highlights Checkstyle violations as errors in the code so
I can immediately see
On Fri, Feb 10, 2017 at 7:42 AM, Kenneth Knowles
wrote:
> On Feb 10, 2017 07:36, "Dan Halperin" wrote:
>
> Before we added checkstyle it was under a minute. Now it's over five?
> That's awful IMO
>
>
> Checkstyle didn't cause all that, did it?
>
The "5 minutes" was going with Aviem's numbers af
On Feb 10, 2017 07:36, "Dan Halperin" wrote:
Before we added checkstyle it was under a minute. Now it's over five?
That's awful IMO
Checkstyle didn't cause all that, did it?
Noting that findbugs takes quite a lot more time. Javadoc and jar are the
other two slow ones.
RAT is fast. But it has
Before we added checkstyle it was under a minute. Now it's over five?
That's awful IMO
On Fri, Feb 10, 2017 at 07:14 Aviem Zur wrote:
> Opened JIRA ticket: https://issues.apache.org/jira/browse/BEAM-1457
>
> On Fri, Feb 10, 2017 at 4:54 PM Jean-Baptiste Onofré
> wrote:
>
> > Yeah. Agree. Time ex
Opened JIRA ticket: https://issues.apache.org/jira/browse/BEAM-1457
On Fri, Feb 10, 2017 at 4:54 PM Jean-Baptiste Onofré
wrote:
> Yeah. Agree. Time extend is not huge and it's worth to add it in verify
> phase.
>
> Regards
> JB
>
> On Feb 10, 2017, 10:13, at 10:13, Aviem Zur wrote:
> >This goes
Yeah. Agree. Time extend is not huge and it's worth to add it in verify phase.
Regards
JB
On Feb 10, 2017, 10:13, at 10:13, Aviem Zur wrote:
>This goes back to the original discussion in this thread - reduce the
>amount of things pull requesters should know and keep the maven command
>in
>the PR
This goes back to the original discussion in this thread - reduce the
amount of things pull requesters should know and keep the maven command in
the PR checklist as: 'mvn clean verify'.
So if rat and findbugs do not take that long to run I think they should be
run by 'mvn clean verify'
I ran a qu
Hi
We discussed about that at the beginning of the project. We agreed to execute
rat and findbugs in a specific profile to reduce the build time for dev.
That's why I do mvn clean install -Prelease before submitting a PR and just
clean install when I'm developing.
No problem to change that.
R
Can we consider adding rat-plugin and findbugs to the default verify phase?
Currently they only run when the `release` profile is enabled.
On Thu, Jan 26, 2017 at 11:42 AM Aljoscha Krettek
wrote:
> +1 to what Dan said
>
> On Wed, 25 Jan 2017 at 21:40 Kenneth Knowles
> wrote:
>
> > +1
> >
> > On
18 matches
Mail list logo
