Agreed
On Wed, Sep 21, 2022 at 12:42 AM Avik Ganguly <a...@fynarfin.io> wrote:
> 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 <
> chee...@monkeysintown.com> 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 <jamespdai...@gmail.com>
>> 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
>>> @jdai...@apache.org <jdai...@apache.org>
>>>
>>>
>>>
>>> On Mon, Sep 19, 2022 at 7:58 AM Avik Ganguly <a...@fynarfin.io> 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.
>
--
Sent from Gmail Mobile
