Thank you Rafael. I think it is a good idea to include our commitment, including concrete steps on our website. This would make it easier for enterprise users to choose Beam. Even though this is already partially Apache policy and there is precedence in our project with 2.1.1 release; increasing the visibility for users would be a positive addition.
I would suggest changing the link in [2] to ( https://lists.apache.org/list.html?dev@beam.apache.org:gte=1d:2.1.1) so that link does not expire after some time. Ahmet On Thu, Jun 14, 2018 at 1:33 PM, Rafael Fernandez <rfern...@google.com> 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 > <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 > <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>? - > 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.* > > > >
