On Mon, Oct 17, 2022 at 10:40 AM Yaniv Kaul <yk...@redhat.com> wrote:
> > > 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'm already looking at these and I expect they can be merged before the current code-freeze date. > I have this for one for inode related code, which got some attention > recently: > https://github.com/gluster/glusterfs/pull/3226 > I'll try to review this one before code-freeze, but it requires much more care. Any help will be appreciated. > > I think this one is worthwhile looking at: > https://github.com/gluster/glusterfs/pull/3854 > I'll try to take a look at this one also. > 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) > This one is mostly ok, but I think we can't release a new version without an explicit check for unsupported versions at least at the beginning, to avoid problems when users upgrade directly from 3.x to 11.x. > 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). > I already started the review but I'm not very familiarized with cdc and the compression libraries, so I'll need some more time. > > 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. > At this point I don't think any of the remaining big features can be added, and given that release 11 has already been delayed quite a bit, I agree with Amar that we should provide a new version soon. I think it already contains very interesting changes that can improve performance and stability. > (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-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >>
------- 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-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
