[om-council] Council meeting April 21st follow-up [1]

Bernhard Rosenkraenzer bero at lindev.ch
Mon Apr 25 07:13:46 EDT 2016


On 2016-04-25 11:57, Tomasz Gajc wrote:

>> We're the first distribution to use clang as its main compiler. That 
>> would be thrown away if we were to move to something else as a base.
> 
> Hi,
> 
> i'd say that we blowed up this chance,

I'd say not yet -- because by the time we're ready for release, we'll 
STILL be the first. Nobody else, except Android, has even started on 
taking this seriously.

> because of "undefinied quality level" bla, bla bla blockers, bla bla 
> bla, lot of bugs, bla, bla bla. NO GO.

I'd phrase it differently, but the problem is valid: We don't have the 
manpower to do everything we'd like to do and that includes fixing some 
bugs that don't affect most of us. At the same time we have a QA team 
that does a great job at finding bugs and trying to make sure we don't 
release something that doesn't meet their high standards.

This is generally a good thing, but it can be dangerous if QA 
expectations are higher than what we can deliver due to lack of manpower 
and other resources (e.g. hardware specific bugs would be a lot easier 
to fix if we had the billions of $$$ behind Ubuntu and could just get 
the problematic pieces of hardware into every developer's hands -- but 
interestingly enough, the distributions that could afford doing that 
sort of thing generally don't).

If we look at what others are releasing, we can see their testing is not 
as rigid as ours.
Try installing Lx3, Ubuntu, Fedora and openSUSE on an Acer Predator 
17-G3 laptop -- Lx3 works perfectly, Ubuntu and Fedora don't even boot 
to UI (graphics driver wrong), openSUSE installs, but has no sound, no 
network and no WiFi.
Yes, that's just one piece of hardware - the thing to take away from it 
is "if we can't install on a specific piece of hardware, Ubuntu, Fedora 
and openSUSE would still consider it release quality".

We need to be realistic about what is and isn't a real blocker.

Yes, if we release something with too many bugs, we risk getting a 
couple of bad reviews (along with good reviews from those not running 
into the issue). If we wait too long to release because of hard to 
find/hard to fix bugs that are serious to only few users, we risk 
getting no reviews at all, which is worse.

> Nobody out there even think about OMA being first distro using 
> LLVM/clang, because of NO RELEASE

Yes -- we can possibly still fix that by getting the Lx3 release out as 
quickly as possible now, before anyone else does the same thing.

> and NOT existing marketing.

We do have marketing, but there's also a valid problem here: Our 
marketing tends not to arrive where it is needed most.
We get great posts on our blog, in our social media and all - but we're 
preaching to the choir there, people following us already know what 
we're doing.

> Look at the many linux realted sites, blogs etc, news goes crazy 
> everywhere about trivial things like "OMG ubuntu builds kernel 4.5.0, 
> OMG they are some awesome".
> While we are doing more awesome work, without being sponsored by tons 
> of money.

That's exactly the problem - of course people running Linux related 
sites like talking about the distro they're using first, and the ones 
they know everyone else uses second -- so every small thing they do is 
great while something 100 times bigger anyone else does remains largely 
invisible.
We need 10 times the headline to even get them to consider something 
might be newsworthy - and the marketing team probably does need to make 
an even bigger effort to get the news to those not already covering us.
It's a bit of a chicken and egg problem though - we have to reach the 
critical mass somehow, if we manage that, the rest will happen 
automatically.

> I haven't seen any news out there that OMV is so awesome because it 
> uses LLVM/clang with LTO that gives great performance. There were two 
> main reasons:
> 1. Out of reach QA expectations
> 2. Release never happened

3. Critical mass not reached
4. We're late to the game, so some people who should care most about 
this (e.g. LLVM devs) are already settled into something else

> Imho if we want to survive RORE (Release Often, Release Early) must be 
> implemented a top of rolling release model only for architectures that 
> have future.

Fully agreed on that.

ttyl
bero



More information about the OM-Council mailing list