On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez <jaher...@redhat.com> wrote:
> On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi <a...@kadalu.io> wrote: > >> Here is my honest take on this one. >> >> On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya <sacha...@redhat.com> >> wrote: >> >>> It is time to evaluate the fulfillment of our committed >>> features/improvements and the feasibility of the proposed deadlines as per >>> Release >>> 11 tracker <https://github.com/gluster/glusterfs/issues/3023>. >>> >>> >>> Currently our timeline is as follows: >>> >>> Code Freeze: 31-Oct-2022 >>> RC : 30-Nov-2022 >>> GA : 10-JAN-2023 >>> >>> *Please evaluate the following and reply to this thread if you want to >>> convey anything important:* >>> >>> - Can we ensure to fulfill all the proposed requirements by the Code >>> Freeze? >>> - Do we need to add any more changes to accommodate any shortcomings or >>> improvements? >>> - Are we all good to go with the proposed timeline? >>> >>> >> We have delayed the release already by more than 1year, and that is a >> significant delay for any project. If the changes we work on is not getting >> released frequently, the feedback loop for the project is delayed and hence >> the further improvements. So, regardless of any pending promised things, we >> should go ahead with the code-freeze and release on these dates. >> >> It is crucial for any projects / companies dependent on the project to >> plan accordingly. There may be already few others who would have planned >> their product release around these dates. Lets keep the same dates, and try >> to achieve the tasks we have planned in these dates. >> > > I agree. Pending changes will need to be added to next release. Doing it > at last time is not safe for stability. > Generally, +1. - Some info on my in-flight PRs: I have multiple independent patches for the flexible array member conversion of different variables that are pending: https://github.com/gluster/glusterfs/pull/3873 https://github.com/gluster/glusterfs/pull/3872 https://github.com/gluster/glusterfs/pull/3868 (this one is particularly interesting, I hope it works!) https://github.com/gluster/glusterfs/pull/3861 https://github.com/gluster/glusterfs/pull/3870 (already in review, perhaps it can get it soon?) I have this for one for inode related code, which got some attention recently: https://github.com/gluster/glusterfs/pull/3226 I think this one is worthwhile looking at: https://github.com/gluster/glusterfs/pull/3854 I wish we could get rid of old, unsupported versions: https://github.com/gluster/glusterfs/pull/3544 (there's more to do, in different patches, but it's a start) None of them is critical for release 11, though I'm unsure if I'll have the ability to complete them later. - The lack of EL9 official support (inc. testing infra.) is regrettable, and I think something worth fixing *before* release 11 - adding sanity on newer OS releases, which will use io_uring for example, is something we should definitely consider. Lastly, I thought zstandard compression to the CDC xlator is interesting for 11 (https://github.com/gluster/glusterfs/pull/3841) - unsure if it's ready for inclusion, but overall impact for stability should be low, considered this is not a fully supported xlator anyway (and then https://github.com/gluster/glusterfs/pull/3835 should / could be considered as well). Last though: If we are just time-based - sure, there's value in going forward and releasing it - there are hundreds (or more) of great patches already merged, I think there's value here. If we wish to look at features and impactful changes to the users - I suggest we review https://github.com/gluster/glusterfs/issues/3023 , we look at what's missing, what's in-flight and can get in, draft the release announcement and see if there's enough content. (I'm for the former, I just think the latter is a good reasonable exercise to see what's in 11!) Y. > Xavi > ------- > > Community Meeting Calendar: > Schedule - > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC > Bridge: https://meet.google.com/cpu-eiue-hvk > > Gluster-devel mailing list > gluster-de...@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > >
_______________________________________________ maintainers mailing list maintainers@gluster.org https://lists.gluster.org/mailman/listinfo/maintainers