+1 on the code freeze date as well.. I suggest we label all the compliance related tickets (we may need even new tickets?) and just treat those as blockers for the release.. Even after we cut RC, I'd imagine we fix some things related to compliance.. In such a case, we can just merge first in the RC branch and the follow on merge on master..
On Fri, Feb 21, 2020 at 7:41 AM [email protected] <[email protected]> wrote: > > +1 on 02/28 being code freeze date. As this is a release focussing on > compliance, we would have to move some of the tickets from the list which > are not being worked on and unrelated to compliance. On Friday, February > 21, 2020, 01:01:45 AM PST, vino yang <[email protected]> wrote: > > Dear Community, > > As discussed before[1], the proposed release date of *end of Feb* for Hudi > 0.5.2 is getting closer. And we have some bug fixes and features since the > 0.5.1 release about one month ago. > > To make the release version more stable, I would suggest a bug fixing and > testing period of two weeks to be on the safe side. Given the testing > period, I would propose to do the code freeze on the 28th of Feb 23:59 PST > in order to keep the release date. It means that we would cut the Hudi > 0.5.2 release branch on this date and no more feature contributions would > be accepted for this branch. And the uncompleted features would be shipped > with the next release. > > There are 17 Jira issues unfinished[2] yet. All these issues have been > assigned. Hope everyone will do their best to catch up with the code > freezing time. > > What do you think about the proposed code freeze date? Glad to hear your > thoughts. > > [1]: > > https://lists.apache.org/thread.html/r70c6741b7396d845d1eb79ddfed922287e9683ae399abd245497a8f8%40%3Cdev.hudi.apache.org%3E > [2]: > > https://jira.apache.org/jira/issues/?jql=project%20%3D%20HUDI%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22)%20AND%20fixVersion%20%3D%200.5.2 > > Best, > Vino >
