mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 21:35:58 +03:00
[GH-ISSUE #2420] 1.94 release #1190
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1190
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gaul on GitHub (Feb 25, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2420
@gaul commented on GitHub (Feb 25, 2024):
@juliogonzalez could you package s3fs 1.94 for Fedora- and openSUSE-based distributions? We previously talked about upgrading strategies in #2384 and I want to reiterate our gratitude for your work here. It is your choice on the update policy but our users definitely benefit from getting the latest s3fs in the most current distro release. Updating the enterprise distributions helps too (we just got a bug report for version 1.86 released 4 years ago in #2392!) but it might make sense to delay a few weeks to wait for regressions.
@juliogonzalez commented on GitHub (Feb 25, 2024):
Sure thing! For as long as Fedora is OK with bumping the versions for Fedora and EPEL, I am OK with going this way. And 1.94 is mostly about bugfixing, so I don't think Fedora is going to oppose a bump.
For openSUSE I always bump the version, as my submissions end up going to openSUSE Tumbleweed. Leap versions are a different beast, but they only last for 1 year anyway, so they never have really old versions, and they can get experimental packages as explained at https://github.com/s3fs-fuse/s3fs-fuse/wiki/Installation-Notes#installing-experimental-packages (those experimental packages from from my submissions as well).
I will prepare my GitHub repository for 1.94 next week.
When do you want me to submit to Fedora/EPEL? Would week 12 (starting on March 18th) work, for example?
As for Ubuntu/Debian, while I am not a maintainer there, I will at least provide (unofficial) builds at https://build.opensuse.org/project/show/home:juliogonzalez:s3fs-fuse. Not sure if we want to reference this at the Wiki, together with https://github.com/s3fs-fuse/s3fs-fuse/wiki/Installation-Notes#build-deb-for-ubuntu-18042004-from-within-docker?
@gaul commented on GitHub (Feb 26, 2024):
Most people use the packages so 1.94 won't see much testing until Fedora or some other rolling distro includes it. So if it is possible to submit to Fedora sooner and EPEL later I think this could help users if we catch a regression earlier. While most of s3fs work is bug-fixing, we do introduce regressions, e.g., 1.93 fixed a regression from 1.92 that took two months to fix #2212. But if this is too complicated please continue doing what you have already done because this works a lot better than what Ubuntu/Debian users currently experience.
I will continue to ask Ubuntu/Debian for package upgrades but I'm happy to reference your unofficial packages until the distros are in a healthier state. Let's make the main documentation in wiki at least. The main README might benefit from a small sentence pointing into the wiki.
@juliogonzalez commented on GitHub (Feb 26, 2024):
Not really complicated waiting a bit for EPEL, but if a regression or an important bug is spotted, the best course of action for the distributions would be to get a patch. As long as the patch (basically the .diff from a PR) can be cleanly applied on top of the latest released version, it's not very hard for me to provide such kind submissions for neither Fedora/EPEL or Tumbleweed.
I never tried it so far, because nobody reported bugzilla issues at Fedora nor (AFAIK) openSUSE. Unfortunately I am not tracking all GitHub issues here (some of them when time allows), but if you ping me specifically, I will try to have a look :-)
With your current suggestion, what I'd suggest is submitting to Fedora Rawhide and openSUSE first (will go to Tumbleweed, which is rolling release), and then after 2/3 weeks to Fedora 3X/4X and EPEL if we didn't get any bug reports here or at the bugzillas.
How does that sound?
ACK, I will update the Wiki later, and probably will prepare a PR for the main README.
@juliogonzalez commented on GitHub (Feb 29, 2024):
As usual, here goes my report about submissions to Fedora/EPEL/openSUSE
Git repository
openSUSE/SLE
From there, when accepted, it should get shortly into openSUSE Tumbleweed/MicroOS, etc.
SLE and openSUSE Leap will get the new version in the next service pack/minor version/major version as usual, unless they get requests from customers/users for an updated package in existing versions (including SLE15SP6 and openSUSE Leap 15.6 which are both in feature freeze), and an ECO is evaluated.
Fedora/EPEL
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2265969
Fedora Rawhide (41): https://bodhi.fedoraproject.org/updates/FEDORA-2024-8e10675fd8
Fedora 40: https://bodhi.fedoraproject.org/updates/FEDORA-2024-257d0fb19b
Fedora 39: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3692443397
Fedora 38: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f197f0c702
EPEL9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-8b2317fb27
EPEL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-5feadd30a0
EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f38388cd78
Ubuntu/Debian unofficial repository
https://build.opensuse.org/package/show/home:juliogonzalez:s3fs-fuse/s3fs-fuse
Pending, v1.94 is not in Debian Unstable yet, from where we use the source package.
@juliogonzalez commented on GitHub (Mar 25, 2024):
All submissions to Fedora and EPEL done.
Unofficial Debian/Ubuntu repo not updated yet. 1.94 is still not at Debian unstable.
@ggtakec commented on GitHub (Mar 26, 2024):
@juliogonzalez Thank you as always!