[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