[Pkg-owncloud-maintainers] About no more ownCloud in Debian
Jos Poortvliet
jos at owncloud.com
Tue Mar 1 22:53:19 UTC 2016
Friends,
I'm genuinely sorry it had to come to this, but as you might have seen in the discussion on the ownCloud mailing list - I personally think this was unavoidable.
Not because of your work, in any way. I think the fact of the matter is that ownCloud, right now, isn't suited for the rules Debian imposes on software it ships. Requirements like having a split between configuration and code, a long support cycle and being able to skip upgrades are certainly not unreasonable [1], but ownCloud is not developed and designed to function that way.
That is not because we hate Debian and other Linux distributions. It isn't even that we don't want it to work that way - we're an open source project and if anything is missing, it is simply because nobody felt an urge to do and maintain it [2]. It all comes down to priorities [3]. I am sure you all can understand that, and I hope you can respect it, too.
Of course there are people paid to work on ownCloud, but also from customers no demand for these things has been coming - at least not to a degree that we'd abandon work on scalability or reliability, for example. So while ownCloud 9.0 will indeed deliver a new, stand-alone updater, which is a step in the direction of providing what Debian needs, it isn't good enough and was not developed with that goal in mind.
Now I understand you have the Debian rules to follow and I appreciate the effort you've put in in making this work. And I understand it must feel very unfair that ownCloud contributors yell at you for doing the work of making ownCloud fit for Debian.
I just hope you can understand the fear and perhaps frustration of some ownCloud developers with regards to risks they see with this approach. They know the architectural limitations of ownCloud, they see the bug reports - we have over 8 million users now so you can expect every corner case and weird setup to have hit the limits of ownCloud and resulted in a bug report by now. And I guess you've seen Lukas' blog post, he takes security very serious, as does ownCloud in general - we absolutely want to follow the best practice and have a policy of disclosing security issues 2 weeks after we released updates to our users. Every time a package wouldn't make the deadline of being packaged and delivered to users that way, somewhere in Switzerland Lukas is banging his head on a wall. And there are cracks in the wall by now. This doesn't excuse unpleasant comments - but I hope it helps you understand it. And let's be honest, nobody is above such things, I see them on this email list too. Perhaps you disagree on the risks - that is your right, of course.
I'd like to say sorry for the unpleasantness and thank you for your work - and repeat my invitation to the ownCloud Contributor Conference. I'd much prefer work on ownCloud to make it suitable for inclusion in Debian over no packages, or fighting about them. But - only if it is done in a way we all feel comfortable with it. That is, *properly* following the rules Debian sets and *properly* implemented to not risk any data loss for users, either in a way we can maintain or in a way maintainable by you.
Perhaps, in September, we can have a chat about this in person, and see if we can make these two requirements meet.
Greetings,
Jos
[1] though I have thoughts on how relevant these rules are and, in general, believe that it is breaking rules which changes the world, not blind adherence to them - this aspect is off topic here.
[2] and doing this in a way that works for debian but doesn't break ownCloud for people running it on the countless other platforms is not as trivial as you might think. Besides the 4 databases and weird platforms (like NAS devices), we would want to do it right and avoid multiple code paths or increasing complexity as both make maintenance and getting new coders involved harder. And those matter to us, too. Some of these changes limit what we can do on other platforms or what 3rd parties can do (limiting innovation) and create potentially a lot of work. If something is just a matter of policy, has no security impact, increases maintenance and doesn't give some powerful benefit - it won't be easy to convince maintainers to add it.
[3] while drafted some weeks ago, I just published this blog post which seems relevant to this conversation: https://owncloud.org/blog/the-three-owncloud-development-priorities/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/attachments/20160301/1e690a6b/attachment.sig>
More information about the Pkg-owncloud-maintainers
mailing list