Hi Devs, James, we don't have to wait 2 weeks for the community to discuss the release, > because it is based on an already approved release
I agree. It's an already approved release with only 1 to 3 PRs going in. I will assist in enforcing that these releases don't have anything other than critical fixes. Do you agree with Aleks proposal here? With best regards, Avik. On Mon, Sep 19, 2022 at 10:14 PM Aleksandar Vidakovic < [email protected]> wrote: > Hi Avik and all, > > ... not sure anymore in which conversation I dropped this... so repeat it > here. Hotfix releases are very similar to normal releases (in terms of > steps) except: > > - we don't have to wait 2 weeks for the community to discuss the > release, because it is based on an already approved release > - ... and no revolutionary aka backwards compatibility breaking > changes are allowed > - a hotfix release should contain 1-3 ("3" is arbitrary, but sounds > good to me) pull requests > > Full list of current hotfix rules here: > https://fineract.apache.org/docs/current/#_maintenance_release_process > > The rest of the process (see > https://fineract.apache.org/docs/current/#_releases) would be exactly the > same. The voting process might be potentially the longest part, but if we > look back at past releases (4 or so) this usually takes only a couple > of hours (and that's only because we live in different timezones). A > release is approved by 3 PMC votes... can't remember that we had to use the > 72h period in recent years. > > Note: once a hotfix is out (let's 1.7.1) then it replaces the previous > minor release (1.7.0 in this example). Just to say: only the latest will be > available for download. > > My 2 cents. > > Cheers > > > On Mon, Sep 19, 2022 at 6:17 PM James Dailey <[email protected]> > wrote: > >> Hi Avik >> >> I'd like to check with other Apache projects to find out what they do for >> hot fixes. >> >> "A binding release vote of the PMC is the critical gating step in the >> release process. Without such a vote, the release is just a set of files >> prepared by an individual. After such a vote, it is a formal offering of >> the ASF, backed by the "full faith and credit" of the Foundation." >> https://infra.apache.org/release-publishing.html >> >> see also: >> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus >> >> There is no "timeout" based release. >> >> Then we get to the norms of this group. >> It feels important that the most active devs have the time to comment and >> review the changelog, even if they are not on the PMC. 72 hrs may not be >> enough. >> And, as I understand it, the two weeks time frame is a sort of *norm* >> within Apache to allow people to take the necessary careful steps - run >> regression tests(?) to ensure that the new release or hotfix is free from >> defects. >> >> So, to your proposal - I would agree that in some cases, like the >> hotfixes where we have some very active devs and everyone is essentially >> waiting for the two weeks to close, that this is not that useful. >> I do agree that we should have a faster process for an urgent hotfix as >> this is intended to fix something missed during the release process. >> >> Some other options? >> >> e.g. >> 5 PMC votes and 72 hrs >> 3 PMC votes and 6 days >> >> >> Thanks >> @[email protected] <[email protected]> >> >> >> >> On Mon, Sep 19, 2022 at 7:58 AM Avik Ganguly <[email protected]> wrote: >> >>> Hello Devs & Non-Devs, >>> >>> I would like your opinion on the below points for hot fix releases :- >>> >>> - Release discussion after cutting a branch (usually this thing is 2 >>> weeks open in mailing lists for feedback). Can we do something about this >>> to cut it down to as little time as possible? I would like to propose a >>> day >>> or 3 votes on whether the discussion is adequate for cutting a release. >>> - Release voting (usual rules, 3 PMC votes or 72 hours). If the >>> release discussion is passing through votes rather than timeout, would it >>> make sense in removing this step as redundant or would it be against >>> Apache >>> policy? >>> >>> With best regards, >>> Avik Ganguly. >>> >>> Disclaimer: >>> >>> Privileged & confidential information is contained in this message >>> (including all attachments). If you are not an intended recipient of this >>> message, please destroy this message immediately and kindly notify >>> the sender by reply e-mail. Any unauthorised use or dissemination of >>> this message in any manner whatsoever, in whole or in part, is strictly >>> prohibited. This e-mail, including all attachments hereto, (i) is for >>> discussion purposes only and shall not be deemed or construed to be a >>> professional opinion unless expressly stated otherwise, and (ii) is not >>> intended, written or sent to be used, and cannot and shall not be used, for >>> any unlawful purpose. This communication, including any attachments, may >>> not be free of viruses, interceptions or interference, and may not be >>> compatible with your systems. You should carry out your own virus checks >>> before opening any attachment to this e-mail. The sender of this e-mail and >>> *Fynarfin Tech Private Limited* shall not be liable for any damage that >>> you may sustain as a result of viruses, incompleteness of this message, a >>> delay in receipt of this message or computer problems experienced. >>> >> -- Disclaimer: Privileged & confidential information is contained in this message (including all attachments). If you are not an intended recipient of this message, please destroy this message immediately and kindly notify the sender by reply e-mail. Any unauthorised use or dissemination of this message in any manner whatsoever, in whole or in part, is strictly prohibited. This e-mail, including all attachments hereto, (i) is for discussion purposes only and shall not be deemed or construed to be a professional opinion unless expressly stated otherwise, and (ii) is not intended, written or sent to be used, and cannot and shall not be used, for any unlawful purpose. This communication, including any attachments, may not be free of viruses, interceptions or interference, and may not be compatible with your systems. You should carry out your own virus checks before opening any attachment to this e-mail. The sender of this e-mail and *Fynarfin Tech Private Limited* shall not be liable for any damage that you may sustain as a result of viruses, incompleteness of this message, a delay in receipt of this message or computer problems experienced.
