Re: Bits from the 10th Debian Groupware Meeting
Hi,
On 08/03/2017 03:21 PM, Rainer Dorsch wrote:
> thank you for all the links. My main question was why it is not listed at all
> in the groupware wiki, you could easily list nextcloud/owncloud in the section
> "Groupware projects not currently considered for inclusion in Debian".
It's a wiki, feel free to add it. :)
> For the technical part, I am wondering if that is still a real issue. I see
> the latest version 12.0.0 was released at May 22 2017, since then there was
> not even a bugfix release.
In terms of Debian release cycles that is still a very short time.
And the main issue here wasn't the release frequency; the main issues
were:
- most importantly: how to support updates from Debian release X to
X + 1, and upstream didn't want to support that at all, because the
amount of minor versions between two Debian releases was too much
- also how Debian can provide security support for the package during
the lifetime of a Debian release (though this was never a showstopper
in this case as far as I understand it)
And while nextcloud is a fork of owncloud, many of the people that
forked it were part of the original owncloud project.
My primary impression is that there's a mindset gap here: what I
really like about Debian stable - especially for servers - is that
the software included doesn't change except for security updates
and other serious bugs. Especially if I administer something, and
that something is not the primary thing I'm interested in in my
daily life, then I really want to be able to basically install and
forget the whole thing. And Debian provides me with that opportunity.
And Debian provides the opportunity that when I upgrade Debian once
every two or three years I can migrate my installation and only
have to test invasive changes _once_ at that point.
If I continuously update a package that is simply not the case. On
every update will I have to make sure that the new package doesn't
break anything. And that'd be fine if that specific package were
the primary thing I'm interested in, but that is not true for most
things.
So sure, someone whose job it is to run a service will not be
interested in Debian stable's packages for that service. They'll
use an own installation thereof. And that's perfectly fine. For
example, Wikipedia is not going to use Debian stable with th
MediaWiki packages from Debian on their systems - because it just
doesn't make sense to them. But a company that just wants to run
an internal Wiki for their own things might be very interested in
Debian's packages for MediaWiki because they have better things
to do than constantly administer a Wiki.
My impression with Owncloud/Nextcloud was that the developers are
not interested in the "install & forget for 2 years" use case of
their software. Which is fine, after all they're giving away their
software for free, but which also means that the fact that Fedora
and Debian dropped the packages is only a symptom of a larger
problem: I personally just can't recommend Owncloud/Nextcloud.
Because if I install that manually or via some other mechanism
upstream provides (e.g. Snap packages) I still have to deal with
the fact that every update is going to be something that might
require quite a bit of manual intervention. Again: for someone
whose job it is to administer an Owncloud/Nextcloud instance
that would be perfectly fine, but it's not something I want to
have to deal with, and my guess is that a lot of other people
don't want to have to deal with.
And I have not seen anything by the Owncloud/Nextcloud devs that
this attitude has changed. I don't begrudge them their opinions
in this problem space, but that just means that their software is
simply not for me.
> So I can see multiple solutions
> 1) Debian includes nextcloud only in unstable and testing (probably most
> compatible with the nextcloud/owncloud business models, see also https://
> help.nextcloud.com/t/will-nextcloud-be-inviting-to-distribution-packages/89/28
> )
You could have it in unstable-only, but anything in testing
targets the next stable release of Debian, and if a package is
not a candidate for a stable Debian release, it shouldn't be in
testing.
> 2) If Nexcloud is interested to bring their software into the debian repo,
> they can help run their regression tests on the upgrade path implemented for
> Debian stable releases (which happens infrequently)
Well, sure, if they were interested in supporting these kinds
of upgrade paths, which they strongly implied that they are
not.
Regards,
Christian
Reply to: