Re: Root logger configuration

[Chad Dombrova]

On Mon, Dec 16, 2019 at 5:59 PM Pablo Estrada  wrote:

> +chad...@gmail.com  is this consistent with behavior
> that you observed?
>

I honestly can't recall, sorry.  I just remember that while I was testing I
updated sdk version and some logging stopped.  I *think* I was missing the
state/message stream, which would be on the client side after pipeline
construction.

-chad

Re: Root logger configuration

[Pablo Estrada]

+chad...@gmail.com  is this consistent with behavior
that you observed?

+Udi Meiri  sorry about the short notice on this. I know
you are working on RC1. But do you think this should be a blocker for
2.18.0? I have https://issues.apache.org/jira/browse/BEAM-8976 to track
that.

On Mon, Dec 16, 2019 at 5:49 PM Pablo Estrada  wrote:

> Hi all,
> So there are two places where we log:
> 1. At pipeline construction.
> 2. At worker startup, to execute user code in workers.
>
> The workers have always set up their logging handlers properly, but
> pipeline construction setup is up to the user.
>
> If the user doesn't set it up, we could have a default configuration - and
> I propose doing it when we create the Pipeline object. See my proposed fix:
> https://github.com/apache/beam/pull/10396 - @Robert Bradshaw
>  wdyt?
>
> If this keeps holding out, then I have a quickfix to make all l9ogging
> happen in the root logger for now:
> https://github.com/apache/beam/pull/10394
>
> Best
> -P.
>
> On Fri, Dec 13, 2019 at 7:45 PM Ahmet Altay  wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 1:08 PM Robert Bradshaw 
>> wrote:
>>
>>> The default behavior of Python logging is
>>>
>>> (1) Logging handlers may get added (usually in main or very close to it).
>>> (2) Logging goes to those handlers, or a default handler if none were
>>> added.
>>>
>>> With this proposal, we would have
>>>
>>> (0) A default handler gets added.
>>> (1) Logging handlers may get added (usually in main or very close to
>>> it) in addition to the default.
>>> (2) Logging goes to these handlers and the default.
>>>
>>> On Fri, Dec 13, 2019 at 12:46 PM Pablo Estrada 
>>> wrote:
>>> >
>>> > I looked at the documentation for basicConfig:
>>> https://docs.python.org/3/library/logging.html#logging.basicConfig
>>> >
>>> > Specifically, the following line:
>>> >
>>> > > This function does nothing if the root logger already has handlers
>>> configured, unless the keyword argument force is set to True.
>>> >
>>> > That would mean that anyone can override the handling later on - which
>>> the workers do?
>>> > Best
>>> > -P.
>>> >
>>> > On Fri, Dec 13, 2019 at 10:55 AM Robert Bradshaw 
>>> wrote:
>>> >>
>>> >> Thanks for looking into this.
>>> >>
>>> >> I'm not sure unconditionally calling logging.basicConfig() on module
>>> >> import is the correct solution--this prevents modules that wish to set
>>> >> up handlers in place of the default handler from being able to do so.
>>> >> (This is why logging.basicConfig is lazily done at the first logging
>>> >> statement for the root logger, rather than earlier.)
>>> >>
>>> >> On Thu, Dec 12, 2019 at 4:34 PM Pablo Estrada 
>>> wrote:
>>> >> >
>>> >> > Hello all,
>>> >> > It has been pointed out to me by Chad, and also by others, that my
>>> logging changes have caused logs to start getting lost.
>>>
>>
>> Does this include losing user logs? Is there a JIRA, and should we fix it
>> in Beam 2.18 branch?
>>
>>
>>> >> >
>>> >> > It seems that by never logging on the root logger, initialization
>>> for a root handler is skipped; and that's what causes the failures.
>>> >> >
>>> >> > I will work on a fix for this. I am thinking of providing a very
>>> simple apache_beam.utils.get_logger function that does something like this:
>>> >> >
>>> >> > def get_logger(name):
>>> >> >   logging.basicConfig()
>>> >> >   return logging.getLogger(name)
>>> >> >
>>> >> > And specific paths that need special handling of the logs should
>>> override this config by adding their own handlers (e.g. sdk_worker,
>>> fn_api_runner, etc).
>>> >> >
>>> >> > I hope I can have a fix for this by tomorrow.
>>> >> > Best
>>> >> > -P.
>>>
>>

Re: Root logger configuration

[Pablo Estrada]

Hi all,
So there are two places where we log:
1. At pipeline construction.
2. At worker startup, to execute user code in workers.

The workers have always set up their logging handlers properly, but
pipeline construction setup is up to the user.

If the user doesn't set it up, we could have a default configuration - and
I propose doing it when we create the Pipeline object. See my proposed fix:
https://github.com/apache/beam/pull/10396 - @Robert Bradshaw
 wdyt?

If this keeps holding out, then I have a quickfix to make all l9ogging
happen in the root logger for now: https://github.com/apache/beam/pull/10394

Best
-P.

On Fri, Dec 13, 2019 at 7:45 PM Ahmet Altay  wrote:

>
>
> On Fri, Dec 13, 2019 at 1:08 PM Robert Bradshaw 
> wrote:
>
>> The default behavior of Python logging is
>>
>> (1) Logging handlers may get added (usually in main or very close to it).
>> (2) Logging goes to those handlers, or a default handler if none were
>> added.
>>
>> With this proposal, we would have
>>
>> (0) A default handler gets added.
>> (1) Logging handlers may get added (usually in main or very close to
>> it) in addition to the default.
>> (2) Logging goes to these handlers and the default.
>>
>> On Fri, Dec 13, 2019 at 12:46 PM Pablo Estrada 
>> wrote:
>> >
>> > I looked at the documentation for basicConfig:
>> https://docs.python.org/3/library/logging.html#logging.basicConfig
>> >
>> > Specifically, the following line:
>> >
>> > > This function does nothing if the root logger already has handlers
>> configured, unless the keyword argument force is set to True.
>> >
>> > That would mean that anyone can override the handling later on - which
>> the workers do?
>> > Best
>> > -P.
>> >
>> > On Fri, Dec 13, 2019 at 10:55 AM Robert Bradshaw 
>> wrote:
>> >>
>> >> Thanks for looking into this.
>> >>
>> >> I'm not sure unconditionally calling logging.basicConfig() on module
>> >> import is the correct solution--this prevents modules that wish to set
>> >> up handlers in place of the default handler from being able to do so.
>> >> (This is why logging.basicConfig is lazily done at the first logging
>> >> statement for the root logger, rather than earlier.)
>> >>
>> >> On Thu, Dec 12, 2019 at 4:34 PM Pablo Estrada 
>> wrote:
>> >> >
>> >> > Hello all,
>> >> > It has been pointed out to me by Chad, and also by others, that my
>> logging changes have caused logs to start getting lost.
>>
>
> Does this include losing user logs? Is there a JIRA, and should we fix it
> in Beam 2.18 branch?
>
>
>> >> >
>> >> > It seems that by never logging on the root logger, initialization
>> for a root handler is skipped; and that's what causes the failures.
>> >> >
>> >> > I will work on a fix for this. I am thinking of providing a very
>> simple apache_beam.utils.get_logger function that does something like this:
>> >> >
>> >> > def get_logger(name):
>> >> >   logging.basicConfig()
>> >> >   return logging.getLogger(name)
>> >> >
>> >> > And specific paths that need special handling of the logs should
>> override this config by adding their own handlers (e.g. sdk_worker,
>> fn_api_runner, etc).
>> >> >
>> >> > I hope I can have a fix for this by tomorrow.
>> >> > Best
>> >> > -P.
>>
>

Re: Please comment on draft comms strategy by Oct 16

[Pablo Estrada]

Hi Maria,
thanks for putting this together. It's large, so a bit hard to follow - but
that's probably just an indication of the complexity of Beam's
communication channels.
FWIW, I found that reading from the top down was useful (or rather, from
the top, backwards from the arrows).

It is an interesting logical map. I am curious to see what we can derive
from it : )

My comments:
- All of the factors that contribute to project transparency, when put
together, add up to increased use of Beam, but I feel like 'increased
knowledge of how to use beam' is the single largest contributor to that. Is
'knowing how to use' completely captured by transparency? (I can try to
rephrase what I mean...)
- I'm sure you've considered this, as you've received the feedback; but not
all of these channels are 'owned' by Beam. Some of these are 'independently
organized'. It may help to mark them as such.
- From the Artifacts section, Blog appears twice, while other artifacts
appear only once with multiple arrows pointing at them (e.g. tech talks).
Maybe this is on purpose, but just checking.

Thanks!
-P.

On Fri, Dec 6, 2019 at 5:12 PM María Cruz  wrote:

> Hi everyone,
> sorry for the tardiness in responding to this, and thank you to everyone
> who shared comments.
> I have adjusted the initial graphic, and taken a step further to develop
> the Apache Beam Communications Logic Model. This type of visualization is a
> hypothesized description of the chain of causes and effects leading to an
> outcome of interest [1]. The goal of making this graphic is to identify how
> Apache Beam's channels and content work towards project goals.
>
> The logic model graphic is attached and has also been uploaded [2] to the
> repo I've been working on. I also added it to comms-strategy-DRAFT.md [3].
> If you have any questions or comments about this graphic, please add them
> here [4].
>
> Step 3 in this process includes describing areas where we can be more
> strategic about the content we produce for Apache Beam. I would like to
> deliver this by December 17.
>
> Looking forward to your comments and feedback!
>
> Thanks,
>
> María
>
>
> [1] https://en.wikipedia.org/wiki/Logic_model
> [2] https://github.com/macruzbar/beam/blob/master/comms-logic-model.svg
> [3]
> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
> [4] https://github.com/macruzbar/beam/issues/4
>
> On Wed, Oct 9, 2019 at 7:09 PM Thomas Weise  wrote:
>
>> It probably makes sense to separate official project channels from
>> external ones like Beam Summit and meetups. Beam Summit is about Beam, but
>> it is "third party" and not under the project umbrella. Operation of the
>> youtube channel might also need clarification.
>>
>>
>> On Wed, Oct 9, 2019 at 4:35 PM Robert Bradshaw 
>> wrote:
>>
>>> Probably worth mentioning Slack and StackOverflow as well.
>>>
>>> On Wed, Oct 9, 2019 at 3:59 PM María Cruz  wrote:
>>> >
>>> > Hi all,
>>> > sorry for multiple messages. I realized after sending the first email
>>> that a new thread with a different subject was probably more efficient.
>>> >
>>> > I created a communication strategy draft. To start, I did a map of
>>> Beam channels and content, and I have some questions for you:
>>> https://github.com/macruzbar/beam/blob/master/Communication-strategy-DRAFT.md
>>> >
>>> > In order to create these files, I forked the repo. Once this looks
>>> good, and if everyone agrees, we can merge the changes to apache/beam.
>>> >
>>> > I didn't assign reviewers for this file because I don't know if there
>>> is someone who usually looks at these kinds of documents. So everyone:
>>> please feel free to pitch in! I will give this a week for comments.
>>> >
>>> > Looking forward to your comments!
>>> >
>>> > María
>>>
>>

Re: Testing Apache Beam with JDK 14 EA builds

[Kenneth Knowles]

Hi Rory,

Here at Beam we are still in a major long-term push to support Java 11 for
pipeline authoring and JRE 11 for execution. Many subtasks are filed under
https://issues.apache.org/jira/browse/BEAM-2530 for this.

Since you are working with so many Apache projects, can you share
information or contribute tweaks or alternative build scripts that will do
the testing you are describing?

Kenn

On Fri, Dec 13, 2019 at 1:44 AM Rory O'Donnell 
wrote:

>
> Hi,
> I work on OpenJDK at Oracle and try to encourage popular open source
> projects to test their releases on latest
> OpenJDK Early Access builds (i.e. JDK 14 -ea, atm), by providing them with
> regular information [0] describing
> new builds, their features, and making sure that their bug reports and
> feedback land [1] in the right hands.
>
> We don't expect projects to test every build, it's entirely up to you.
> We're already collaborating with developers
> of Apache Ant, Apache Maven, Apache Lucene, Apache Tomcat and other
> similar projects, and would love to be
> able to add Apache Beam to our list [2].
>
> Rgds,Rory
> [0] Example e-mail:
> https://mail.openjdk.java.net/pipermail/quality-discuss/2019-December/000908.html
> [1]
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+September+2019
> [2] https://wiki.openjdk.java.net/display/quality/Quality+Outreach
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

Re: [Proposal] Slowly Changing Dimensions and Distributed Map Side Inputs (in Dataflow)

[Kenneth Knowles]

I want to highlight that this design works for definitely more runners than
just Dataflow. I see two pieces of it that I want to bring onto the thread:

1. A new kind of "unbounded source" which is a periodic refresh of a
bounded source, and use that as a side input. Each main input element has a
window that maps to a specific refresh of the side input.
2. Distributed map side inputs: supporting very large lookup tables, but
with consistency challenges. Even the part about "windmill API" probably
applies to other runners

So I hope the title and "Objective" section do not cause people to stop
reading.

Kenn

On Mon, Dec 16, 2019 at 11:36 AM Mikhail Gryzykhin 
wrote:

> +some people explicitly
>
> Can you please check on the doc and comment if it looks fine?
>
> Thank you,
> --Mikhail
>
> On Tue, Dec 10, 2019 at 1:43 PM Mikhail Gryzykhin 
> wrote:
>
>> "Good news, everyone-"
>> ―Farnsworth
>>
>> Hi everyone,
>>
>> Recently, I was looking into relaxing limitations on side inputs in
>> Dataflow runner. As part of it, I came up with design proposal for
>> standardizing slowly changing dimensions use case in Beam and relevant
>> changes to add support for distributed map side inputs.
>>
>> Please review and comment on design doc.
>> 
>>  [1]
>>
>> Thank you,
>> Mikhail.
>>
>> -
>>
>> [1]
>> https://docs.google.com/document/d/1LDY_CtsOJ8Y_zNv1QtkP6AGFrtzkj1q5EW_gSChOIvg
>>
>>

Re: [VOTE] Beam's Mascot will be the Firefly (Lampyridae)

[Chamikara Jayalath]

+1 (non-binding)

On Mon, Dec 16, 2019 at 1:12 PM Mark Liu  wrote:

> +1
>
> On Mon, Dec 16, 2019 at 11:31 AM Daniel Oliveira 
> wrote:
>
>> +1 (non-binding)
>>
>> On Sat, Dec 14, 2019 at 5:24 PM Kyle Weaver  wrote:
>>
>>> +1 (non-binding)
>>>
>>> On Sat, Dec 14, 2019 at 3:10 AM Jan Lukavský  wrote:
>>>
 +1 (non-binding)
 On 12/13/19 7:22 PM, Pablo Estrada wrote:

 +1 (binding)

 On Fri, Dec 13, 2019 at 8:47 AM Maximilian Michels 
 wrote:

> +1 (binding)
>
> On 13.12.19 17:10, Jeff Klukas wrote:
> > +1 (non-binding)
> >
> > On Thu, Dec 12, 2019 at 11:58 PM Kenneth Knowles  > > wrote:
> >
> > Please vote on the proposal for Beam's mascot to be the Firefly.
> > This encompasses the Lampyridae family of insects, without
> > specifying a genus or species.
> >
> > [ ] +1, Approve Firefly being the mascot
> > [ ] -1, Disapprove Firefly being the mascot
> >
> > The vote will be open for at least 72 hours excluding weekends.
> It
> > is adopted by at least 3 PMC +1 approval votes, with no PMC -1
> > disapproval votes*. Non-PMC votes are still encouraged.
> >
> > PMC voters, please help by indicating your vote as "(binding)"
> >
> > Kenn
> >
> > *I have chosen this format for this vote, even though Beam uses
> > simple majority as a rule, because I want any PMC member to be
> able
> > to veto based on concerns about overlap or trademark.
> >
>

Re: [VOTE] Beam's Mascot will be the Firefly (Lampyridae)

[Mark Liu]

+1

On Mon, Dec 16, 2019 at 11:31 AM Daniel Oliveira 
wrote:

> +1 (non-binding)
>
> On Sat, Dec 14, 2019 at 5:24 PM Kyle Weaver  wrote:
>
>> +1 (non-binding)
>>
>> On Sat, Dec 14, 2019 at 3:10 AM Jan Lukavský  wrote:
>>
>>> +1 (non-binding)
>>> On 12/13/19 7:22 PM, Pablo Estrada wrote:
>>>
>>> +1 (binding)
>>>
>>> On Fri, Dec 13, 2019 at 8:47 AM Maximilian Michels 
>>> wrote:
>>>
 +1 (binding)

 On 13.12.19 17:10, Jeff Klukas wrote:
 > +1 (non-binding)
 >
 > On Thu, Dec 12, 2019 at 11:58 PM Kenneth Knowles >>> > > wrote:
 >
 > Please vote on the proposal for Beam's mascot to be the Firefly.
 > This encompasses the Lampyridae family of insects, without
 > specifying a genus or species.
 >
 > [ ] +1, Approve Firefly being the mascot
 > [ ] -1, Disapprove Firefly being the mascot
 >
 > The vote will be open for at least 72 hours excluding weekends. It
 > is adopted by at least 3 PMC +1 approval votes, with no PMC -1
 > disapproval votes*. Non-PMC votes are still encouraged.
 >
 > PMC voters, please help by indicating your vote as "(binding)"
 >
 > Kenn
 >
 > *I have chosen this format for this vote, even though Beam uses
 > simple majority as a rule, because I want any PMC member to be
 able
 > to veto based on concerns about overlap or trademark.
 >

>>>

Re: [DISCUSS] BIP reloaded

[Robert Bradshaw]

Additional process is a two-edged sword: it can help move stuff
forward, to the correct decision, but it can also add significant
overhead.

I think there are many proposals for which the existing processes of
deriving consensus (over email, possibly followed by a formal vote or
lazy consensus) are sufficient. However, sometimes they're not.
Specifically, for long-term roadmaps, it would be useful to have them
in a standard place that can be tracked and understood (I don't think
we've been able to use JIRA effectively for this here). I also think
there are some proposals that reach a certain level of complexity that
trying to address them by occasionally responding to email threads as
they come up is insufficient. For these latter, I think there is a
need for commitment for a group of people in the community to commit
to clearly defining and driving a solution to the problem via a more
formal process. Often the one making the proposal has sufficient
motivation, but sometimes what lacks is be (non-sporadic) investment
by those trying to understand, evaluate, and incorporate the proposal.

So I'm (strongly) +1 for exploring a more formal process, but -1 on
requiring it.

On Sun, Dec 15, 2019 at 1:07 AM Jan Lukavský  wrote:
>
> Hi,
>
> thanks for reactions so far. I agree that there are many questions that have 
> to be clarified. I'd propose to split this into two parts:
>
>  a) first reach a consensus that we want this process in the first place
>
>  b) after that, we need to clarify all the details - that will probably be 
> somewhat iterative procedure
>
> I'm not sure if there is something more we need to clarify before we can cast 
> a vote on (a).
>
> Thoughts?
>
>  Jan
>
> On 12/10/19 3:46 PM, Łukasz Gajowy wrote:
>
> +1 for formalizing the process, enhancing it and documenting clearly.
>
> I noticed that Apache Airflow has a cool way of both creating AIPs and 
> keeping track of all of them. There is a "Create new AIP" button on their 
> Confluence. This way, no AIP gets lost and all are kept in one place. Please 
> keep in mind that this is also the problem we want to solve in Beam and try 
> to keep track of all the documents we have so far*. It's certainly good to 
> solve that problem too, if possible.
>
> Also the AIP structure is something that I find nice - There's place for all 
> additional resources, JIRAs, discussion in comments and state of the 
> proposal. Even if we don't choose to use Confluence, we definitely could use 
> a similar template with all that information for our google docs proposals or 
> any other tool we stick to.
>
> Thanks!
>
> *thank you, Ismael and Alexey, for all the reminders under the proposals to 
> add them to Confluence list! :)
>
> wt., 10 gru 2019 o 13:29 jincheng sun  napisał(a):
>>
>> Thanks for bring up this discussion Jan!
>>
>> +1 for cearly define BIP for beam.
>>
>> And I think would be nice to initialize a concept document for BIP. Just a 
>> reminder: the document may contains:
>>
>> - How many kinds of improvement in beam.
>> - What kind of improvement should to create a BIP.
>> - What should be included in a BIP.
>> - Who can create the BIP.
>> - Who can participate in the discussion of BIP and who can vote for BIP.
>> - What are the possible limitations of BiP, such as whether it is necessary 
>> to complete the dev of BIP  in one release.
>> - How to track a BIP.
>>
>> Here is a question: I found out a policy[1] in beam, but only contains the 
>> poilcy of release , my question is does beam have something called Bylaws? 
>> Similar as Flink[1].
>>
>> Anyway, I like your proposals Jan :)
>>
>> Best,
>> Jincheng
>> [1] https://beam.apache.org/community/policies/
>> [2] 
>> https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws#FlinkBylaws-Approvals
>>
>>
>> David Morávek  于2019年12月10日周二 下午2:33写道：
>>>
>>> Hi Jan,
>>>
>>> I think this is more pretty much what we currently do, just a little bit 
>>> more transparent for the community. If the process is standardized, it can 
>>> open doors for bigger contributions from people not familiar with the 
>>> process. Also it's way easier to track progress of BIPs, than documents 
>>> linked from the mailing list.
>>>
>>> Big +1 ;)
>>>
>>> D.
>>>
>>> On Sun, Dec 8, 2019 at 12:42 PM Jan Lukavský  wrote:

 Hi,

 I'd like to revive a discussion that was taken some year and a half ago
 [1], which included a concept of "BIP" (Beam Improvement Proposal) - an
 equivalent of "FLIP" (flink), "KIP" (kafka), "SPIP" (spark), and so on.

 The discussion then ended without any (public) conclusion, so I'd like
 to pick up from there. There were questions related to:

   a) how does the concept of BIP differ from simple plain JIRA?

   b) what does it bring to the community?

 I'd like to outline my point of view on both of these aspects (they are
 related).

 BIP differs from JIRA by definition of a process:

 BIP -> vote -> 

Re: BEAM-8865: Code Review Wanted for a Javadoc update

[Tomo Suzuki]

Thank you, Pablo and Chamikara.

On Mon, Dec 16, 2019 at 12:49 PM Tomo Suzuki  wrote:
>
> Hi Beam developers,
>
> Can somebody review/merge this javadoc update? The example code there
> was not compiling.
> https://github.com/apache/beam/pull/10256 "Updating Javadoc of FileIO example"
>
> The original author of the javadoc (jkff) wrote my proposal is good.
>
> --
> Regards,
> Tomo



-- 
Regards,
Tomo

Re: [VOTE] Beam's Mascot will be the Firefly (Lampyridae)

[Daniel Oliveira]

+1 (non-binding)

On Sat, Dec 14, 2019 at 5:24 PM Kyle Weaver  wrote:

> +1 (non-binding)
>
> On Sat, Dec 14, 2019 at 3:10 AM Jan Lukavský  wrote:
>
>> +1 (non-binding)
>> On 12/13/19 7:22 PM, Pablo Estrada wrote:
>>
>> +1 (binding)
>>
>> On Fri, Dec 13, 2019 at 8:47 AM Maximilian Michels 
>> wrote:
>>
>>> +1 (binding)
>>>
>>> On 13.12.19 17:10, Jeff Klukas wrote:
>>> > +1 (non-binding)
>>> >
>>> > On Thu, Dec 12, 2019 at 11:58 PM Kenneth Knowles >> > > wrote:
>>> >
>>> > Please vote on the proposal for Beam's mascot to be the Firefly.
>>> > This encompasses the Lampyridae family of insects, without
>>> > specifying a genus or species.
>>> >
>>> > [ ] +1, Approve Firefly being the mascot
>>> > [ ] -1, Disapprove Firefly being the mascot
>>> >
>>> > The vote will be open for at least 72 hours excluding weekends. It
>>> > is adopted by at least 3 PMC +1 approval votes, with no PMC -1
>>> > disapproval votes*. Non-PMC votes are still encouraged.
>>> >
>>> > PMC voters, please help by indicating your vote as "(binding)"
>>> >
>>> > Kenn
>>> >
>>> > *I have chosen this format for this vote, even though Beam uses
>>> > simple majority as a rule, because I want any PMC member to be able
>>> > to veto based on concerns about overlap or trademark.
>>> >
>>>
>>

Re: [RELEASE] Tracking 2.18

[Udi Meiri]

The remaining 4 open blockers all have recently merged cherrypicks (at
least 1 blocker is waiting on verification since it's a release process
issue).

Will attempt an RC today.

On Thu, Dec 12, 2019 at 5:33 PM Udi Meiri  wrote:

> Also marked 3 Jiras from these cherrypicks as blockers .
> Current open blocker count: 7
> .
>
> On Thu, Dec 12, 2019 at 5:21 PM Udi Meiri  wrote:
>
>> Just merged 6 PRs. :)
>>
>> On Thu, Dec 12, 2019 at 4:52 PM Udi Meiri  wrote:
>>
>>> Update: I'm accepting cherrypicks with failing tests if the
>>> corresponding PR have passed them on master.
>>>
>>> I recall (without proof) that in the past, even with released worker
>>> containers for the in-process release, that ITs against the release branch
>>> still fail.
>>>
>>> On Tue, Dec 10, 2019 at 10:58 AM Udi Meiri  wrote:
>>>
 Re: cherrypicks on top of the release-2.18.0 branch
 The precommit tests are failing most likely due to some integration
 tests (wordcount, etc.) that are expecting the new 2.18 worker on Dataflow.
 I'm working on building an initial version of that worker so that the
 tests may pass.

 On Thu, Dec 5, 2019 at 4:39 PM Robert Bradshaw 
 wrote:

> Yeah, so I saw...
>
> On Thu, Dec 5, 2019 at 4:31 PM Udi Meiri  wrote:
> >
> > Sorry Robert the release was already cut yesterday.
> >
> >
> >
> > On Thu, Dec 5, 2019 at 8:37 AM Ismaël Mejía 
> wrote:
> >>
> >> Colm, I just merged your PR and cherry picked it into 2.18.0
> >> https://github.com/apache/beam/pull/10296
> >>
> >> On Thu, Dec 5, 2019 at 10:54 AM jincheng sun <
> sunjincheng...@gmail.com> wrote:
> >>>
> >>> Thanks for the Tracking Udi!
> >>>
> >>> I have updated the status of some release blockers issues as
> follows:
> >>>
> >>> - BEAM-8733 closed
> >>> - BEAM-8620 reset the fix version to 2.19
> >>> - BEAM-8618 reset the fix version to 2.19
> >>>
> >>> Best,
> >>> Jincheng
> >>>
> >>> Colm O hEigeartaigh  于2019年12月5日周四 下午5:38写道：
> 
>  Could we get this one in 2.18 as well?
> https://issues.apache.org/jira/browse/BEAM-8861
> 
>  Colm.
> 
>  On Wed, Dec 4, 2019 at 8:02 PM Udi Meiri 
> wrote:
> >
> > Following the release calendar, I plan on cutting the 2.18
> release branch today.
> >
> > There are currently 8 release blockers.
> >
>



smime.p7s
Description: S/MIME Cryptographic Signature

BEAM-8865: Code Review Wanted for a Javadoc update

[Tomo Suzuki]

Hi Beam developers,

Can somebody review/merge this javadoc update? The example code there
was not compiling.
https://github.com/apache/beam/pull/10256 "Updating Javadoc of FileIO example"

The original author of the javadoc (jkff) wrote my proposal is good.

-- 
Regards,
Tomo

Beam Dependency Check Report (2019-12-16)

[Apache Jenkins Server]

ERROR: File 'src/build/dependencyUpdates/beam-dependency-check-report.html' does not exist