That'd be great. go/github so people can find/identify you.
On Mon, Nov 11, 2019 at 11:05 AM Luke Cwik wrote:
>
> What is your github user id so people could tag you as a reviewer?
>
> On Mon, Nov 11, 2019 at 11:02 AM Brandon Pollack wrote:
>>
>> I might have some off time once and an while and
What is your github user id so people could tag you as a reviewer?
On Mon, Nov 11, 2019 at 11:02 AM Brandon Pollack wrote:
> I might have some off time once and an while and could use a change in
> pace sometimes, I wouldn't be able to much but Luke said you guys could use
> the help?
>
> --
> L
I might have some off time once and an while and could use a change in pace
sometimes, I wouldn't be able to much but Luke said you guys could use the
help?
--
Let me know how I'm doing! go/brpol-feedback
~||~ Flume
B B B
i a r
g l a
d n
d
o
n
I do think we need something less generic than our current @Experimental. I
also like the idea of a separate package for unvetted contributions (though
Incubating might simply be confusing, given that Apache uses Incubating for
something else).
Good idea to have a standard way of marking such comm
Thanks, Reuven, for bringing this up. This is an area well worth
investing time in. Specific comments below.
On Mon, Feb 19, 2018 at 10:32 AM, Reuven Lax wrote:
> Pedantic
>
> Overly-pedantic comments (change variable names, etc.) can be frustrating.
> The PR author can feel like they are being
I'm ambivalent about the placement of less-stable contributions, but I'd be
very much in favor of being clear about how stable a given API is.
There's several axes of stability here, too:
- Is the API going to stay compatible
- Is the implementation going to stay compatible via pipeline updates
-
There was a suggestion of such a thing - a collection of less well-tested
and vetted contributions. The one that has the spirit I think of is the
Piggybank from Apache Pig. Most important to make sure all committers and
users both understand the meaning of it. The biggest problem is if users
really
On further thought I like the separate package even more. It allows us to
easily isolate all those tests, and not block commits or releases on them.
On Tue, Feb 20, 2018 at 7:45 AM, Reuven Lax wrote:
> Another idea: we could have a special package for these "unrefined"
> contributions. Once the
Another idea: we could have a special package for these "unrefined"
contributions. Once the contribution has had time to mature some, it can be
moved to the regular package structure.
On Tue, Feb 20, 2018 at 7:41 AM, Jean-Baptiste Onofré
wrote:
> I would add some @ToBeRefined or so đ
> Le 20 fév
I would add some @ToBeRefined or so đ
Le 20 févr. 2018 à 16:35, à 16:35, Reuven Lax a écrit:
>Hi JB,
>
>You're right, I was thinking more about changes to core when talking
>about
>the technical-excellence bar.
>
>I think there still needs to be some bar for new features and
>extension,
>but I al
Fully agree !
Thanks Reuven
Regards
JB
Le 20 févr. 2018 à 16:35, à 16:35, Reuven Lax a écrit:
>Hi JB,
>
>You're right, I was thinking more about changes to core when talking
>about
>the technical-excellence bar.
>
>I think there still needs to be some bar for new features and
>extension,
>but I
Hi JB,
You're right, I was thinking more about changes to core when talking about
the technical-excellence bar.
I think there still needs to be some bar for new features and extension,
but I also think it can be much lower (as nobody is breaking anything by
merging this). An example of where we s
+1. It's a fair idea to have dedicated guides.
Regards
JB
Le 20 févr. 2018 à 14:43, à 14:43, Alexey Romanenko
a Ă©crit:
>Reuven, thank you for bringing this topic.
>
>As a new contributor to Beam codebase I raise two my hands for such
>guideline document and I'd propose to add it as a new guide
Hi Reuven
I agree with all your points except maybe in term of bar level, especially on
new features (like extensions or IOs). If the PRs on the core should be heavily
reviewed, I'm more in favor of merging the PR pretty fast even if not perfect.
It's not a technical topic, it's really a contri
Reuven, thank you for bringing this topic.
As a new contributor to Beam codebase I raise two my hands for such guideline
document and I'd propose to add it as a new guide into section âOther Guidesâ
on web site documentation.
For sure, there are already several very helpful and detailed guides
This is excellent!
I can't really add anything right now but I think having a PR dashboard is one
of the most important points because it also indirectly solves "Review Latency"
and "Code Review Response SLA" by making things more visible.
--
Aljoscha
> On 19. Feb 2018, at 19:32, Reuven Lax w
There have been a number of threads on code reviews (most recently on a
"State of the project" email). These threads have died out without much
resolution, but I'm not sure that the concerns have gone away.
First of all, I'm of the opinion that a code-review bar for Beam commits is
critical to su
17 matches
Mail list logo
