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é <j...@nanthrax.net> 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#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 >
