This sounds reasonable to me. On Fri, Sep 28, 2018 at 5:39 PM, Connell O'Callaghan <[email protected]> wrote:
> Ismaël and Ahmet thank you both for your responses!!! > > Can the text on the site today - reproduced below - be enhanced with the > text in bold? Note I would not expect this new text to be in bold once > deployed to the site. > Triage release-blocking issues in JIRA > > There could be outstanding release-blocking issues, which should be > triaged before proceeding to build a release candidate. We track them by > assigning a specific Fix version field even before the issue resolved. > > The list of release-blocking issues is available at the version status > page > <https://issues.apache.org/jira/browse/BEAM/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel>. > Triage each unresolved issue with one of the following resolutions: > > - If the issue has been resolved and JIRA was not updated, resolve it > accordingly. > - If the issue has not been resolved and it is acceptable to defer > this until the next release, update the Fix Version field to the new > version you just created. Please consider discussing this with stakeholders > and the dev@ mailing list, as appropriate. > - If the issue has not been resolved and it is not acceptable to > release until it is fixed, the release cannot proceed. Instead, work with > the Beam community to resolve the issue. > > *If there is a bug found in the RC creation process/tools, those issues > should be considered high priority and fixed in 7 days. * > > This is to prevent a regression in the amount of time it takes to cut an > RC. > > On Fri, Sep 21, 2018 at 2:06 PM Ahmet Altay <[email protected]> wrote: > >> 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 >>> >> >>
