Re: [DISCUSS] Portability representation of schemas

If we want to have a Pipeline level registry, we could add it to Components [1]. message Components { ... map logical_types; } And in FieldType reference the logical types by id: oneof field_type { AtomicType atomic_type; ArrayType array_type; ... string logical_type_id;// was

Re: [VOTE] Release 2.13.0, release candidate #2

Thanks Kenn, for identifying the issue. If no artifacts affected artifacts are published then we should be good. Let me know if we need to make any changes in 2.13.0 On Wed, Jun 5, 2019 at 10:53 AM Kenneth Knowles wrote: > Just discovered a potentially serious issue that was present during this

Re: Removing shading by default within BeamModulePlugin.groovy

I am able to pass several runners validates runner tests and the Java PostCommit. I also was able to publish a release into the staging repository[1] and compared the newly generated poms artifact-2.14.0-20190605.*-30.pom against the previously nightly snapshot of artifact-2.14.0-20190605.*-28

Re: [discuss] A tweak to the Python API for SDF?

I have no objections. +Ismaël Mejía who has familiarity and interest in Java SDF. On Wed, Jun 5, 2019 at 11:31 AM Brian Hulette wrote: > Just wanted to resurrect this to say that it seems appropriate to make the > same change in Java. All the same arguments apply there, and now there's > the

Re: [discuss] A tweak to the Python API for SDF?

Just wanted to resurrect this to say that it seems appropriate to make the same change in Java. All the same arguments apply there, and now there's the additional argument for maintaining symmetry with Python. I think BEAM-7250 should be changed to a ticket to actually implement this in Java

Re: [VOTE] Release 2.13.0, release candidate #2

Just discovered a potentially serious issue that was present during this RC: https://issues.apache.org/jira/browse/BEAM-7493. So far I have not discovered a truly user-facing impact, and example validation succeeded, but I wanted to alert the list. Summary: When rendering a published pom.xml the

Re: Help triaging Jira issues

Hi Kenneth, I already follow the issues@ mailing list pretty much daily. I'd like to help with triaging issues, especially ones related to the Python SDK since I'm most familiar with it. On Wed, Jun 5, 2019 at 10:26 PM Alex Van Boxel wrote: > Hey Kenneth, I help out. I'm planning to contribute

Re: Help triaging Jira issues

Hey Kenneth, I help out. I'm planning to contribute more on Beam and it seems to be ideal to keep up-to-date with the project. _/ _/ Alex Van Boxel On Wed, Jun 5, 2019 at 6:46 PM Kenneth Knowles wrote: > Hi all, > > I am requesting help in triaging incoming issues. I made a search here: >

Help triaging Jira issues

Hi all, I am requesting help in triaging incoming issues. I made a search here: https://issues.apache.org/jira/issues/?filter=12345682 I have a daily email subscription to this filter as a reminder, but rarely can really sit down to do

Re: Plan for dropping python 2 support

I agree with the sentiment on this thread. Our priority needs to be offering good python 3 support that we can comfortably recommend users to switch. Progress on that so far has been promising and I do anticipate that we will reach there in the near future. My proposal would be, once we reach to

Re: [VOTE] Release 2.13.0, release candidate #2

+1 and I think all of that can be covered with JIRA. Irrespective the release manager still needs to pay attention to the communication on the VOTE thread. On Wed, Jun 5, 2019 at 9:19 AM Ahmet Altay wrote: > Checking that JIRA link sounds reasonable as long as we can agree that it > is single

Re: [VOTE] Release 2.13.0, release candidate #2

Checking that JIRA link sounds reasonable as long as we can agree that it is single source of truth for cherry pick requests. I also agree with Cham, requests need to come with a reason. On Wed, Jun 5, 2019 at 7:38 AM Ismaël Mejía wrote: > I don't think we need anything fancier or marking even

Re: [VOTE] Release 2.13.0, release candidate #2

I don't think we need anything fancier or marking even as Blocker some of this stuff, would not be enough just to monitor that [1] has no issues? (of course if the interested party has not put the fix version to the current ongoing vote one this is a mistake). [1]

Re: [VOTE] Release 2.13.0, release candidate #2

On Tue, Jun 4, 2019 at 5:02 PM Ahmet Altay wrote: > I would suggest have a single way of tracking cherry pick request to an > RC. Currently we use emails on the RC thread, open PRs, and Jiras tagged > for the release. This is confusing the person doing the release while they > are juggling

Re: Plan for dropping python 2 support

We can support Python 2 for some time in 2020, but, we should target a date no later than 2020 to drop support. If we do plan to drop support for Python 2 in 2020, we should sign the Python 3 statement[1], declaring that we will "drop support for Python 2.7 no later than 2020". In addition to the

Re: [Discuss] Ideas for Apache Beam presence in social media

+1 What would be the mechanism to notify the PMC that there is something to review? On Tue, Jun 4, 2019 at 9:55 PM Kenneth Knowles wrote: > Bringing the PMC's conclusion back to this list, we are happy to start > with the following arrangement: > > - Doc/spreadsheet/etc readable by dev@ (aka

Re: Plan for dropping python 2 support

Until Python 3 support for Beam is officially out of beta and recommended, I don't think we can tell people to stop using Python 2. Given that 2020 is just over 6 months away, that seems a short transition time, so I would guess we'll have to continue supporting Python 2 sometime into 2020. A

Plan for dropping python 2 support

Python 2 won't be maintained after 2020 [1]. I was wondering what will be our (Beam) plan for this. Other projects [2] have started to alert users that support will be removed so maybe we should decide or policy for this too. [1] https://pythonclock.org/ [2]