I won't put great length into my final answer, because my point, i.e. necessitas NOT being a community project, has not been refuted, nor do I see in Bogdan's answer any sign that my points will be addressed in to foreseeable future.<br><br>Just some specific points:<br><br>1) Insulting<br><br> I didn't insult anybody. I probably hurt feelings but you were forewarned. Re Ray, I was referring to his own quote:<br><br>"I just handle Mac and Windows builds and our own version of the ndk<br>

toolchains, I'd like to help out more on the Qt side but I'm basically<br>

a novice with Qt still, plus, I've fallen behind on ndk work anyway."<br><br>2)  Vision (http://community.kde.org/index.php?title=Necessitas)<br><br>Oh, you mean there is yet ANOTHER place to look for information re necessitas? Besides, this a TODO list, not a vision.<br>One thing I understand is that Widgets are more important to you than QML, even though Qt is deprecating their use on mobile device.<br>Your call, but I think this is a waste of time/resource, and I admit I'm somewhat frustrated you refuse to integrate the QML 

components (either mine's or Kate's) because it doesn't have the "Android

 look& feel", which seems fallacious to me, especially considering the alpha state of the project and that the widgets do not have it either.<br><br>3) KDE; ah, KDE:<br><br>"I didn't wanted to give also my money": If you don't want to use one of the numerous free solutions for hosting FLOSS projects as to make the project coherent, please organize a fund raising. I'm pretty sure you'll get the $150 for a yearly hosting plan in a matter of seconds.<br><br>"I had to join somebody, KDE was the natural choice": Why "joining somebody"? To host the project? See above. KDE a natural choice? Why? Because they're using Qt? In that sense, you could as well have asked QGIS to host necessitas. At least they officially support multiplatform.<br><br>4) Patches:<br><br>"Some time is easier/faster to rewrite them, then to reject a patch": Oh indeed, it is ALWAYS faster, but it is not how it works in a community project.<br>"e.g. the menus patch that you sent [1], it didn't

work at all": My point exactly. You didn't discuss the supposed fact that it doesn't work with me (although it works pretty well for me, thank you).<br>"Probably you are frustrated because I had to revert your last

patch,

because it was a fiasco": Not a bit frustrated about the revert. I KNEW it wasn't working as it should. I'm frustrated because I proposed a solution (limit to /assets) both on the dev list and on the reviewboard, without ANY reaction.<br><br>OK, that's about it. <br>I'm still not 100% sure Qt on Android is viable as a "commercial" alternative but thanks to Bogdan's great work, I was able to port my pet Qt/QML apps from Symbian to Android and they work great with some patches.<br><br>For what it's worth, my necessitas clone is at https://gitorious.org/~koying/qt/koyings-android-lighthouse (Native Options Menu + Native Context Menu + "/assets" only + Native Share menu soon)<br>My Symbian derivated QML Components are at https://gitorious.org/~koying/qt-components/android-qt-components (Native Options Menu + Native Context Menu + Native Share menu soon)<br>Don't forget Kate's Meego-derived components, either (We should really merge those...)<br><br>Best Regards<br>- Chris -<br><br><br>On Thursday, March 15, 2012 6:01:46 PM UTC+1, BogDan wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Chris,

<br>

<br>On Mar 15, 1:07 pm, Koying <<a>c...@semperpax.com</a>> wrote:

<br>>  WARNING! This post is a rant, expresses only my own opinion and feelings

> might be harmed during the course of this reading.

<br>>

<br>> *<RANT>*

<br>>

<br>> This post is a reaction to a thread on the dev list where Bogdan was

> lamenting on the lack of commitment to the project.

<br>> I found it both laughable and pathetic in the sense that NOTHING is done to

> make it a project you can be committed to, and I'll expose, IMHO, why.

<br>>

<br>

Until now I find your remarks very insulting ...

<br>

<br>> 1) *This is a one man (and a half, sorry Ray), "benevolent despot" kind of

<br>> project.*

<br>>

<br>

<br>I'm not going to accept you to insult Ray ! Ray's contribution is not

<br>half !

<br>Because Ray dedicate his free time to this project, now 4000+ users

<br>can use this

project on windows and mac ! What have you done for this project ?

<br>

<br>>

<br>> Bogdan IS the project. Every single decision is made by him without

<br>> discussions nor appeal. He has his vision for the project (that I didn't

<br>> find, but it could be hidden in one of the zillions places the project is

<br>> scattered into. More on this later) and I don't feel like he is open to

> discuss/challenge this vision.

<br>

<br>I'm confused ! First you say that "He has his vision for the project

<br>that I didn't

<br>find .. "  then you say  "I don't feel like he is open to discuss/

challenge this vision." !

<br>If you don't know my vision, how can you say that I'm not open to

<br>discuss it,

did we ever discuss it ?

<br>

<br>Anyway, my expectations for this project are here:

<br><a href="http://community.kde.org/index.php?title=Necessitas" target="_blank">http://community.kde.org/<wbr>index.php?title=Necessitas</a>

<br>

<br>We (you and me) had a few discussions before, but I don't remember I

have been that close...

<br>We talk about menus and about look&feel plugin, I remember that we

<br>had different approaches on this topic, you wanted add android

<br>look&feel only to

<br>your QML, I didn't agreed, because I still want to support class

widgets.

<br>It means that I'm not open to discuss? Please give me more hints on

<br>this matter !

<br>BTW Android 9patch is more complex than the standard, so, you can't

<br>use

QML BorderImage (qDrawBorderPixmap) to draw the images !

<br>

<br>> This is human. AFAIK Bogdan created the project and feels he has all rights

> on it (which he has), but that prevents real involvement from others.

> Fact is, if Bogdan is unavailable, the project just plain stops.

<br>>

<br>

<br>Every community project, is based on meritocracy:

You code/contribute, then you have the right to make decisions !

<br>

<br>> 2) *NOTHING is done to make it a community project.*

<br>>

<br>> I already ranted about this, but the scattering of the project resources is

> just plain ridiculous, laughable and a HOWTO not to make a coherent project.

<br>> Wiki on sourceforge, 1 mailing list on kde and 1 on google groups, 1 bug

<br>> tracker on sourceforge and 1 on google code, unclear/hidden master

<br>> repository, unclear contribution process, which leads me to:

<br>>

<br>

<br>If you search this mailing list you'll find all the informations you

<br>need:

<br>-  regarding HOWTO and other information: The <a href="http://sf.net" target="_blank">sf.net</a> pages was written

<br>by Damine Treg,

<br>sadly he didn't had time to continue, so I asked may times for peoples

<br>help !

Nobody wanted to do it! I can't do everything by myself !

<br>- 1 on google groups - this is a high traffic general mailing list

used by everybody.

<br>- 1 mailing list on kde  - this one is a low traffic mailing  list

<br>used only by developers, I don't have time to read all posts on

google.

<br>- 1 bug tracker on sourceforge and 1 on google code -  it was discuss

many times before, ONLY bug tracker on sourceforge should be used.

<br>- unclear/hidden master repository: check <a href="http://community.kde.org/Necessitas/Repositories" target="_blank">http://community.kde.org/<wbr>Necessitas/Repositories</a>

<br>- unclear contribution process, as I already said to you before is not

<br>may fault !

<br>

<br>

<br>> 3) *What the f... does necessitas has to do with KDE?*

<br>>

<br>> I only assume Bogdan and Ray are KDE devs and that it is easy for them to

<br>> host necessitas's master git and "contribution process" on KDE, but this is

<br>> VERY wrong from a necessitas perspective. KDE might have its own

<br>> contribution process but it is irrelevant to us and ridiculous for a

<br>> necessitas contributor to have to register a kde account to be able to use

<br>> reviewboard, itself, IMHO, a very obscure and complicated system for code

> contribution vs. what is existing in github or gitorious.

> Obviously, all merge requests in the gitorious clone are ignored.

<br>> Pretty please, make gitorious the main repository, use gitorious merge

<br>> request system and do whatever KDE stuff you fancy do in your own KDE

<br>> corner.

<br>>

<br>

It has everything to do with KDE! Necessitas *IS* a KDE project !

Again, searching this list will give you enough informations.

<br>I'll try to summarize: When I released first alpha I had to put

<br>Ministro libs somewhere,

<br>I used some free servers to put the libs, but it was not a good

<br>solution. I dedicated my

<br>free time to this project and I didn't wanted to give also my money,

<br>so I had to find

<br>a reliable solution,  back then Nokia just joined Microsoft, to fight

<br>against android,

<br>so, I had to join somebody, KDE was the natural choice, we share the

<br>same goal:

To keep QT free and powerful.

<br>

<br>Regarding contributions: We want to upstream everything, the problems

<br>are:

<br> - Nokia doesn't accept contributions without accepting and sign their

<br>contributors agreement,

<br> - I can't move the project to <a href="http://qt-project.org" target="_blank">qt-project.org</a> (they don't want it yet

<br>because is not finished)

so you can't accept their agreement, when you publish your patch.

<br> - The ONLY solution was to "force" contributors to release their code

under BSD or public domain.

<br>

<br>>

<br>> 4) *Accept contribution, reject them, discuss them or ask for update, DON'T

<br>> rewrite them*.

<br>>

<br>> Crying for contribution, then taking some parts of a patch to rewrite it

<br>> you way, mostly incompatible with the original patch, is NOT the way to go

> to motivate contributors.

<br>>

<br>

<br>  Again I find some of your remarks very insulting, I'm not "crying"

<br>for contribution !

I'm happy to have more contributor, but i'm not crying !

<br>

<br>  Some time is easier/faster to rewrite them, then to reject a patch

<br>or to

<br>ask for updates ! e.g. the menus patch that you sent [1], it didn't

<br>work at all,

but I've seen a lot potential, so I decide to make it work [2] !

<br>I *CREDIT YOU FOR YOUR WORK* and I push a working version, so,

what was wrong in that ?

<br>

<br>  Probably you are frustrated because I had to revert your last

<br>patch,

<br>because it was a fiasco, it made the applications almost unusable, is

that my fault ?

<br>Probably it is, because I trust your patch and I didn't run and check

all the tests before push it !

<br>The problem is to run and check all the tests it takes too much (1-3

days).

<br>

<br>> 5) *The project is sloooooowwwwww*.

<br>>

<br>> Due to 1), 2) and Bogdan's limited availability, necessitas is slow to

<br>> progress in its own right. I kind of made my own necessitas fork to move

<br>> on, and due to 4) it has diverged so much from the main trunk that I'm not

> sure I'll bother rebasing.

<br>>

<br>> 6) *Maybe related to 3), I don't know if it is necessitas or KDE, but one

> should definitely learn about the "git rebase" command*.

<br>>

<br>> All the merges coming from I don't know which branches makes the git

<br>> repository unreadable. The proper way to merge upstream is to rebase and

> resolve conflicts. Merging upstream is pure lazyness.

<br>>

<br>

WOW you are so good! We didn't know about "git rebase" command !!!

<br>Of course you forgot to learn that you can't use "git rebase" command

when more than one people is using that branch !

Check <a href="http://lwn.net/Articles/328438/" target="_blank">http://lwn.net/Articles/328438/</a> for more info on this topic.

<br>

Merging with upstream is NOT lazyness, is responsibility !

<br>

<br>> *Bottom line*:

<br>>

> *Necessitas is NOT a community project*.

<br>>

<br>> Unless the issues outlined are addressed, It is pointless to whine about

> necessitas' lack of contribution.

<br>> I suspect many of the more knowledgeable potential contributors will just

<br>> take the trunk and adapt it to their needs, without bothering trying to

<br>> contribute it back. Unless the project becomes more community friendly, I'm

> open to contribute to a potential fork.

<br>>

<br>> *</RANT>*

<br>>

<br>

I'm open to discuss what is wrong with my vision !

<br>I'm open to know other people vision, so, please share your vision

with us!

<br>

<br>Don't forget that this project is based on meritocracy! Even if you

<br>have a vision, remember that you must to code it, not only to discuss

<br>it !

<br>

<br>To be clear: I'm open to discuss, but I'm not going to "cry" for

<br>contributors or to accept contributions with insults in the same

<br>box !

<br>

<br>> Best Regards

<br>> - Chris -

<br>

<br>[1] <a href="https://git.reviewboard.kde.org/r/103934/diff/#index_header" target="_blank">https://git.reviewboard.kde.<wbr>org/r/103934/diff/#index_<wbr>header</a>

<br>[2]

<br><a href="https://projects.kde.org/projects/playground/mobile/necessitas/android-qt/repository/revisions/6dc070ff2715fd75e0e8576aa6f4c524b824ad42/diff" target="_blank">https://projects.kde.org/<wbr>projects/playground/mobile/<wbr>necessitas/android-qt/<wbr>repository/revisions/<wbr>6dc070ff2715fd75e0e8576aa6f4c5<wbr>24b824ad42/diff</a>

<br>

<br>Cheers,

BogDan.

<br></blockquote>