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

[Martin Steigerwald]

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