[ 
https://issues.apache.org/jira/browse/BEAM-10308?focusedWorklogId=458998&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-458998
 ]

ASF GitHub Bot logged work on BEAM-10308:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 14/Jul/20 22:20
            Start Date: 14/Jul/20 22:20
    Worklog Time Spent: 10m 
      Work Description: tvalentyn commented on pull request #12196:
URL: https://github.com/apache/beam/pull/12196#issuecomment-658441886


   > To be honest I think this situation is somewhat of a gap in the guidance 
there. There may be cases where its worth delaying a release for a severe 
bugfix even if it's a longstanding issue and not a regression, and that's not 
addressed in our release guide. We could draw a line somewhere: e.g. maybe data 
loss/incorrect result bugs can delay, crashes can not?
   
   In my opinion for these situations releasing a patch version (2.23.1) 
following a release (2.23.0), would be most preferable to users: new 
features/bugfixes already in RC1 will become available earlier, and cherry-pick 
worthy long-standing issues that were recently fixed and easy to back-port 
won't have to wait 6 weeks to be released. If anything goes wrong (cherry-pick 
conflict, new bug), 2.23.0 will still stay around.
   For example, for this particular change I think we would only need to update 
Python SDK artifacts. We can propose to make 2.23.1 with this fix right after 
2.23.0, without waiting for 2.24.0, if you think it's urgent. Thoughts 
@TheNeuralBit @robertwb ?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 458998)
    Time Spent: 6h 10m  (was: 6h)

> Component id assignement is not consistent across PipelineContext instances
> ---------------------------------------------------------------------------
>
>                 Key: BEAM-10308
>                 URL: https://issues.apache.org/jira/browse/BEAM-10308
>             Project: Beam
>          Issue Type: Bug
>          Components: cross-language, sdk-py-core
>            Reporter: Brian Hulette
>            Assignee: Brian Hulette
>            Priority: P1
>             Fix For: 2.24.0
>
>          Time Spent: 6h 10m
>  Remaining Estimate: 0h
>
> The "unique ref" ids used in PipelineContext are generated on the fly, which 
> can cause us to get a different id for the same component in different 
> contexts.
> This becomes a problem when ExternalTransform is used, because it creates its 
> own pipeline context for expansion. So its possible the component ids in the 
> expansion request will actually refer to an entirely different component when 
> the pipeline is finally assembled for execution.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to