On Mon, Oct 17, 2022 at 8:41 AM Xavi Hernandez <jahernan@xxxxxxxxxx> wrote:
On Mon, Oct 17, 2022 at 4:03 AM Amar Tumballi <amar@xxxxxxxxx> wrote:Here is my honest take on this one.On Tue, Oct 11, 2022 at 3:06 PM Shwetha Acharya <sacharya@xxxxxxxxxx> 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.
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/3868 (this one is particularly interesting, I hope it works!)
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:
I think this one is worthwhile looking at:
I wish we could get rid of old, unsupported versions:
(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-devel@xxxxxxxxxxx
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@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
