You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Avik Ganguly <av...@fynarfin.io> on 2022/09/19 14:57:57 UTC
Hotfix Release Process
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.
Re: Hotfix Release Process
Posted by James Dailey <ja...@gmail.com>.
Agreed
On Wed, Sep 21, 2022 at 12:42 AM Avik Ganguly <av...@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 <
> cheetah@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 <ja...@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
>>> @jdailey@apache.org <jd...@apache.org>
>>>
>>>
>>>
>>> On Mon, Sep 19, 2022 at 7:58 AM Avik Ganguly <av...@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
Re: Hotfix Release Process
Posted by Avik Ganguly <av...@fynarfin.io>.
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 <
cheetah@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 <ja...@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
>> @jdailey@apache.org <jd...@apache.org>
>>
>>
>>
>> On Mon, Sep 19, 2022 at 7:58 AM Avik Ganguly <av...@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.
Re: Hotfix Release Process
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
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 <ja...@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
> @jdailey@apache.org <jd...@apache.org>
>
>
>
> On Mon, Sep 19, 2022 at 7:58 AM Avik Ganguly <av...@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.
>>
>
Re: Hotfix Release Process
Posted by James Dailey <ja...@gmail.com>.
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
@jdailey@apache.org <jd...@apache.org>
On Mon, Sep 19, 2022 at 7:58 AM Avik Ganguly <av...@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.
>