+1 except [4] for me, too. [4] may be replaced with linking DISCUSSION mail
thread archive to JIRA.
Yes it doesn't update news on discussion to JIRA and/or Github, but at
least someone needed to see can find out manually.
Thanks,
Jungtaek Lim (HeartSaVioR)
2016년 10월 7일 (금) 오전 11:00, Satish Duggan
+1 for proposal except for [4]. Agree with Raghu on [4] as it may be
burdensome to update with summaries and folks may start replying comments
on those summaries etc and conclusions are updated on respective design
docs. We may want to start without [4].
Thanks,
Satish.
On Fri, Oct 7, 2016 at 12:
Mostly my thoughts are the same as Robert's. Use #3 whenever possible,
fallback to #1 otherwise, but please consider using informative names for
your methods in all cases.
#1 GBK.create(): IMO this pattern is best only for transforms where
withBar is optional or there is no such method, as in GBK.
Thanks for bringing this up. This inconsistency is something that has
bothered me as well.
Personally, I'm a fan of #3 when there's an obvious, required,
type-providing argument, and #1 otherwise. Note that these two are not
necessarily mutually exclusive.
Another thing to keep in mind is that Ja
Quite a few transforms in the SDK are generic (i.e. have type parameters),
e.g. ParDo, GroupByKey, Keys / WithKeys, many connectors (TextIO, KafkaIO,
JdbcIO, MongoDbGridFSIO etc - both read and write). They use different
styles of binding the type parameters to concrete types in caller code.
I wou
>
> At the end of the day, it comes down to two questions:
>
> 1) Are there technical and project direction discussions happening off
> list and not reflected back to the list?
>
> 2) If yes, are the concrete decisions being made as a result of the off
> list discussions?
> From an Apache standpo
+1 for rev...@beam.incubator.apache.org. Open lists are critically
important.
My comment earlier was mainly about (4). Sorry about the not being clear.
On Thu, Oct 6, 2016 at 11:00 AM, Lukasz Cwik
wrote:
> +1 for supporting different working styles.
>
> On Thu, Oct 6, 2016 at 10:58 AM, Kenneth
+1 for supporting different working styles.
On Thu, Oct 6, 2016 at 10:58 AM, Kenneth Knowles
wrote:
> +1 to rev...@beam.incubator.apache.org if it is turnkey for infra to set
> up, aka points 1 and 2.
>
> Even though I would not personally read it via email, getting the
> information in yet anot
Hi Daniel,
Thanks for raising this. I think I was a major contributor to your
frustration with the process by suggesting big changes to your IO PR.
As others have said, ideally that process should have gone differently: 1)
we should have had documentation on the best practices in developing IOs,
+1 to rev...@beam.incubator.apache.org if it is turnkey for infra to set
up, aka points 1 and 2.
Even though I would not personally read it via email, getting the
information in yet another format and infrastructure (and stewardship) is
valuable for search, archival, and supporting diverse work st
JB,
Are there any examples of similar process for another Apache project?
Providing regular updates of discussion happening another open list seems
burdensome, especially for new contributors who come to project with large
proposals.
If a feature is large enough, may be a there needs to be a desi
Great, I will definitely. Thanks !
I'm improving the CSS, and testing live with Jekyll. Hopefully, I will
be able to propose a pull request soon.
Regards
JB
On 10/06/2016 05:49 PM, James Malone wrote:
Awesome! If you need or want any help on other styling (like docs and such)
let me know - I
Awesome! If you need or want any help on other styling (like docs and such)
let me know - I am happy to help!
James
On Wed, Oct 5, 2016 at 11:33 PM, Jean-Baptiste Onofré
wrote:
> Hi
>
> For the website I already proposed a new design and css:
> http://maven.nanthrax.net/beam/
>
> I plan to prov
Hi,
I'm currently in holidays but I'll put some thought into this and give my
comments once I get back.
Aljoscha
On Wed, Oct 5, 2016, 21:51 Ben Chambers
wrote:
> To provide some more background I threw together a quick doc outlining my
> current thinking for this Metrics API. You can find it at
Hi team,
following the discussion we had about technical discussion that should
happen on the mailing list, I would like to propose the following:
1. We create a new mailing list: rev...@beam.incubator.apache.org.
2. We configure github integration to send all pull request comments on
review
Hi Dan,
I think for 1, we are not so far and things are improving smoothly. For
instance, Ben started the metric discussion thread on the mailing list.
Of course, we have to improve there, but it's just a question of time
and good habits.
For 2, I'm with you about that. IMHO, we need an agre
At the end of the day, it comes down to two questions:
1) Are there technical and project direction discussions happening off list and
not reflected back to the list?
2) If yes, are the concrete decisions being made as a result of the off list
discussions?
The answer to #1 is a definite yes.
Great summary Davor,
+1 with what you said.
Regards
JB
On 10/06/2016 08:29 AM, Davor Bonaci wrote:
Daniel, so glad you are starting to contribute to Beam! It was great
talking with you in person back in May. Welcome!
--
There are lots of different things mentioned here; I'll try to address t
Yes, but as said in another e-mail, even if it's a step forward, an
argued and valuable proposal message is better IMHO.
Regards
JB
On 10/06/2016 08:16 AM, Daniel Kulp wrote:
On Oct 6, 2016, at 2:33 AM, Dan Halperin wrote:
Anyway, I don’t really understand why the full github integration w
Hi Dan,
Even if enable the "full" Github integration is a step forward, I'm not
sure it will help at the end.
I'm afraid we (at least most of us ;)) won't read pull request comments
on the mailing list because it would be way more verbose.
So, I think there's more value to quickly explain a
20 matches
Mail list logo
