[Owncloud] Owncloud on Fedora/RHEL 6

[Matěj Cepl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2014-01-13, 21:25 GMT, you wrote:
> And here is the problem: Fedora 19 (!) seems to provide 
> ownCloud 4.5.13 which is about nine month old. That's not what 
> people want. They want ownCloud 6. And we seek a way to 
> provide them, even if they are on Fed19.

And if insted of pushing new version to your system (or OpenSUSE 
build) you would push it to the Koji, then you would have build 
for Rawhide and -testing distros in the same time. When I was 
working as part of the team dealing with Mozilla programs 
(Firefox and Thunderbird) we were proud to have 0day upgrades.  
I don’t see the reason why you couldn’t have the same in Fedora 
(note, Fedora is not RHEL so updates and rebases are mostly 
decision of the maintainers).

> Yes, I know, I worked long enough for another distro. But one 
> of the distro communities problems is that they don't really 
> face todays reality: As said above, people want to have 
> up-to-date apps. And if a new version (!) comes out, they 
> wanna use it and not hear "Well, you have a nine month old 
> version, and we will provide you with security fixes. Be 
> happy!"

I am not sure which distro you are talking about. If you think 
Debian/stable, then RHEL is not exactly like that. Of course, 
stability is very very important, but it is not exactly 
completely dead frozen stability as with the Debian/stable (and 
this is not meant to say anything against Debian maintainers ...  
when I see how incredible amount of work my colleagues have to 
spend on keeping RHEL together, I fully understand Debian with 
its limited resources is not capable of such feat). Notice that 
we have many server side (even PHP) programs in EPEL 
(https://fedoraproject.org/wiki/EPEL), and if you think that 
keeping up with WordPress 
(http://koji.fedoraproject.org/koji/packageinfo?packageID=4118) 
is so simple, then you are badly mistaken. For example, we had 
to create php53 for it (or because of Zarafa 
http://koji.fedoraproject.org/koji/packageinfo?packageID=9907, 
another not exactly simple package to maintain).

> They don't wanna have their operating system platform having 
> dictating the versions of the apps they're using.

??? Nobody dictates you anything, if you put you hand down to 
the shovel.

> You might want to check how that is on other, successful 
> platforms like android how it works there. Time has changed 
> a bit, and we as distro guys shouldn't close the eyes IMHO.

If you think that the mess of multiple copies of huge libraries 
bundled in individual packages half of them unmaintained (a mess 
from which Java folks are trying to get out ...  
http://openjdk.java.net/projects/jigsaw/ ... so far 
unsuccessfully) and thus half of them with unpatched security 
vulnerabilities makes me envious, then you are sorely mistaken.  
I don’t mind if people put such mess on their phones (their 
problem), but to have something like that on server doesn’t seem 
like a good idea. Yes, many people do it, but probably mostly 
because they have no other choice (especially in Java world 
which lacks appropriate technology), but a part of the Fedora’s 
mission is to provide excellent engineering. This doesn’t seem 
like a way there.

BTW, so far, RHEL customers seem to agree with this opinion.

> Of course not. This is speed: If ownCloud upstream releases 
> a new ownCloud version, the users can install it through their 
> distro package manager an hour later. 6.0.0a on Fedora 19.

As I said, as the old rabbi said ... it depends just on you.

> Whooohooo, now you're starting! Please calm down a bit, we're 
> not doing bad stuff intentional.

I didn’t say that. Just that because you are doing your separate 
community, you didn’t have time and resources to do it 
correctly. Completely without any sneering, how should I report 
bugs against your RHEL packaging? GitHub Issue tracker?

> a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not 
> backport the client without taking too much away. And RHEL not being 
> desktop system no 1 on the planet, we decided to ship an useful Qt 
> version in /opt/. I know, distro people hate that, but please consider 
> reality here as well. What do users want? A _working_ solution. And I 
> don't think that the Qt in /opt/.. steps in the way of anything else on 
> the system as we also provide wrapper scripts.

What do users want? Well, users of RHEL want also _maintained_ 
solution. Are you certain you will maintain Qt (it is a huge 
library) as well as Fedora maintainers? As I said we have php53 
package (for EPEL 5; don’t tell me how RHEL-6 is obsolete before 
supporting RHEL-5 ;)), or perhaps somebody can think about 
patching reasonable subset of owncloud-client to work with old 
Qt, or perhaps old owncloud-client can be patched to work with 
new server API. Something. Reasonable people are able to 
negotiate solutions for their problems.  

> b) issue tracker: https://github.com/owncloud/mirall/issues - not 
> exactly hidden...

OK, point taken.

>  > I don’t know where this mentality of splitting distro into
>> thousand of incompatible subcommunities growth from? Ubuntu,
>> with its PPAs, because Canonical doesn’t allow you to fix bugs
>> in the core libraries, or what (not trying to libel them, just
>> really honestly don’t know why you need to separate yourself
>> from the rest of the Fedora/RHEL community)?
> It's not that we want to separate, why should we? We see the benefit of 
> stable and maintained distros. But as I tried to explain above: We want 
> to provide our users with very current binary packages, as outlined, 
> that is one of our main goals. As soon as we can solve that requirement 
> with the main distros, we would love to drop our own packages.

Reasonable people are able to find solution for their problems.  
I believe most Fedora maintainers are reasonable people (yes, 
I know some exceptions ;))? Why do you think you won’t be able 
to work with them?

> Have you thought about how other web oriented platforms solve this 
> problem? Why does the ruby gem stuff exist? Because they want to be 
> faster than the distros update cycle, as we want. And I think you agree 
> with me that a third party repo with proper rpms is the better solution