ownCloud has been famous for being hostile against downstream (Fedora, Debian).
Especially since Jos is still on board: Would you still consider to threaten downstream with trademarks? Or will Nextcloud follow a different agenda and be “inviting” to downstream users and downstream developers?
I’m quite interested in this topic since we are running an ownCloud instance for a nonprofit organization. Since everything is run by volunteers, we do not have the resources to upgrade to new versions that frequently and have to rely on stable distribution packages for providing our services.
Let me also note that the aggressive comments towards distributions ended my consideration to contribute to ownCloud.
I think it depends on the definition of “hostile”. From the past we always welcomed help for packaging purposes but we want to make sure that our users get the latest and greatest release.
So if a distribution ships something like a totally outdated and insecure ownCloud. Such as for example Ubuntu did.
The problem there being also: Somebody does an install nextcloud-server and gets a totally outdated release with bugs which are already fixed in another release. Usually people also report bugs to us to the bug tracker then which is kinda wasted time for both parties.
I think a joined approach where distributions AND upstream work together would be welcome. But this also has to come in a way that upstream has the capacities and resources to support it. If a distribution decides to freeze a major version for 4 years of Nextcloud and then manually applies backports (with no guarantees of the quality of those for the timeline) then this is something that I personally dislike.
That said, we’re an open community and happy to start any discussions on how to work best together to distribute Nextcloud.
Debian stable releases (and their users) require long-term security support for whatever version is packaged, and that’s a deliberate choice for their use-case. It shouldn’t be that hard if the timing is well co-ordinated, such that the latest feature-complete version lands in Debian shortly before freeze (November 2016), and upstream made some long-term (2-3 years?) commitment to identify (e.g. file CVEs) and try to fix security bugs in that version.
The only ways to get that wrong, are if a rapidly changing development version went into Debian sid/testing too soon (and thus requires substantial changes after the freeze date); or if upstream doesn’t clearly identify or make easy to backport patches for security bugs. (e.g. Oracle MySQL, not detailing the security bugs fixed, adding arbitrary new features in a maintenance release, and not even having public source version control ).
By all means call the long-term supported version by some other name / numbering scheme if you want to differentiate it from the very latest vendor release, but please don’t use trademark law to threaten distributors.
Also, Debian users expect a smooth upgrade between major versions of the OS, so that needs to be supported by applications too.
In my opinion, web apps shouldn’t even be packaged for distributions. You’re almost certain to run into issues as soon as you install another one, with different requirements. Things breaks when you try to configure things a bit differently, updates break, etc.
If you require LTS support for a web app, get an enterprise contract.
Fine, this thread is about not blocking people in doing so.
[quote="oparoz, post:5, topic:89]If you require LTS support for a web app, get an enterprise contract.
[/quote]
I’m not following. LTS was not promoted at owncloud.com, so I am a bit surprised that this should have made the difference. Note, that ownCloud 7 was supported until recently. (In some way v7 is probably still covered, since there have been no new security fixes for 8.x since then.) However, when v7 was still supported you would have to do 4 upgrades to get to v9.
True and I won’t comment about the use of IP laws to protect a product. I just don’t want distros to start dictating how and when to release NC.
Users can stop using packages and switch to something else, like containers or simply Ubuntu Snap.
But that requires a change in processes and it may not be that easy to introduce, depending on the type of organisation.
My comment was about the previous post which mentions smooth upgrades between major version of an OS. I should have used quotes.
The way distros do LTS only works for Linux itself and some apps which evolve really slowly. That’s one reason Ubuntu introduced Snaps. If Debian wants to jump 9 version every 3 years, then they should provide the required scripts to make it happen, not NC and it will be a mess and people will blame NC.
If a company needs to stay on a very old version of an app because it’s integrated with other solutions per example, then it’s always a good idea to have a support contract to help with the migration to a more recent version.
That’s certainly an honest answer to the original question.
I’m quite happy most other maintainers prefer to be nice towards their users, so I don’t have “enterprise contracts” for every bit of moderately complex software from the stable distributions on my servers.
I’ll be keeping a close eye on both projects and continuing to package OwnCloud updates for the foreseeable future.
Once there is an initial beta release here then I’ll take a look at the packaging requirements for that and see how it will go attempting to get it through package review.
It is a fair amount of time just testing OwnCloud (see my own blog for a view of how much time it takes to package and test each update) so I’ll make no promises about NextCloud of course …
Assuming it is not too painful to package (given my existing OwnCloud knowledge and activities anyway) I’ll certainly be of a mind to do so, but the difficulty will come as the two projects diverge in time and any library dependencies that may end up differing.
TL:DR; Keeping an eye on it, will have something more meaty to say in coming weeks.
ownCloud used to have a 6 months release cycle where new releases came out. Now if an LTS distro ships an ownCloud version the releases keep piling up til the next release. Take Debian LTS for example: 5 years support amounts to 10 releases.
Upgrading a web app is not as simple as a desktop app or system utility because you have to worry about database migrations in addition to configuration and files (and the upgrade process is already fragile enough ;D). Furthermore Debian is not the only long term stable distro. You see this gets out of hand pretty fast and would require ownCloud to run upgrade tests for hundreds of different upgrade paths so the current decision is to limit this to only the previous version.
The release model does not fit with Debians release cycle so Debian maintainers patched out the safety lock for the previous version update requirement. People voiced their frustration on both sides, etc.
I honestly don’t know if this will ever be solved. The only solution I can think of is to release new versions only every 5 years or something like that which is just bogus.
Debian was first to implement a working automatic upgrade script, and OC could have adopted that instead of showing disrespect for the people working on it. Distributions have lots of users and do much work to “sanitize” software. Seeing NC following the same path is disappointing to say the least.
@xav the issue has been discussed to death already. The general gist is: their way of upgrading is not considered to be a solution by the developers and it was more of a communication issue, no hard feelings.
To summarize my answer: we are friendly and open to any collaborators, also package maintainers, but IMHO it will either take a long time or not be possible to upgrade from a version which is not a direct predecessor
I think there are mainly two problems to solve. One is on the Nextcloud side and one is on the Distribution side.
make it possible for Distributions and users in general to upgrade also across multiple major versions. I think this is something we definitely can and should improve. I thought I read already a thread about it by @LukasReschke but I can’t find it any more.
Distributions need to find a way to keep their version secure. I think that’s especially crucial for software running on a server, like Nextcloud. I don’t really know how this can be handled on a Distribution side without updating at least to the latest bug-fix releases. But I think that’s a important point need to be solved to keep the users secure.
If NC could designate one version/branch as “long-term supported” at a time, you’d only need to support two types of upgrade:
upgrade to latest (major or minor) version from previous version (for people who update often)
upgrade to new LTS from previous LTS (this is basically what Debian tried to do, but if the developer does this, great)
And although Debian LTS releases are supported for 5 years, not every application has to be part of that, the official stable release only has a life of 3 years (plus ~6 months between the freeze and release).
But since the LTS version will be different for each distribution, it’s not just one LTS version and upgrade paths isn’t it ?
Supporting a LTS version is also not only about upgrade paths, there are also critical fixes backports.
Disclaimer : I’m no employee of NC myself. This is just IMHO.
I don’t think you should interpret posts in the forum as the official stance of NC, at this point they are only personal opinions in a discussion.
The project just started and right now a lot of things are in the process of being figured out.
Relationship with package maintainers are no exception and this is a great time to make your opinion heard.
Actually I was trying to suggest NC designate a single release branch as LTS, so that stable distributions can all use that, rather than each picking some arbitrary version and hoping it’ll be supported. Ideally something like Firefox ESR.
