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.
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
