I agree with Ismaël, this process is generally working well. As an improvement we could document it somewhere.
One other area I think we can improve is, issues that are related to the release process. For example, at times we will have issues that require doing additional manual steps in the release process, we will file a JIRA and we tend to punt those JIRAs release after release as long as there is a manual work around. However, these issues add to the cost of cutting releases. I would propose prioritizing those issues that are identified during the release and about the release process itself. Ahmet On Wed, Sep 19, 2018 at 4:41 AM, Ismaël Mejía <[email protected]> wrote: > We have done this so far by letting the JIRA issues 'Open' with the > 'Fix version' corresponding to the upcoming release and we track the > progress between the branch cut and the first release candidate with > the assigned parties, the process has been the de-facto standard since > long time ago and has worked so far smoothly. More info here: > > https://beam.apache.org/contribute/release-guide/#triage-release-blocking- > issues-in-jira > > Is there something missing? or do you have other ideas maybe to > improve it in mind? > > On Wed, Sep 19, 2018 at 2:34 AM Connell O'Callaghan <[email protected]> > wrote: > > > > Hi All > > > > In order to allow successful and smooth deployment of the latest BEAM > releases, are the community OK that we track bugs blocking releases, with a > goal to resolve such bugs within a week? If there is general agreement (or > no major objections) on this we will edit the contributor page using > similar language to the "Stale pull requests" section -early next week. > > > > Thank you all, > > - Connell >
