[Pkg-owncloud-maintainers] Bug#816376: Bug#816376: Unfit upstream

On Mittwoch, 9. März 2016 22:30:13 CET Jos Poortvliet wrote: > On woensdag 9 maart 2016 19:21:31 CET MJ Ray wrote: > > Jos Poortvliet wrote: > > > The situation is rather sad and frustrating as users who decided to > > > trust > > > the Debian developers and took their packages over ownCloud's provided > > > packages are now stuck on a version which can't trivially be upgraded to > > > either our upstream version or anything else. We would love to find a > > > solution for them - as I've said many times, our main concern is the end > > > users, rather than politics, rules or anything else. > > > > One of the debian project's top priorities is its users and it has > > rather more track record of providing solid software for them for the > > long term which is WHY the various rules, policies and guidelines were > > defined. They weren't just adopted as self-flagellation by masochists. > > There seems to be a complete and total lack of appreciation for that > > upstream in this instance. > > Well, it's true that I'm rather skeptical of some of these rules, yes. We > (myself and many others at ownCloud) aren't exactly new to the world of > distributions - my previous job was at SUSE, the same goes for our CEO and > half the management team and many others. > > I've said it would be healthy for distributions (in general, I haven't aimed > at Debian or any other specific distro in this regard) to re-think these > rules as many of them were developed for applications of a rather different > kind (C/ C++ console or desktop tools, mostly). Now I know many of the > modern languages have been doing stupid stuff like re-creating packaging > tools (eg ruby, php and others) and that creates all kinds of annoying > issues. Beware, this may be somewhat of a flame, but honestly right now I am quite a bit fed up with "either you support the new web app developers way of doing things or you will become obsolete except for running containers" argumentation crap. I use Debian on my server cause of those rules. They provide me some sanity for maintaining it. With Debian I have one upgrade every about three years. And the rules in Debian make sure that upgrades are working very smoothly and most rough things are documented in the releasenotes. I´d even go as far as that Debian is one of the distributions with the best track record on upgrading. And that since more than 10 years even at times where one would just re-install a SUSE or RedHat distribution with every major upgrade, cause upgrades just didn´t work out at all, neither were they supported. Now, I do think after what I learned here that the upgrading of Owncloud is a complete mess compared to the standards I know from Debian. It just does not compare in any sensible way to what I am used to and to what I love about Debian. Additionally the dependency upgrades and additional dependencies Owncloud requires with each new versions make a backport pretty unfeasible. David tells about 70 related packages and as I tested upgrading Owncloud debian packages by the path David suggested, which didn´t work for me at that time, maybe due to a misunderstanding on my side on his instructions in README.Debian which he clarified after that, I ended up with a quite adventurous mixture of Debian Jessie + Unstable. Thanks to the outstandingly excellent dpkg / apt packaging framework I was able to downgrade it to plain Jessie after that and continue running the server as Jessie again. I know it doesn´t have to be that way. For example Wordpress debian package, before there was a backport for jessie- backports I just had the one from unstable installed. It needed just 2 other packages from Sid, at the beginning it didn´t need any other packages from sid at all, only later versions needed two packages. That is a software that is feasible for backporting. And it has a backport. There has been some reluctance about it from the backports team, as a previous backport was cancelled, but the current one is maintained well. Also for drupal7 there is a backport, not completely in sync with the version in testing currently, but there is one for jessie and there is also one for wheezy. Owncloud at its current state of development IMO is not feasible for a backport – and its it not feasible for a backport it certainly is not feasible for a security upgrade to a new major version of it. Cause even if David or someone else did all the work to backport that 50+ other dependencies that a new version of Owncloud need a new version of them, who on earth is going to test it with all the other PHP related packages in Debian stable that use the same dependencies? Now I don´t know an easy solution to this, but with the current way Owncloud is developed, I get the impression that it is very difficult to provide any sane backport for it or switch versions for Owncloud within security support for Debian stable. Not impossible, but difficult. So thats IMO why there isn´t one, nor why no one decided to go with the Iceweasel approach. Debian compromises on its stable policy already. For chromium and iceweasel maintainers provide new upstream versions within stable security support. And even though I think they may bend unbundling rules for packaging to some extent by accepting that upstream bundles some stuff, by no means I have the impression that they would need to upgrade 50-70 other packages just in order to bring in an upgraded browser to stable. > It is a mess. We all know it. We should look for solutions - because if we > don't, as I've said a few times: distributions will become 'the thing you > run a docker container on'. And indeed, Snappy, project Atomic - there is > work going on in this direction. I am still surprised at the certainity in which you claim to know the future. My current conclusion regarding Owncloud is this: I am not going to mess with it. Instead I prepare to remove it from my server, before Jessie security support for it ends. Why is that? Cause the alternative would be this: - I use a Linux container. - I use upstream tarball or package which bundles almost all of the dependencies. - Instead of Debian security support for *all* packages, with announcement mailinglist, with fixed CVEs mentioned, with Debian Security Advisories, with debsecan vulnerability reporting, with cron-apt upgrade reporting, with documentated limitations checkable with check-support-status from package debian-security-support I would need to rely on upstream promise to provide timely security updates for *any* and *all* of the bundled dependencies. Maybe I could trust it, but I currently don´t know. Debian has a track record. I run it since more than I bet 8 years on server VM and I am pretty confident no one broke into my server. And we run it on a ton of servers for ourselves and customers at my employer so I am pretty confident it is a repeatable experience. - I need to install each upgrade, mess manually with migrating crypto keys at least once and what else upstream may come up with. Now I ask you: Are you kidding me? Is this the model of doing things the future? Develop without any care of maintainability just for the sake of bringing in new features really fast? Thanks, I opt out with this model of upstream saves some work which then every user of Owncloud has to do. I´d think its upstreams responsibility to do this work, instead of relying that users will put up with it and having the work that could be done *once* replicated about, well 8 million of times. If you read this as a strong "Get your upgrades fixed!" then, yes, thats exactly it. > As I wrote in the other email - I feel there were two options: Debian would > be flexible with the rules, making things work until, perhaps, ownCloud > could be modified to fit the Debian rules (or perhaps these rules were no > good fit, period). Or - no more Debian ownCloud packages. I don't know if > the first option was ever considered - all I know is that we ended up with > the second. The rules of Debian is why I have it on the server and, no offense meant, no OpenSUSE or Fedora. And no Linux containiner for every single app I want to run on it. I am happily running Debian Sid + some experimental packages on my laptop, but on my server? Nope. Wordpress can do it, Drupal can do it, Postfix can do it, Dovecot can do it, Mailman can do it, Apache can do it, you name it can do it. For all of them Debian provides seamless upgrades across distro-releases and for some even backports, like Wordpress for example). No data loss whatsoever with any of those so far. I have security updates with CVE numbers in changelog, I have it all via apt, I have it all work out of the box, I have releasenotes, I have sanity, I have I can sleep well with all of it running on my server. (Well I wonder a bit about Wordpress, but I hope just a few addons it may work out.) Please I want this for Owncloud as well… or I really intend hard to look at an alternative for it. Back then I assumed that crypto support stuff was stable, but upstream changed it twice, at least. Without a sane upgrade path. Back then I thought Owncloud would focus on providing share file & sync and I can just install it and be done with it. Actually I understand that even since Owncloud 8 its mostly about share & sync, its still not installing and be done with it. I now found that Owncloud appears to be like a tamagotchi that messes up big time if I do not give it care and nudging and upgrades and stuff every half of a year at least. I want to install this thing and be done with it. For three years at least. And then upgrade it. With any possible pitfalls being documented in README.Debian or release notes. Does not seem that this is going to happen soon enough for Stretch at the moment, a pity, cause I truly believe that Owncloud has something for it. I chose it for some reason. It clearly offers a functionality I want. Yet, if its not supportable for my server with any amount of sanity, its out. And I don´t even know what I tell possible customers of Owncloud at the company I am with. I for sure will tell them to use upstream packages after what I learned here, but I do not intend to hold back what I think of upstream policy on upgrades especially in the context of enterprise needs. Cause most companies I do work with want to do it just like I do: Install it and *be done* with it. I bet with the current model there is not even a remote chance for Owncloud to ever be included as a supportable package within SLES or RHEL. And heck for Debian its just about 3 years, if one excludes Owncloud from Debian LTS support, which I would clearly advise to do, not 10. If the new web world is break things hard and break things often… I am clearly willing to sit it out, to wait for some sanity to come back into the minds of the developers of the web apps. Cause in the end its my choice how my future will look. And no one elses. There is no law that determines that distributions will be just a base operating system for containers. There is no law that forces me to keep Owncloud installed on my server. Its removal its just one apt purge call away. I done this before with stuff, and I am willing to do it again if I am not convinced I am willing to put up with the hazzle to maintain it. Its the people who create Debian and Owncloud and its the users who create the future. After DebConf 2016 in Heidelberg I have no doubt that Debian is there to stay to be used as a distribution in its best sense. I also think Owncloud will stay and thrive. But unless the approaches I see being used in Owncloud development do not at least to some extent match with the amount of what I call sanity I want for my server, I am not intending to continue to use it. The barrier of entry for an application to be packaged within Debian may be high, but I came to trust this entry barrier. It keeps out the stuff that I would use more of my precious time to maintain it than I want. I want this what I call quality. I am not living for my server. The server is there to provide the functionality I want – with the least amount of work on my side. In other words: The server is there to serve me… not the other way around. If its in the Debian repo, I know, usually it is maintainable. I love this entry barrier. That said I use rubygems for some things at work, like installing fluentd – yet I would never put this directly in contact with the internet and I am not really fond of having a packaging system inside a packaging system. I agree there is an issue to be solved, and maybe even some changes in how distros are created are important to make, but blindly adopting the crazy break things often, break things hard, deploy every commit at the moment it is pushed kind of strategy is not it… at least not for me. Maybe for a huge company like Facebook this agile development approach will work really good with a team of dozens of people to fix things up, in case someone messes the app. But not for me. Heck, even for Plasma + KDE Frameworks packages are quite maintainable. They even extend their outreach to distros currently. If the desktop can do it, if quite some PHP like Wordpress and Drupal apps can do it, if every other server app like Postfix, Apache, Nginx, Dovecot can do it, why can´t Owncloud? Whats up with you guys? Thanks, -- Martin