On Wed, Mar 23, 2011 at 7:40 PM, Robin Burchell <virot...@viroteck.net> wrote: > On Wed, Mar 23, 2011 at 4:48 PM, Sivan Greenberg <si...@omniqueue.com> wrote: >> I'd also like to add that regardless of way the new architectural >> decisions were made, he's communication of the decision was excellent > > I think the existence (and breadth) of this thread is clear evidence > that it wasn't. Or did you skip over the bits about people with > expertise in the areas involved and Nokia architects noting that they > hadn't been consulted about this at all, and their requests for > information on what specific performance problems there were etc > repeatedly being ignored?
I admit I found it difficult to follow the thread, I stand corrected! Let me just say that from my *personal* (I apologize if this sounded as if I speak for broader group...) point of view as someone following the development, I knew exactly what was going to happen, which components supposedly did not deliver the promise, and which components are going to be committed to onwards. For a simpleton like me trying to understand which technologies to target or work on, how open they are and what is the level of support in *open source* available, this was rather a breeze. (having known parts of SyncEvo, surrounding projects and the less then hour support replies I got from Patrick just by stating I am interested in helping, without tedious bug reports and endless red tape, also for me SyncEvo feels more of an tangible upstream to meego than tracker, but that is surely a hunch based, uninformed feeling). If the input was indeed disregarded, than this is terribly unfortunate and shows we have serious issues running the project which should be resolved *before* any engineering work goes on. Maybe we need to adopt Ubuntu's code of conduct? Let's hope an "official" governing body of MeeGo would address that ASAP as I know the Nokia side a bit, where blood sweat and tears were put into their responsibility areas in MeeGo. However, my personal reservation is that it is not possible that those "wrong decisions" were made at a whim and without considering the alternatives or the current state of affairs, or were light headed at. I just can't buy it, maybe I'm stupid. Even if that is how it seems from the communications exchanged on this thread so far. (Which gets me back on needing an open architecture process! with specs and bof per spec, after we get past the stabilization phase which feels to be delaying...). Superior technology is worth nothing without proper execution... > >> Sometimes you need to use 'older' wheels and improve them until exhaustion >> before recreating them... > > Yes. Key point being that you should try improve something *first* > rather than throw it out on what seems to be a whim without consulting > the people involved and without backing up your reasons for *why*. I recall that Imad explained in his email why, again for me as a simpleton in the MeeGo world, that seemed enough. Regardless if EDS is much "inferior" to Tracker if I was an meego architect, I'd settle first for 10 contacts working flawlessly with the technology I can use without hurdles today (I have expectations from vendors, community, users? Yes yes, I know MeeGo is NOT for end users... Someone wants to see a final first usable version of the software already....), than state of the art that cowards at locating or taking long to load or taking ages to load the first contact... or even if is flawless on the end user side, takes ages for my developers to learn.. or kills my battery..(this is just an example!) > > [I'd like to note that I am certainly not the world's biggest fan of > some of the mentioned technologies, but I don't really support how > this decision was made, either] I can understand that, and I admit I prefer open architecture decisions and discussions a'la Ubuntu BOF -> Spec style. Linaro seems as if they are doing it at least in a very open and transparent way. -Sivan _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
