[GH-ISSUE #794 ] Preparation for release of version 1.84 #457

Author

Owner

@ggtakec commented on GitHub (Jul 8, 2018):

Launched new release 1.84 now.

Thanks @gaul @orozery @chrilith @vadimeremeev @juliogonzalez @ambiknai @wjt @nkkashyap @cfz @phxvyper @dmgk
Your help was much appreciated. I could not have done this new release without you.

@mapreri @jollyroger
Just let you know, new release 1.84 version is tagged now.
Please check and start to package it if it have no problem.
Thanks in advance for your assistance.

@ggtakec commented on GitHub (Jul 8, 2018): ### Launched new release 1.84 now. Thanks @gaul @orozery @chrilith @vadimeremeev @juliogonzalez @ambiknai @wjt @nkkashyap @cfz @phxvyper @dmgk Your help was much appreciated. I could not have done this new release without you. @mapreri @jollyroger Just let you know, new release 1.84 version is tagged now. Please check and start to package it if it have no problem. Thanks in advance for your assistance.

kerem commented

Author

Owner

@cowdude commented on GitHub (Jul 31, 2018):

@ggtakec Thanks for fixing #748; that's a life saver for us. Do you know when this will be released on Ubuntu/Debian?

@cowdude commented on GitHub (Jul 31, 2018): @ggtakec Thanks for fixing #748; that's a life saver for us. Do you know when this will be released on Ubuntu/Debian?

kerem commented

Author

Owner

@mapreri commented on GitHub (Jul 31, 2018):

@cowdude personally, I've been waiting for @jollyroger to prepare the update.

@mapreri commented on GitHub (Jul 31, 2018): @cowdude personally, I've been waiting for @jollyroger to prepare the update.

kerem commented

Author

Owner

@marco-m commented on GitHub (Aug 2, 2018):

hello @jollyroger did you have any chance to work on the package for 1.84 ? Pretty please ? :-)

@marco-m commented on GitHub (Aug 2, 2018): hello @jollyroger did you have any chance to work on the package for 1.84 ? Pretty please ? :-)

kerem commented

Author

Owner

@marco-m commented on GitHub (Aug 16, 2018):

Hello @ggtakec, since there is no response from @jollyroger, would you be interested in the following:

My team makes a PR that adds to your travis build the capability to upload artifacts as a github release, based on tag (https://docs.travis-ci.com/user/deployment/releases/)
The artifact to be uploaded will NOT be a debian package, will be a zip file containing the needed executables. Having a debian package would be better, but we don't have time to do that. I think that having an executable to install by hand is a lot better than nothing at all :-) and it can be used as a blueprint to add Debian package later.

Would that work for you ?

@marco-m commented on GitHub (Aug 16, 2018): Hello @ggtakec, since there is no response from @jollyroger, would you be interested in the following: 1. My team makes a PR that adds to your travis build the capability to upload artifacts as a github release, based on tag (https://docs.travis-ci.com/user/deployment/releases/) 2. The artifact to be uploaded will NOT be a debian package, will be a zip file containing the needed executables. Having a debian package would be better, but we don't have time to do that. I think that having an executable to install by hand is a lot better than nothing at all :-) and it can be used as a blueprint to add Debian package later. Would that work for you ?

kerem commented

Author

Owner

@jollyroger commented on GitHub (Aug 16, 2018):

@marco-m @mapreri @cowdude sorry guys for this delay. I'll prepare the packages today. I hope @mapreri will be able to upload them soon after that.

@jollyroger commented on GitHub (Aug 16, 2018): @marco-m @mapreri @cowdude sorry guys for this delay. I'll prepare the packages today. I hope @mapreri will be able to upload them soon after that.

kerem commented

Author

Owner

@mapreri commented on GitHub (Aug 16, 2018):

Not quite, I'm next to completely offline till the ~6 of September.

However, I can do small tasks like adding you to the salsa.debian.org
repository if you register and answer to the mail I sent you back in
February (I think) :)

Anyway, please do prepare the upload, maybe I can find a spot to do the
upload...

On Thu, 16 Aug 2018, 5:37 p.m. Andrii Senkovych, notifications@github.com
wrote:

@marco-m https://github.com/marco-m @mapreri
https://github.com/mapreri @cowdude https://github.com/cowdude sorry
guys for this delay. I'll prepare the packages today. I hope @mapreri
https://github.com/mapreri will be able to upload them soon after that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/s3fs-fuse/s3fs-fuse/issues/794#issuecomment-413588314,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfyk88Ry5eME-5PmkLXXoaT1EWcsBj4ks5uRZGXgaJpZM4VGp0q
.

@mapreri commented on GitHub (Aug 16, 2018): Not quite, I'm next to completely offline till the ~6 of September. However, I can do small tasks like adding you to the salsa.debian.org repository if you register and answer to the mail I sent you back in February (I think) :) Anyway, please do prepare the upload, maybe I can find a spot to do the upload... On Thu, 16 Aug 2018, 5:37 p.m. Andrii Senkovych, <notifications@github.com> wrote: > @marco-m <https://github.com/marco-m> @mapreri > <https://github.com/mapreri> @cowdude <https://github.com/cowdude> sorry > guys for this delay. I'll prepare the packages today. I hope @mapreri > <https://github.com/mapreri> will be able to upload them soon after that. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/s3fs-fuse/s3fs-fuse/issues/794#issuecomment-413588314>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABfyk88Ry5eME-5PmkLXXoaT1EWcsBj4ks5uRZGXgaJpZM4VGp0q> > . >

kerem commented

Author

Owner

@jollyroger commented on GitHub (Aug 17, 2018):

@mapreri I've done the packaging and updates, please review.

For anyone interested in reviewing source package I have uploaded it to https://mentors.debian.net/package/s3fs-fuse

For everyone who needs the binary packages badly I've uploaded x86_64 build to my GDrive for testing purposes: https://drive.google.com/open?id=1iOSYFg44Ovg170s4Wmji8UJhsejsPKDc

@jollyroger commented on GitHub (Aug 17, 2018): @mapreri I've done the packaging and updates, please review. For anyone interested in reviewing source package I have uploaded it to https://mentors.debian.net/package/s3fs-fuse For everyone who needs the binary packages badly I've uploaded x86_64 build to my GDrive for testing purposes: https://drive.google.com/open?id=1iOSYFg44Ovg170s4Wmji8UJhsejsPKDc

kerem commented

Author

Owner

@marco-m commented on GitHub (Aug 17, 2018):

Thanks @jollyroger ! Appreciated ! What I don't understand is why all this package building must be done out-of-band by hand as opposed to integrate it in the travis build of s3-fuse :-) A CI system exists to avoid all these manual steps that, as this ticket shows, can take more than one month to be done. @ggtakec ?

@marco-m commented on GitHub (Aug 17, 2018): Thanks @jollyroger ! Appreciated ! What I don't understand is why all this package building must be done out-of-band by hand as opposed to integrate it in the travis build of s3-fuse :-) A CI system exists to avoid all these manual steps that, as this ticket shows, can take more than one month to be done. @ggtakec ?

kerem commented

Author

Owner

@gaul commented on GitHub (Aug 17, 2018):

I am not aware of any projects that push packages to distros; generally distros periodically pull source from upstream projects and build packages themselves. I do not believe this is an automatic process for Debian and someone like @jollyroger needs to kick off the process.

@gaul commented on GitHub (Aug 17, 2018): I am not aware of any projects that push packages to distros; generally distros periodically pull source from upstream projects and build packages themselves. I do not believe this is an automatic process for Debian and someone like @jollyroger needs to kick off the process.

kerem commented

Author

Owner

@marco-m commented on GitHub (Aug 17, 2018):

I am not talking about pushing the package to the distro upstream. I am talking about pushing the DEB package as a github release, from CI, automatically, triggered by a git commit.

As such, any user like me who cannot use s3fs-fuse because it has a memory leak, don't have to wait for the distro to make the package available, I just do a dpkg install :-)

If the distro maintainer wants or needs to do their own build from source, they can still do it.

@marco-m commented on GitHub (Aug 17, 2018): I am not talking about pushing the package to the distro upstream. I am talking about pushing the DEB package as a github release, from CI, automatically, triggered by a git commit. As such, any user like me who cannot use s3fs-fuse because it has a memory leak, don't have to wait for the distro to make the package available, I just do a dpkg install :-) If the distro maintainer wants or needs to do their own build from source, they can still do it.

kerem commented

Author

Owner

@gaul commented on GitHub (Aug 18, 2018):

I would much rather let distros handle packaging since I doubt many users will seek out upstream. Perhaps this is something you could demonstrate in another repo or PPA and we can evaluate it later?

@gaul commented on GitHub (Aug 18, 2018): I would much rather let distros handle packaging since I doubt many users will seek out upstream. Perhaps this is something you could demonstrate in another repo or PPA and we can evaluate it later?

kerem commented

Author

Owner

@marco-m commented on GitHub (Aug 18, 2018):

It seems I am unable to explain myself then, I don't know what to add besides restating what I already wrote. It seems you are happy with the current status quo, which is: with a random delay, one day a package will be available for users, if said user keeps making comments on a github issue. I made an offer to make the situation better, you are not interested. Thank you for s3fs-fuse, it helped us for a while, now it is time for us to find something else.

@marco-m commented on GitHub (Aug 18, 2018): It seems I am unable to explain myself then, I don't know what to add besides restating what I already wrote. It seems you are happy with the current status quo, which is: with a random delay, one day a package will be available for users, if said user keeps making comments on a github issue. I made an offer to make the situation better, you are not interested. Thank you for s3fs-fuse, it helped us for a while, now it is time for us to find something else.

kerem commented

Author

Owner

@gaul commented on GitHub (Aug 19, 2018):

Packaging binaries is not a simple matter given processor architecture, libstdc++, SSL libraries, and everything else. Perhaps it is possible to do this as a deb or statically linked binary but I have my doubts. s3fs can include this in releases if you can demonstrate how to do so for a broad cross-section of users with low maintainer overhead. However I suspect that distributions provide a better mechanism to deliver the same functionality and you may want to file issues against your distro of choice to upgrade. Please remember that s3fs is a volunteer project and additional work for niche use cases may not scope into the project.

@gaul commented on GitHub (Aug 19, 2018): Packaging binaries is not a simple matter given processor architecture, libstdc++, SSL libraries, and everything else. Perhaps it is possible to do this as a deb or statically linked binary but I have my doubts. s3fs can include this in releases if you can demonstrate how to do so for a broad cross-section of users with low maintainer overhead. However I suspect that distributions provide a better mechanism to deliver the same functionality and you may want to file issues against your distro of choice to upgrade. Please remember that s3fs is a volunteer project and additional work for niche use cases may not scope into the project.

kerem commented

Author

Owner

@marco-m commented on GitHub (Aug 20, 2018):

@gaul if you read all my comments in this thread, you will see that I offered to do the job, I never asked anything to s3fs-fuse besides if you were willing to review a PR. And again, I never proposed to do the work of the Debian maintainer.

@marco-m commented on GitHub (Aug 20, 2018): @gaul if you read _all_ my comments in this thread, you will see that I offered to do the job, I never asked anything to s3fs-fuse besides if you were willing to review a PR. And again, I never proposed to do the work of the Debian maintainer.

kerem commented

Author

Owner

@jollyroger commented on GitHub (Aug 20, 2018):

@marco-m I totally understand your feelings because there was a time I wasn't satisfied with the delay new versions of software appeared in Debian and I just started packaging software myself. But sadly the situation repeated again with me on the other said and I feel ashamed.

It is totally possible to build Debian/RPM packages with Travis and publish them somewhere for others to download without need to wait for the maintainer (i.e. me) to do the job. Unfortunately this will not automatically prepare and upload packages into the Debian Archive. This also means Debian/RPM build rules should be maintained by both upstream (in the s3fs master branch) and maintainer's repository (https://salsa.debian.org/debian/s3fs-fuse for Debian, see the Debian branch).

If there are no major changes on the build process the project will need little to no time to support the build infrastructure).

Once builds are working the project will need to have a package hosting. It could be packagecloud.io to cover most popular distros (they provide free paln for the open-source projects) or other package hosting (or some Debian machine/container to run the repo). If @ggtakec has any thoughts on this point than I'll prepare PR with changes to the .travis-ci.yml

@jollyroger commented on GitHub (Aug 20, 2018): @marco-m I totally understand your feelings because there was a time I wasn't satisfied with the delay new versions of software appeared in Debian and I just started packaging software myself. But sadly the situation repeated again with me on the other said and I feel ashamed. It is totally possible to build Debian/RPM packages with Travis and publish them somewhere for others to download without need to wait for the maintainer (i.e. me) to do the job. Unfortunately this will not automatically prepare and upload packages into the Debian Archive. This also means Debian/RPM build rules should be maintained by both upstream (in the s3fs master branch) and maintainer's repository (https://salsa.debian.org/debian/s3fs-fuse for Debian, see the Debian branch). If there are no major changes on the build process the project will need little to no time to support the build infrastructure). Once builds are working the project will need to have a package hosting. It could be packagecloud.io to cover most popular distros (they provide free paln for the open-source projects) or other package hosting (or some Debian machine/container to run the repo). If @ggtakec has any thoughts on this point than I'll prepare PR with changes to the `.travis-ci.yml`

kerem commented

Author

Owner

@ggtakec commented on GitHub (Aug 20, 2018):

@marco-m sorry for my late reply.
I think that Uploading package to Github Releases is one form of package distribution.
But like @gaul says, it is necessary to prepare packages for all environments in which s3fs can run. And that would be desirable.
And for corresponding to various kinds of packages, Github Releases alone is insufficient and it is necessary to correspond to package management software(apt, yum, etc).
If this is to be realized, I think that instead of Github Releases, another place is good. For example, packagecloud.io ( @jollyroger said ).
And it would be better to divide it into a repository dedicated to managing such packages.
In other words, we should prepare a package management repository that is different from the repository of s3fs source code (basic package version).

Although I'd like to offer a new version at any time, it is difficult to deal with all the differences in the user's environment. (We can not narrow down to just one environment.)
But s3fs can be built with autotools, and will not you build in the user's environment until the official version is provided?

@ggtakec commented on GitHub (Aug 20, 2018): @marco-m sorry for my late reply. I think that Uploading package to Github Releases is one form of package distribution. But like @gaul says, it is necessary to prepare packages for all environments in which s3fs can run. And that would be desirable. And for corresponding to various kinds of packages, Github Releases alone is insufficient and it is necessary to correspond to package management software(apt, yum, etc). If this is to be realized, I think that instead of Github Releases, another place is good. For example, packagecloud.io ( @jollyroger said ). And it would be better to divide it into a repository dedicated to managing such packages. In other words, we should prepare a package management repository that is different from the repository of s3fs source code (basic package version). Although I'd like to offer a new version at any time, it is difficult to deal with all the differences in the user's environment. (We can not narrow down to just one environment.) But s3fs can be built with autotools, and will not you build in the user's environment until the official version is provided?

kerem commented

Author

Owner

@ggtakec commented on GitHub (Aug 20, 2018):

@jollyroger If corresponding to packagecloud.io, I think that it is better to have rpm and other packages, to do that, we will also need a spec file.
And I think that it is necessary to pay attention to collision of package names. (I am not familiar with this yet)
Finally, I'm curious that there is a limit to the free plan for using packagecloud.io.

@ggtakec commented on GitHub (Aug 20, 2018): @jollyroger If corresponding to packagecloud.io, I think that it is better to have rpm and other packages, to do that, we will also need a spec file. And I think that it is necessary to pay attention to collision of package names. (I am not familiar with this yet) Finally, I'm curious that there is a limit to the free plan for using packagecloud.io.

kerem commented

Author

Owner

@jollyroger commented on GitHub (Aug 20, 2018):

@ggtakec I have some experience in writing spec files as well. We could start with the spec file used by Fedora distribution provided there are no copyright/licensing issues (i hope these are absent). There are only 40 lines of code there currently. It is also possible to support automatic package versioning for both Debian and RPM builds.

Please clarify what do you mean for package names collision. I see that both Debian and RHEL use "s3fs-fuse" as the source package name and provide the /usr/bin/s3fs binary, however Debian uses the s3fs name while Fedora keeps s3fs-fuse. I expect this will remain the same for the upstream-generated packages.

If we are talking about providing different package suffixes depending on the build environment then there is no issue with the RPM repositories: the only way is to keep the packages in a separate directories. The Debian packages however will need a special suffix attached for each target distribution to be able to put the packages in a single repository. I'm sure, this can be solved with Travis.

As for the packagecloud.io, i haven't found even the free plan buth there was a note that FOSS developers could request free plan. I do not know the limitations either.

@jollyroger commented on GitHub (Aug 20, 2018): @ggtakec I have some experience in writing spec files as well. We could start with the spec file used by Fedora distribution provided there are no copyright/licensing issues (i hope these are absent). There are only 40 lines of code there currently. It is also possible to support automatic package versioning for both Debian and RPM builds. Please clarify what do you mean for package names collision. I see that both Debian and RHEL use "s3fs-fuse" as the source package name and provide the `/usr/bin/s3fs` binary, however Debian uses the `s3fs` name while Fedora keeps `s3fs-fuse`. I expect this will remain the same for the upstream-generated packages. If we are talking about providing different package suffixes depending on the build environment then there is no issue with the RPM repositories: the only way is to keep the packages in a separate directories. The Debian packages however will need a special suffix attached for each target distribution to be able to put the packages in a single repository. I'm sure, this can be solved with Travis. As for the packagecloud.io, i haven't found even the free plan buth there was a note that FOSS developers could request free plan. I do not know the limitations either.

kerem commented

Author

Owner

@juliogonzalez commented on GitHub (Aug 20, 2018):

About RHEL/Fedora, I am maintaining https://github.com/juliogonzalez/s3fs-fuse-rpm for a long time, and the plan, after talking to @gaul is pushing the SPEC to Fedora, as soon as I have time to review the doc and adapt the spec if needed (the SPEC I use at my project is based on one that was previously submitted to Fedora, but not accepted).

Fedora package uses s3fs-fuse because there was already already a package s3fs before.

You can see the details at https://bugzilla.redhat.com/show_bug.cgi?id=725292

@juliogonzalez commented on GitHub (Aug 20, 2018): About RHEL/Fedora, I am maintaining https://github.com/juliogonzalez/s3fs-fuse-rpm for a long time, and the plan, after talking to @gaul is pushing the SPEC to Fedora, as soon as I have time to review the doc and adapt the spec if needed (the SPEC I use at my project is based on one that was previously submitted to Fedora, but not accepted). Fedora package uses `s3fs-fuse` because there was already already a package `s3fs` before. You can see the details at https://bugzilla.redhat.com/show_bug.cgi?id=725292

kerem commented

Author

Owner

@ggtakec commented on GitHub (Aug 20, 2018):

@jollyroger What I was worried about was not the package name on the same arch but the version number.
ex.) x.y.z-b.el5.x86(i386).rpm or x.y.x-b.deb
If it does not match up to the build number in the same format as upstream, will not the user get confused?

If we create a package only when we stamp a release tag and upload it to packagecloud.io etc., there is no problem.
However, I felt it difficult to manage such as changing the release number, only applying patches, etc.
(On this case, I think we need to update release number for each patch.)

If s3fs-fuse supports packages on packagecloud.io etc, which repository type do you consider as good?(I think the latter seems natural)

set up another repository under s3fs organizations and manage only specs and control files.
prepare both files in the current repository and upload packages to storage after building by travis(at only tagging release).

About free plan:
After registration, I found the page that free limit is (250 MB of storage/250 MB of bandwidth per month) in the subscription page.
(I just registered and I have not used it yet so it may be wrong.)
However, this free size will over soon. I hope that it is open to FOSS.

@ggtakec commented on GitHub (Aug 20, 2018): @jollyroger What I was worried about was not the package name on the same arch but the version number. ex.) x.y.z-b.el5.x86(i386).rpm or x.y.x-b.deb If it does not match up to the build number in the same format as upstream, will not the user get confused? If we create a package only when we stamp a release tag and upload it to packagecloud.io etc., there is no problem. However, I felt it difficult to manage such as changing the release number, only applying patches, etc. (On this case, I think we need to update release number for each patch.) If s3fs-fuse supports packages on packagecloud.io etc, which repository type do you consider as good?(I think the latter seems natural) - set up another repository under s3fs organizations and manage only specs and control files. - prepare both files in the current repository and upload packages to storage after building by travis(at only tagging release). About free plan: After registration, I found the page that free limit is (250 MB of storage/250 MB of bandwidth per month) in the subscription page. (I just registered and I have not used it yet so it may be wrong.) However, this free size will over soon. I hope that it is open to FOSS.

kerem commented

Author

Owner

@ggtakec commented on GitHub (Aug 20, 2018):

@juliogonzalez I agree. s3fs-fuse has its name problem from the beginning.
That is a problem that we can not decide alone, it is a troubling problem.

@ggtakec commented on GitHub (Aug 20, 2018): @juliogonzalez I agree. s3fs-fuse has its name problem from the beginning. That is a problem that we can not decide alone, it is a troubling problem.

kerem commented

Author

Owner

@jollyroger commented on GitHub (Aug 20, 2018):

@juliogonzalez I have checked the Debian archive and found no strict convention on the FUSE modules naming. So far there are 17 relevant packages starting with fuse, 28 packages ending with fuse(and 26 ending with -fuse among them), 44 packages ending with fs. I'll try to get some attention from Debian Developers on this topic but chances are high that nothing will be changed. I wonder i there's any interest on this or if we need this. Even if the transition to a single naming scheme is accepted this will take years anyway.

s3fs was not packaged in Debian before 2014 and at that time I got no objections on the name from other Debian Developers. Granted, I did not check on the name in other distributions at that time, I could have chosen the s3fs-fuse maybe.

@ggtakec for the versioning here's the one of the usual approaches to version naming. Let's check the freerdp-x11 package. Currently it has this version in the Debian unstable:

1.1.0~git20140921.1.440916e+dfsg1-15

As you see it consists of

the last tagged version (1.1.0)
and the git suffix that can be obtained partly using git describe command:
- last git commit date (20140921)
- number of commits after tagged release (1)
- git hash (440916e)

For the RPM packages I used similar but different approach due to rpm version limitations. The version was 2.2-255.12345ab:

the tag version (2.2)
release number that consisted of:
- number of commits after tagged release (255)
- git hash (12345ab)

This approach requires to stick with git metadata for versioning and as a result if there is a source distribuion tarball generated, there should be a separate VERSION file that will provide the version info when git is not present. The downsides of this approach can be observed on the branches where rebase and squash is used. In this case package ordering is messed up. The other thing is that beta or pre-release tags could mess up the usual package ordering as well. @juliogonzalez please share your thoughs, maybe there's a better approach that you know.

As for the

@jollyroger commented on GitHub (Aug 20, 2018): @juliogonzalez I have checked the Debian archive and found no strict convention on the FUSE modules naming. So far there are 17 relevant packages starting with `fuse`, 28 packages ending with `fuse`(and 26 ending with `-fuse` among them), 44 packages ending with `fs`. I'll try to get some attention from Debian Developers on this topic but chances are high that nothing will be changed. I wonder i there's any interest on this or if we need this. Even if the transition to a single naming scheme is accepted this will take years anyway. `s3fs` was not packaged in Debian before 2014 and at that time I got no objections on the name from other Debian Developers. Granted, I did not check on the name in other distributions at that time, I could have chosen the `s3fs-fuse` maybe. @ggtakec for the versioning here's the one of the usual approaches to version naming. Let's check the `freerdp-x11` package. Currently it has this version in the Debian unstable: 1.1.0~git20140921.1.440916e+dfsg1-15 As you see it consists of * the last tagged version (`1.1.0`) * and the git suffix that can be obtained partly using `git describe` command: * last git commit date (`20140921`) * number of commits after tagged release (`1`) * git hash (`440916e`) For the RPM packages I used similar but different approach due to rpm version limitations. The version was `2.2-255.12345ab`: * the tag version (`2.2`) * release number that consisted of: * number of commits after tagged release (`255`) * git hash (`12345ab`) This approach requires to stick with git metadata for versioning and as a result if there is a source distribuion tarball generated, there should be a separate `VERSION` file that will provide the version info when git is not present. The downsides of this approach can be observed on the branches where `rebase` and `squash` is used. In this case package ordering is messed up. The other thing is that `beta` or `pre-release` tags could mess up the usual package ordering as well. @juliogonzalez please share your thoughs, maybe there's a better approach that you know. As for the

kerem commented

Author

Owner

@mapreri commented on GitHub (Aug 20, 2018):

At any rate, I just sponsored @jollyroger 's work to debian unstable!
https://tracker.debian.org/news/981407/accepted-s3fs-fuse-184-1-source-into-unstable/

@mapreri commented on GitHub (Aug 20, 2018): At any rate, I just sponsored @jollyroger 's work to debian unstable! https://tracker.debian.org/news/981407/accepted-s3fs-fuse-184-1-source-into-unstable/

kerem commented

Author

Owner

@jollyroger commented on GitHub (Aug 21, 2018):

@mapreri Thank you!

@marco-m Should I consider to prepare this package for Debian Backports as well? Current version in Debian Stable is 1.80.

@jollyroger commented on GitHub (Aug 21, 2018): @mapreri Thank you! @marco-m Should I consider to prepare this package for Debian Backports as well? Current version in Debian Stable is 1.80.

kerem commented

Author

Owner

@ggtakec commented on GitHub (Aug 21, 2018):

@mapreri @jollyroger Thanks for packaging. I really appreciate your kindness.

@ggtakec commented on GitHub (Aug 21, 2018): @mapreri @jollyroger Thanks for packaging. I really appreciate your kindness.

kerem commented

Author

Owner

@ggtakec commented on GitHub (Aug 21, 2018):

@jollyroger The information you gave me is appreciated, and how to make version number is very helpful.

If we upload the package to Github Releases, I would like to update the package only at tagging a Release version.
In other words, instead of updating the package every time it merges into source code, I want to do it only when I tag a release version.
These packages can only be used meaningfully in the period until reflected in upstream.
It seems necessary to think a little about the type of package to prepare, the timing to create the package, and so on.

@ggtakec commented on GitHub (Aug 21, 2018): @jollyroger The information you gave me is appreciated, and how to make version number is very helpful. If we upload the package to Github Releases, I would like to update the package only at tagging a Release version. In other words, instead of updating the package every time it merges into source code, I want to do it only when I tag a release version. These packages can only be used meaningfully in the period until reflected in upstream. It seems necessary to think a little about the type of package to prepare, the timing to create the package, and so on.

kerem commented

Author

Owner

@marco-m commented on GitHub (Aug 21, 2018):

@jollyroger thanks for your help! I am using Ubuntu 18.04 and did a quick check, it seems to be working (seems = the leak takes some time to materialize). Thanks also to @mapreri and @ggtakec !

@marco-m commented on GitHub (Aug 21, 2018): @jollyroger thanks for your help! I am using Ubuntu 18.04 and did a quick check, it seems to be working (seems = the leak takes some time to materialize). Thanks also to @mapreri and @ggtakec !

kerem commented

Author

Owner

@jollyroger commented on GitHub (Aug 22, 2018):

@ggtakec the idea is to build package on every commit so you can ping someone (e.g. me) if the packages fail to build before you have to set a new tag. As for the publishing, we could have a separate repositories for nightly/continious builds on the master branch. These repos will hold builds from last 30 days for example. This way a volunteer testers or users that require freshly accepted changes on their environments could get build results fast. On the other hand the release repositories will hold all tagged releases builds (or at least it should be this way). For Debian, aptly can manage such repositories. For RHEL this is done via subdirectories.

In addition, Travis CI can be set to upload selected release artifacts using GitHub API after building a tagged release.

@jollyroger commented on GitHub (Aug 22, 2018): @ggtakec the idea is to build package on every commit so you can ping someone (e.g. me) if the packages fail to build before you have to set a new tag. As for the publishing, we could have a separate repositories for nightly/continious builds on the master branch. These repos will hold builds from last 30 days for example. This way a volunteer testers or users that require freshly accepted changes on their environments could get build results fast. On the other hand the release repositories will hold all tagged releases builds (or at least it should be this way). For Debian, `aptly` can manage such repositories. For RHEL this is done via subdirectories. In addition, Travis CI can be set to upload selected release artifacts using [GitHub API][1] after building a tagged release. [1]: https://developer.github.com/v3/repos/releases/#upload-a-release-asset

kerem commented