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#vulnerability-handling_ > > [2] https://lists.apache.org/list.html?dev@beam.apache.org:lte=40M:2.1.1 > > * > > [3] Example text for the contributor guideline: > > > What requires a critical point release? > > * > > A data loss bug > > * > > A data corruption bug > > * > > A processing correctness bug > > * > > For security vulnerabilities, please follow > https://apache.org/security/committers.html#vulnerability-handling . > > > What do we do a critical point release on? > > Our first priority is to stop the bleeding. We ought to prioritize a > point release for the latest Beam version, based on the release branch, > that cherrypicks only the intended fix. > > * > > We've done it before! Remember 2.1.1 > <https://lists.apache.org/list.html?dev@beam.apache.org:lte=40M:2.1.1>? > > o > > Since this is a critical release, we can relax our usual 72 hour > voting policy. It worked well for 2.1.1, we should make it > repeatable: Propose, have PMC folks do due diligence on the > request, and sign off. Since this is critical, we may want to > have more than one person working on the release. > > * > > Once we get it out, the community can discuss which previous > releases would benefit from a potential point release. > > > Who proposes a critical point release? > > Any member of the community. 3 PMC +1 votes are sufficient to get the > process rolling. > > * > > > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
