Rename Coffice?

[Sebastian Sauer]

On 03/28/2013 10:46 PM, Inge Wallin wrote:
> On Thursday, March 28, 2013 18:10:35 Sebastian Sauer wrote:
>> On 03/28/2013 05:47 AM, Jaroslaw Staniek wrote:
>>> Sebastian, I only referred the marketing/PR side of things; both Inge
>>> and part of me offer you support in that area.
>>> The desire I tried to express is: avoiding confusion among users or
>>> 3rdparties, plus wannabe journalists, by not multiplying extra
>>> *official public* flavors of Calligra in their minds unless it can be
>>> easily explained in a short sentence to a Joe user.
>> I see what you mean but I am not sure how to do better in the future.
>> Maybe a bold intro sentence that explicit says "This is experimental"
>> and probably most important :"This is not an official Calligra release".
>> Yes, makes sense, agreed :)
> I think we need to distinguish two things:
>   - What the user sees / experiences and who created this.
>   - What the package consists of.
>
> In this particular case COffice is a creation by you. It builds on the Calligra
> Office Engine(not yet tm :) ) but what the user actually sees is created by you.

Yep, not different from all the *.py scripts in words/plugin/scripts, 
from Kexi's scripting plugin, from lot of the functions shipped in 
Sheets, etc. pp. I would save 95% of Calligra or even 99% of KDE was 
written by only one dev without proper review :)

> In any LInux distribution the packager would be behind the package and if it's
> an official part of the distribution, then it's the distribution name that is
> behind it. This is part of the quality assurance; if the program is not mature
> enough it simply won't be a part of the official distribution but will be hidden
> in some repo for "contributed code" or so.

Some distributions indeed do tests. Some even do patches and work active 
in upstream. Yes, that's really good but its not the case for all. Some 
distributors active break our applications, not care, do so again and 
again. Some automate the packaging process and not even do any tests any 
longer. I think I just saw some days ago commits to fix active breakages 
of Krita in a certain distribution... now iirc that's really not new. 
Its an old problem persistent especially on the Linux desktop. But let's 
not rant here :)

In the mobile landscape its different, better and more worse. Google 
Play does only some automated tests. E.g. Ovi and BB do real blackbox 
testing with dedicated QA-people trying to crash your app, monitor 
battery-usage, weeks and sometimes months long QA-processes. Google Play 
is here certainly rather open just like Linux distributions are, means 
minimal automated tests, not more. Most other mobile app markets are 
much more strict. Not only related to crashes and quality but also to 
there own business interests which the application may undermine or 
compete with, with political and ethical rules, etc. pp.

I doubt any Linux distributor has dedicated QA-centers with people doing 
app-QA all day. I especially doubt that's happening for KDE/Calligra. 
But well, Google Play does not too...

> In this case, you are both the developer and the packager. What you have done
> is remarkable - in a very short time you have created something that works on
> Android and solved many and tricky problems on the way.  But that's not what
> the user sees; s/he sees a limited package that can only show one file format
> and with a very limited UI. There could even be crashes - I don't know.

I know since Google Play has stats for that :) 1 crash so far and it 
looks like a borked device with some IllegalArgumentException before the 
app is started. Not that bad taken the thausend of installs :)

> I think that in a case like this it's very important that we stamp alpha (or
> beta) on it and say things like "built on the calligra engine" rather than
> "calligra for android" - until it's ready!

Agreed.

> But we all agree on that, so I'm just preaching for the choire and repeating
> what you already wrote. The actual point here is that we don't have any
> policies on how to handle this.
>
> Normally KDE only releases source code and never does any packaging.

That's wrong. See e.g. 
http://necessitas.kde.org/necessitas/necessitas_sdk_installer.php

And that not since yesterday. We have e.g. KDE on Windows since *years* 
delivering packages direct to end-user including installer and updater 
for binary stuff. http://windows.kde.org

Also KDE subprojects delivered before packages like Amarok Windows 
executables and so on and on. 
http://community.kde.org/Amarok/GettingStarted/Download/Windows

>   However
> for Android and other similar platforms we either have to outsource the
> packaging to individuals or companies (like KO ;) ) - or start a new trend in
> the KDE community by packaging and releasing binaries ourselves.

Its not a new trend and its done since long years. To name just two 
examples: myself with e.g. KMLDonkey on N9 and Android, Marble as one of 
the earliest N9 apps and now even on Jolla/Nemo already.

In fact, FLOSS has no such rules. Anybody can (and imho should) take the 
code, make packages and distribute. That can *not* be limited per GPL. 
Its a core-value of FLOSS to not limit that.

In maximum what Calligra can do is to demand changing the name like e.g. 
debian does with Firefox=>Iceweasel. iirc the KDE-logo has also 
protection, the artwork is proper licensed and cannot be limited in any 
way. Anyhow, Coffice has/had an own name and artwork already :) So, even 
with policy there would have been no way to prevent anything.

> I'd like to have a short discussion about this here and then take it to the
> wider community and e.V board so that KDE can create some new policies. What
> does a package need to be able to put a "KDE" stamp on it, or in this case
> "official Calligra software"?

Actually this will be *very* difficult if you not like to apply the same 
rules to all distributors out there. Situation is that currently anybody 
can take the code, make packages and ship with artwork and brand 
included. Now where to draw the line? What if a distributor adds an own 
patch does he need to rebrand KDE? Or do you try to define who's a 
distributor (e.g. only Linux?) or is it about the channels (what's with 
commercial distributions? one-click installs? embedded?).

I think any try to get policies in place will just result in "then let's 
play save and rebrand that". Since our artwork cannot be limited by 
whatever policies on top of the FLOSS license (which explicit does *NOT* 
define such limitations and latest now it pays out - hach, I like FLOSS) 
only thing you can demand is not to use the name KDE/Calligra name and 
the Calligra/KDE logos. But is that really what's wanted? I doubt its in 
the spirit of FLOSS.

Serious, what's the problem and why does it need policies now when it 
worked fine since what 15 years? :) What's the advantage and what are 
the disadvantages?

>>> This is important,
>>> and was also quickly pointed out in the first comment on your blog
>>> entry
>>> [http://blogs.kde.org/2013/03/24/coffice-calligra-android-available-now].
>> Yep. Well, its all "work in progress" and that includes names, getting
>> the patches proper upstream / into master, etc. I think its a different
>> balance act of at the one time making clear "its a start, a preview, its
>> going to change" and still make clear "yes, this is Calligra *code* done
>> by the Calligra community". The later was important for me cause of
>> exactly that assumption that some may write "New Office suite" and leave
>> out all the background that 99.9% of the work that was needed are not
>> done by me but by Calligra. Yes, it was important for me to outline that
>> direct in the headline. Always not so easy to proper balance such things
>> and you can be sure some news-pages will get it wrong, like to get it
>> wrong, will spin there own stuff, always, cause it may sound better,
>> brings more clicks. What I think is/was very important here is to make
>> the message positive on any level. News love negative messages and imho
>> its better to be to positive then negative on any level.
>>
>> In concrete I personally prefer to be wrong citated with "its an
>> official Calligra release" then with a "its a Calligra fork". I really
>> tried hard to prevent the last case. Not only with Calligra but also
>> with that fake-library, with the qmake/cmake case, with the Qt-only
>> case, with Linux Desktop/Android case, etc. pp. In that blog I tried to
>> explain why while making sure a) its not set in stones and b) its going
>> to change and c) this is NOT negative and cause things are done
>> different does NOT mean how its done before is bad or so.
>>
>> Actually that's one of the reasons why I got that code into our
>> repository weeks before. Personally this days I like github more but
>> okay. Its also why I talked about that in IRC, why I announced the
>> milestone2 here 1-2 weeks ago, why I gave earlier packages for testing
>> to the community, why I real-time chatted in IRC, showed of the blog
>> before, etc. pp. I just think it was very important to name Calligra
>> (and for that matter KDE), to make clear that yes, this is Calligra code
>> and its coming out of the Calligra community.
>>
>> For the last sentence, the "its coming out of the Calligra community":
>> Let's be realistic. NO project in Calligra or in KDE is done by all of
>> the community. If somebody (and most things in KDE/Calligra are done by
>> only one dev) comes up with something and if it fits basic rules (like
>> FLOSS) then its from (or coming out of) the community. More so if it
>> utilizes 99.9% of the code written by that community :) Anyhow, the imho
>> REALLY important and interesting aspect here is more how its driven
>> future. That's what we worked out or are still working out. Looks
>> promising so far :)
>>
>> On that matter:
>> * Calligra Mini then.
>> * I mailed sysadmins. In future we may use an own KDE Google Play
>> account. Still some things to work out. Its in progress.
> Great! Calligra Mini is a good name.  But I'd be uncomfortable to release
> Calligra Mini under that name until it's quite a bit better than now. On the
> other hand the release early, release often mantra also is good.  So how shall
> we handle this? Release Calligra Mini alpha1, alpha2, beta1 and so on? Or use
> COffice as the development code name and then release Calligra Mini when it's
> ready?

My proposal would be to wait some more weeks till its in a better state 
and then align it to the Calligra version number. But then maybe it 
would have advantages to start with a 1.0 version?

Note that Android (or is that only Necessitas/QtCreator?) limits the 
possible version naming. Its x.y and minimum is 1.0. You cannot add a 
alpha/beta to the version.