Re: [VOTE] Apache Beam, version 2.5.0, release candidate #2

2018-06-17 Thread Jean-Baptiste Onofré 
s/add/had/g

On 17/06/2018 19:32, Pablo Estrada wrote:
> Going to https://github.com/apache/beam/tree/v2.5.0-RC2 gives me a 404
> error. May need to push the label?
> Best
> -P.
> 
> On Sun, Jun 17, 2018 at 1:15 AM Romain Manni-Bucau
> mailto:rmannibu...@gmail.com>> wrote:
> 
> +1 (same tests than for take #1)
> 
> Le dim. 17 juin 2018 07:18, Jean-Baptiste Onofré  > a écrit :
> 
> Hi everyone,
> 
> Please review and vote on the release candidate #2 for the version
> 2.5.0, as follows:
> 
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific
> comments)
> 
> NB: this is the first release using Gradle, so don't be too
> harsh ;) A
> PR about the release guide will follow thanks to this release.
> 
> The complete staging area is available for your review, which
> includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to
> dist.apache.org 
> [2], which is signed with the key with fingerprint C8282E76 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.5.0-RC2" [5],
> * website pull request listing the release and publishing the API
> reference manual [6].
> * Java artifacts were built with Gradle 4.7 (wrapper) and
> OpenJDK/Oracle
> JDK 1.8.0_172 (Oracle Corporation 25.172-b11).
> * Python artifacts are deployed along with the source release to the
> dist.apache.org  [2].
> 
> The vote will be open for at least 72 hours. It is adopted by
> majority
> approval, with at least 3 PMC affirmative votes.
> 
> Thanks,
> JB
> 
> [1]
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12342847
> [2] https://dist.apache.org/repos/dist/dev/beam/2.5.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4]
> https://repository.apache.org/content/repositories/orgapachebeam-1043/
> [5] https://github.com/apache/beam/tree/v2.5.0-RC2
> [6] https://github.com/apache/beam-site/pull/463
> 
> -- 
> Got feedback? go/pabloem-feedback

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Apache Beam, version 2.5.0, release candidate #2

2018-06-17 Thread Jean-Baptiste Onofré 
Done,

by the way, I add to launch a gitbox resync for both beam and beam-site
repos.

Regards
JB

On 17/06/2018 19:32, Pablo Estrada wrote:
> Going to https://github.com/apache/beam/tree/v2.5.0-RC2 gives me a 404
> error. May need to push the label?
> Best
> -P.
> 
> On Sun, Jun 17, 2018 at 1:15 AM Romain Manni-Bucau
> mailto:rmannibu...@gmail.com>> wrote:
> 
> +1 (same tests than for take #1)
> 
> Le dim. 17 juin 2018 07:18, Jean-Baptiste Onofré  > a écrit :
> 
> Hi everyone,
> 
> Please review and vote on the release candidate #2 for the version
> 2.5.0, as follows:
> 
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific
> comments)
> 
> NB: this is the first release using Gradle, so don't be too
> harsh ;) A
> PR about the release guide will follow thanks to this release.
> 
> The complete staging area is available for your review, which
> includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to
> dist.apache.org 
> [2], which is signed with the key with fingerprint C8282E76 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.5.0-RC2" [5],
> * website pull request listing the release and publishing the API
> reference manual [6].
> * Java artifacts were built with Gradle 4.7 (wrapper) and
> OpenJDK/Oracle
> JDK 1.8.0_172 (Oracle Corporation 25.172-b11).
> * Python artifacts are deployed along with the source release to the
> dist.apache.org  [2].
> 
> The vote will be open for at least 72 hours. It is adopted by
> majority
> approval, with at least 3 PMC affirmative votes.
> 
> Thanks,
> JB
> 
> [1]
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12342847
> [2] https://dist.apache.org/repos/dist/dev/beam/2.5.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4]
> https://repository.apache.org/content/repositories/orgapachebeam-1043/
> [5] https://github.com/apache/beam/tree/v2.5.0-RC2
> [6] https://github.com/apache/beam-site/pull/463
> 
> -- 
> Got feedback? go/pabloem-feedback

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Apache Beam, version 2.5.0, release candidate #2

2018-06-17 Thread Yifan Zou 
+1
Python quick-start and mobile-gaming on core runners passed.

On Sun, Jun 17, 2018 at 10:32 AM Pablo Estrada  wrote:

> Going to https://github.com/apache/beam/tree/v2.5.0-RC2 gives me a 404
> error. May need to push the label?
> Best
> -P.
>
> On Sun, Jun 17, 2018 at 1:15 AM Romain Manni-Bucau 
> wrote:
>
>> +1 (same tests than for take #1)
>>
>> Le dim. 17 juin 2018 07:18, Jean-Baptiste Onofré  a
>> écrit :
>>
>>> Hi everyone,
>>>
>>> Please review and vote on the release candidate #2 for the version
>>> 2.5.0, as follows:
>>>
>>> [ ] +1, Approve the release
>>> [ ] -1, Do not approve the release (please provide specific comments)
>>>
>>> NB: this is the first release using Gradle, so don't be too harsh ;) A
>>> PR about the release guide will follow thanks to this release.
>>>
>>> The complete staging area is available for your review, which includes:
>>> * JIRA release notes [1],
>>> * the official Apache source release to be deployed to dist.apache.org
>>> [2], which is signed with the key with fingerprint C8282E76 [3],
>>> * all artifacts to be deployed to the Maven Central Repository [4],
>>> * source code tag "v2.5.0-RC2" [5],
>>> * website pull request listing the release and publishing the API
>>> reference manual [6].
>>> * Java artifacts were built with Gradle 4.7 (wrapper) and OpenJDK/Oracle
>>> JDK 1.8.0_172 (Oracle Corporation 25.172-b11).
>>> * Python artifacts are deployed along with the source release to the
>>> dist.apache.org [2].
>>>
>>> The vote will be open for at least 72 hours. It is adopted by majority
>>> approval, with at least 3 PMC affirmative votes.
>>>
>>> Thanks,
>>> JB
>>>
>>> [1]
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12342847
>>> [2] https://dist.apache.org/repos/dist/dev/beam/2.5.0/
>>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>>> [4]
>>> https://repository.apache.org/content/repositories/orgapachebeam-1043/
>>> [5] https://github.com/apache/beam/tree/v2.5.0-RC2
>>> [6] https://github.com/apache/beam-site/pull/463
>>>
>> --
> Got feedback? go/pabloem-feedback
> 
>

Re: [VOTE] Apache Beam, version 2.5.0, release candidate #2

2018-06-17 Thread Pablo Estrada 
Going to https://github.com/apache/beam/tree/v2.5.0-RC2 gives me a 404
error. May need to push the label?
Best
-P.

On Sun, Jun 17, 2018 at 1:15 AM Romain Manni-Bucau 
wrote:

> +1 (same tests than for take #1)
>
> Le dim. 17 juin 2018 07:18, Jean-Baptiste Onofré  a
> écrit :
>
>> Hi everyone,
>>
>> Please review and vote on the release candidate #2 for the version
>> 2.5.0, as follows:
>>
>> [ ] +1, Approve the release
>> [ ] -1, Do not approve the release (please provide specific comments)
>>
>> NB: this is the first release using Gradle, so don't be too harsh ;) A
>> PR about the release guide will follow thanks to this release.
>>
>> The complete staging area is available for your review, which includes:
>> * JIRA release notes [1],
>> * the official Apache source release to be deployed to dist.apache.org
>> [2], which is signed with the key with fingerprint C8282E76 [3],
>> * all artifacts to be deployed to the Maven Central Repository [4],
>> * source code tag "v2.5.0-RC2" [5],
>> * website pull request listing the release and publishing the API
>> reference manual [6].
>> * Java artifacts were built with Gradle 4.7 (wrapper) and OpenJDK/Oracle
>> JDK 1.8.0_172 (Oracle Corporation 25.172-b11).
>> * Python artifacts are deployed along with the source release to the
>> dist.apache.org [2].
>>
>> The vote will be open for at least 72 hours. It is adopted by majority
>> approval, with at least 3 PMC affirmative votes.
>>
>> Thanks,
>> JB
>>
>> [1]
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12342847
>> [2] https://dist.apache.org/repos/dist/dev/beam/2.5.0/
>> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
>> [4]
>> https://repository.apache.org/content/repositories/orgapachebeam-1043/
>> [5] https://github.com/apache/beam/tree/v2.5.0-RC2
>> [6] https://github.com/apache/beam-site/pull/463
>>
> --
Got feedback? go/pabloem-feedback

Re: [VOTE] Apache Beam, version 2.5.0, release candidate #2

2018-06-17 Thread Romain Manni-Bucau 
+1 (same tests than for take #1)

Le dim. 17 juin 2018 07:18, Jean-Baptiste Onofré  a écrit :

> Hi everyone,
>
> Please review and vote on the release candidate #2 for the version
> 2.5.0, as follows:
>
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> NB: this is the first release using Gradle, so don't be too harsh ;) A
> PR about the release guide will follow thanks to this release.
>
> The complete staging area is available for your review, which includes:
> * JIRA release notes [1],
> * the official Apache source release to be deployed to dist.apache.org
> [2], which is signed with the key with fingerprint C8282E76 [3],
> * all artifacts to be deployed to the Maven Central Repository [4],
> * source code tag "v2.5.0-RC2" [5],
> * website pull request listing the release and publishing the API
> reference manual [6].
> * Java artifacts were built with Gradle 4.7 (wrapper) and OpenJDK/Oracle
> JDK 1.8.0_172 (Oracle Corporation 25.172-b11).
> * Python artifacts are deployed along with the source release to the
> dist.apache.org [2].
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Thanks,
> JB
>
> [1]
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12342847
> [2] https://dist.apache.org/repos/dist/dev/beam/2.5.0/
> [3] https://dist.apache.org/repos/dist/release/beam/KEYS
> [4] https://repository.apache.org/content/repositories/orgapachebeam-1043/
> [5] https://github.com/apache/beam/tree/v2.5.0-RC2
> [6] https://github.com/apache/beam-site/pull/463
>

Re: [DISCUSS] Releasing Beam in the presence of emergencies

2018-06-17 Thread Romain Manni-Bucau 
Hi guys

If you take back this thread [1], then beam will only support two branches
and no others.

On the shortcut release cycle it is not really desired at apache and not
the normal process so the 3 days vote is required but not a blocker IMHO.
If really an issue the merge can be done quickly on master and you can
release on your own nexus in 1h. The side note for the asf release manager
here will be to emphase the diff to let people review it faster. Less
change there is, easier it is to vote.

My question on that process will be for dataflow guys wich often request a
few more days. Is it ok because dataflow doesnt use multiple versions or
does it need some work on that side to support a faster support of new beam
versions?

[1]
https://lists.apache.org/thread.html/1f6941f112d080de3633d11c574fb67bce5f6f81679ec3bdeaf807f0@


Le dim. 17 juin 2018 01:08, Ravi Prakash  a écrit :

> Hi Beam-devs!
>
> There is also the consideration of which releases to fix. I am familiar
> with Apache Hadoop and there may be a "stable", "beta" and "alpha" release.
> Usually security fixes are ported to one or more of those branches.
>
> Cheers
> Ravi
>
> On Sat, Jun 16, 2018 at 2:43 PM, Kenneth Knowles  wrote:
>
>> I like the idea of explicitly affirming our use of the ASF Vulnerability
>> Policy as well as listing other classes of bugs that are particularly
>> critical for a project like Beam. I think the most valuable thing is having
>> a clear and concise policy for users to understand at a glance. Then we can
>> have a verbose walkthrough for someone implementing the policy.
>>
>> Kenn
>>
>> On Sat, Jun 16, 2018 at 9:54 AM Chamikara Jayalath 
>> wrote:
>>
>>> While performing a patch release is the correct approach for a critical
>>> fixes I think there are still several points that we might want to discuss
>>> and formalize/document if needed.
>>>
>>> (1) What if there's an ongoing major/minor version release ?
>>> If think patch releases should be independent of any ongoing major/minor
>>> versions releases and should be handled by a separate release manager who
>>> can commit the the time to cut the release immediately.
>>>
>>> (2) What changes should go in ?
>>> Only the fix that addresses the critical issue should go into the patch
>>> release. Any other fixes should be held till the next minor version release.
>>>
>>> (3) What to do with the faulty release ?
>>> We should clearly document the issue with the faulty (non-patched)
>>> release in https://beam.apache.org/get-started/downloads/. This can be
>>> complemented by other announcements (to user list, twitter, for example)
>>> and runner specific solutions (rejecting jobs, warnings for running jobs).
>>>
>>> (4) Voting period and validation.
>>> We are performing the patch on top of an already released branch. So can
>>> we expedite the release validation and voting process ?
>>>
>>> I'm sure there are other points.
>>>
>>> Thanks,
>>> Cham
>>>
>>> On Thu, Jun 14, 2018 at 10:29 PM Jean-Baptiste Onofré 
>>> wrote:
>>>
 Hi Rafael,

 It's a good point but I don't see nothing more to do on our side: if a
 emergency issue is detected, then we have to address it and release a
 fix release (x.y.z where z is the specific release fixing the issue).
 The commitment is a best effort as in all community: if an emergency
 issue is detected, qualified and accepted, then we do our best to
 provide a fix and do the fix release.

 So, for me, it's already handled.

 By the way, just a quick reminder in term of release:

 - now that gradle release seems ok, we resume our release cycle every ~
 6 weeks
 - we can cut release anytime if required, especially to address
 emergency issues.

 Regards
 JB

 On 14/06/2018 22:33, Rafael Fernandez wrote:
 > Hi Beam devs,
 >
 > Emergencies can and will happen. As Apache Beam adoption continues to
 > grow, the user community will naturally expect the Beam developer
 > community to react to critical issues, such as security
 vulnerabilities
 > in our dependencies. I want to make sure the dev community is in
 > agreement that we follow the ASF Vulnerability Handling processes [1]
 > for such occurrences.
 >
 >
 > In addition, I'd like to discuss cases in which data correctness/loss
 > may warrant an expedited release (i.e., we did not wait 72 hours), as
 we
 > did in 2.1.1 [2].  Concretely:
 >
 >
 >  1.
 >
 > Do we need to add anything to our project website so the user
 > community knows how we react to such issues?
 >
 >  2.
 >
 > Should we have an entry in the contributor guide to address
 critical
 > point releases, so we eliminate any guesswork in the event of an
 > emergency? (Example text [3])
 >
 >
 > Thanks,
 >
 > r
 >
 >
 > [1]
 >
 > _https://apache.org/security/committers.html#