The wiki does not seem to be operational ATM, but I will do this when
it is back up.
On Mon, Jan 19, 2015 at 12:00 PM, Patrick Wendell wrote:
> Okay - so given all this I was going to put the following on the wiki
> tentatively:
>
> ## Reviewing Code
> Community code review is Spark's fundamental
Okay - so given all this I was going to put the following on the wiki
tentatively:
## Reviewing Code
Community code review is Spark's fundamental quality assurance
process. When reviewing a patch, your goal should be to help
streamline the committing process by giving committers confidence this
pa
Patrick's original proposal LGTM :). However until now, I have been in the
impression of LGTM with special emphasis on TM part. That said, I will be
okay/happy(or Responsible ) for the patch, if it goes in.
Prashant Sharma
On Sun, Jan 18, 2015 at 2:33 PM, Reynold Xin wrote:
> Maybe just to a
Maybe just to avoid LGTM as a single token when it is not actually
according to Patrick's definition, but anybody can still leave comments
like:
"The direction of the PR looks good to me." or "+1 on the direction"
"The build part looks good to me"
...
On Sat, Jan 17, 2015 at 8:49 PM, Kay Ouste
+1 to Patrick's proposal of strong LGTM semantics. On past projects, I've
heard the semantics of "LGTM" expressed as "I've looked at this thoroughly
and take as much ownership as if I wrote the patch myself". My
understanding is that this is the level of review we expect for all patches
that ulti
Yeah, the ASF +1 has become partly overloaded to mean both "I would like to see
this feature" and "this patch should be committed", although, at least in
Hadoop, using +1 on JIRA (as opposed to, say, in a release vote) should
unambiguously mean the latter unless qualified in some other way.
I d
I think the ASF +1 is *slightly* different than Google's LGTM, because
it might convey wanting the patch/feature to be merged but not
necessarily saying you did a thorough review and stand behind it's
technical contents. For instance, I've seen people pile on +1's to try
and indicate support for a
I think I've seen something like +2 = "strong LGTM" and +1 = "weak LGTM;
someone else should review" before. It's nice to have a shortcut which
isn't a sentence when talking about weaker forms of LGTM.
On Sat, Jan 17, 2015 at 6:59 PM, wrote:
> I think clarifying these semantics is definitely wor
I think clarifying these semantics is definitely worthwhile. Maybe this
complicates the process with additional terminology, but the way I've used
these has been:
+1 - I think this is safe to merge and, barring objections from others, would
merge it immediately.
LGTM - I have no concerns about
+1 on this.
> On Jan 17, 2015, at 6:16 PM, Reza Zadeh wrote:
>
> LGTM
>
> On Sat, Jan 17, 2015 at 5:40 PM, Patrick Wendell wrote:
>
>> Hey All,
>>
>> Just wanted to ping about a minor issue - but one that ends up having
>> consequence given Spark's volume of reviews and commits. As much as
>
LGTM
On Sat, Jan 17, 2015 at 5:40 PM, Patrick Wendell wrote:
> Hey All,
>
> Just wanted to ping about a minor issue - but one that ends up having
> consequence given Spark's volume of reviews and commits. As much as
> possible, I think that we should try and gear towards "Google Style"
> LGTM on
11 matches
Mail list logo
