Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
This is actually quite good in my view, we have a proven working in the wild implementation in official , while all other components are still there to experiment with or showcase when they become mature enough. -Sivan On Fri, Mar 25, 2011 at 11:11 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Fri, 2011-03-25 at 12:19 +0200, Sivan Greenberg wrote: This is actually quite good in my view, we have a proven working in the wild implementation in official , while all other components are still there to experiment with or showcase when they become mature enough. This is certainly a good compromise. But then we just develop a Tracker miner for E-D-S (which is somthing we planned to do anyway in upstream, at least at some point). Some pointers and info on how to make a E-D-S miner for Tracker: http://lists.meego.com/pipermail/meego-dev/2011-March/482147.html Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 09:11:48 AM Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Well Tracker is in MeeGo sure, but I was talking about RAD environments on top of Tracker, and in one of the mails on this architecture thread I saw this: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 09:11:48 AM Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Yes Tracker is still part of MeeGo, but I was talking specifically about RAD environments built on top of Tracker. My concern is that I saw this statement in one of the mails in this thread: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the official way of using Tracker in Maemo Qt based code. As far as I know it has been packaged for MeeGo too, and I am not sure if the above statement from Arjan van de Ven is correct. In order to build the RAD environment, that I personally dream of, QSparql will be needed even if application programmers won't all use it directly. Maybe we can do a visual QtCreator environment via QSparql QML integration and QtCreator plugins, to allow app developers to rapidly create mashups with the application independent data in Tracker. That data might by combined with data from SPARQL endpoints out on the web that is also retrieved via QSparql. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? (Someone should really summarize these threads in a wiki) Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. Perhaps you can elaborate on this RAD tools elsewhere, say, meego-community mailing list? I have hard time thinking how a RAD tool for sparql would look like, but the thought is intriguing... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 03:01:43 PM Ville M. Vainio wrote: On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. (Someone should really summarize these threads in a wiki) Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. Perhaps you can elaborate on this RAD tools elsewhere, say, meego-community mailing list? I have hard time thinking how a RAD tool for sparql would look like, but the thought is intriguing... Well, RDF stores are just databases that happen to be more general and based on graphs, rather than being based on tables like relational databases. Often you can view RDF data as a table and that works fine. But I don't see any reason why visual development tools for RDF/SPARQL stores should look much different to what people are familiar with from tools like Visual Basic. Or ORM's like NeXT/Apple's Enterprise Object Framework, or the Core Data modern equivalent, that are combined with Interface Builder for visually composing UIs. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On 3/25/2011 8:24 AM, Richard Dale wrote: On Friday, March 25, 2011 03:01:43 PM Ville M. Vainio wrote: On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. my concern is based on the (lack of) progress around QSparql in MeeGo. I'm sure it's all great in Harmattan, but a solid story for MeeGo has so far been lacking. Ideally QSparql becomes a real, full and open source member of the Qt family of APIs. (a solid story also includes proper moving away from older APIs) Until that's there color me a bit skeptical... it's been promised for a long time and hasn't really materialized very well yet. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
Hi Arjen, On Fri, Mar 25, 2011 at 17:30, Arjan van de Ven ar...@linux.intel.com wrote: I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. my concern is based on the (lack of) progress around QSparql in MeeGo. I'm sure it's all great in Harmattan, but a solid story for MeeGo has so far been lacking. Ideally QSparql becomes a real, full and open source member of the Qt family of APIs. (a solid story also includes proper moving away from older APIs) Where exactly your concerns are coming from? http://maemo.gitorious.org/maemo-af/qsparql and http://maemo.gitorious.org/maemo-af/libqtsparql-tracker are alive and available. Development there hapens daily. Developers are available at upstream tracker IRC channel. The code there exactly what is used in Harmattan, packages get built straight out of gitorious.org. Are you concerned that nobody has submitted libqtsparql-tracker for about three months to OBS? QSparql build itself as over a month old. I guess an architecture decision story hasn't really added any assurance at all. Until that's there color me a bit skeptical... it's been promised for a long time and hasn't really materialized very well yet. Code is there open, development is happening openly, and for what it worth, it gets very extensive testing as part of Harmattan application development. Don't tell me that at this level (Tracker - QSparql) testing in MeeGo would be totally different from any other recent GNU/Linux environment. Regarding proper moving away from older APIs, meego-handset-photos hasn't seen any development in gitorious.org since October2010. Where can I find a recent version? -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On 25/03/11 09:11, Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Would it be helpful to have a branch project area on the community OBS? Conceptually this is similar to the Project:DE which is tracking trunk and maintaining an overlay. It may help to show me the code and to maintain patchsets over time as MeeGo:Trunk moves. David/lbt -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
2011/3/23 zoltan@nokia.com: Since lot of time was anyway lost on the subject, and it's an important subject, perhaps it would make sense to consecrate a wiki page to it, including the main use cases to be solved, the solutions proposed, the test data sets involved, test cases used for measuring the solutions (in production type of environment and background load), and then measurements for each solution (eventually on separate pages). This work anyway needs to be done, actually a lot has already been done, so it is not waste of time. It does not need to happen entirely (including all test cases) before Imad's decision, just a few. If you don't like this, just use email or whatever way you want. But let's set a deadline for this preparation until Monday, so that Imad makes a decision on Monday. Meanwhile the work doesn't have to stop. Please also remember that if there is supposed to be a technology selection, your dispute document also has to list people/companies publically committed to the task of implementation/maintenance. Actual contribution/commitment weighs harder than numbers sometimes. Let me draw a parallel. When a feature comes in, there is a query around for who can and wants to invest in implementing and maintaining the feature (at least one release cycle up to a year after the release, in case of very important central feature probably several cycles) as well as QA responsibility. When a assignee/QA is found, the feature is accepted on the roadmap. A feature may cover several modifications in multiple components. At that time when a FEA# is proposed a component developer can pitch investments/commitment from companies to support it through numbers and facts, or take on the sole responsibility himself/herself. It's pretty obvious Intel has knowledge assets and people doing SyncEvolution/EDS already so they would probably not be interested in investing in the alternative. Which means someone else has to do the lifting. We can't ask for Intel's investment into technologies or strong arm them, nor should we. If I was a product manager or TSG looking at the technology choice/selection I would look, even before looking at the numbers, check if there's actual resources listed that will actually do the hard lifting for technology direction and discard the technologies that doesn't have sufficient. And then evaluate based on the facts. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wed, Mar 23, 2011 at 11:53 AM, Dave Neary dne...@maemo.org wrote: Hi, A quick note on meritocracies. Andrew Flegg wrote: According to Imad Sousou at the last TSG meeting[1], the MeeGo Technical Steering Group consists of two seats: * Intel (Imad Sousou) * Nokia (currently vacant after Valtteri Halla left Nokia) Companies typically don't have inherent merit. To cite one example, when Mitchell Baker left AOL (I can't remember whether she resigned or was laid off, it's irrelevant), AOL decided to appoint someone to take over from her as Chief Lizard Wrangler. But Mitchell said Hello, I'm still here - I don't work for AOL any more, but I'm *still* the Chief Lizard Wranger - and people followed her, and not the AOL appointee. I had understood that the TSG was made up of Imad Valtteri, not Intel Nokia. Has Valtteri resigned from the TSG officially? Combined with appointments of companies (whose representatives, with the exception of Yonghui Wang of China Mobile, have not sent even one email to any MeeGo lists) this makes MeeGo look less less like a meritocracy and more more like a collection of corporate partnerships. Dave before you start writing off MeeGo meritocracy you may want to look at all the mailing lists a little more closely. For example, MeeGo IVI had as its second post to the IVI mailing list this missive from myself: http://lists.meego.com/pipermail/meego-ivi/2010-September/01.html Pelagicore had announced itself as a contributor long before we volunteered to officially participate by assuming roles within the IVI project and long, long before we were confirmed in those roles by the TSG. From my personal perspective as Release Manager for MeeGo IVI meritocracy is not a buzz word but the way releases get made - you need code to release after all. I take meritocratic and open governance quite seriously and want it to be clear that I'll always do everything I can to ensure that is the case in MeeGo IVI. snip Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Thu, Mar 24, 2011 at 9:07 AM, Carsten Munk cars...@maemo.org wrote: 2011/3/23 zoltan@nokia.com: Since lot of time was anyway lost on the subject, and it's an important subject, perhaps it would make sense to consecrate a wiki page to it, including the main use cases to be solved, the solutions proposed, the test data sets involved, test cases used for measuring the solutions (in production type of environment and background load), and then measurements for each solution (eventually on separate pages). This work anyway needs to be done, actually a lot has already been done, so it is not waste of time. It does not need to happen entirely (including all test cases) before Imad's decision, just a few. If you don't like this, just use email or whatever way you want. But let's set a deadline for this preparation until Monday, so that Imad makes a decision on Monday. Meanwhile the work doesn't have to stop. Please also remember that if there is supposed to be a technology selection, your dispute document also has to list people/companies publically committed to the task of implementation/maintenance. Actual contribution/commitment weighs harder than numbers sometimes. +1 Let me draw a parallel. When a feature comes in, there is a query around for who can and wants to invest in implementing and maintaining the feature (at least one release cycle up to a year after the release, in case of very important central feature probably several cycles) as well as QA responsibility. When a assignee/QA is found, the feature is accepted on the roadmap. A feature may cover several modifications in multiple components. At that time when a FEA# is proposed a component developer can pitch investments/commitment from companies to support it through numbers and facts, or take on the sole responsibility himself/herself. It's pretty obvious Intel has knowledge assets and people doing SyncEvolution/EDS already so they would probably not be interested in investing in the alternative. Which means someone else has to do the lifting. We can't ask for Intel's investment into technologies or strong arm them, nor should we. ++1 If I was a product manager or TSG looking at the technology choice/selection I would look, even before looking at the numbers, check if there's actual resources listed that will actually do the hard lifting for technology direction and discard the technologies that doesn't have sufficient. And then evaluate based on the facts. +1 BR, -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
Hi Carsten, From: carsten.m...@gmail.com [mailto:carsten.m...@gmail.com Sent: 24 March, 2011 09:08 Please also remember that if there is supposed to be a technology selection, your dispute document also has to list people/companies publically committed to the task of implementation/maintenance. Actual contribution/commitment weighs harder than numbers sometimes. Both solutions have people committed to it. It's pretty obvious Intel has knowledge assets and people doing SyncEvolution/EDS already so they would probably not be interested in investing in the alternative. Which means someone else has to do the lifting. We can't ask for Intel's investment into technologies or strong arm them, nor should we. True, and at the moment they can't rely on Nokia. But Nokia does not control tracker either, most of the tracker guys are external consultants. If I was a product manager or TSG looking at the technology choice/selection I would look, even before looking at the numbers, check if there's actual resources listed that will actually do the hard lifting for technology direction and discard the technologies that doesn't have sufficient. And then evaluate based on the facts. There are two things: 1. For short term, doing the homework: MeeGo needs to maturize as fast as possible, and we need to get the releases rolling with usable content. 2. MeeGo needs to be competitive on the long term, even become the leading innovation platform of the future. Your comment and Intel's decision addressed the first part. But there is a lot of competition out there, which is pulling away on the integrated content handling technologies that e.g. tracker tries to cover (Android by big margin, and I surmise WP7 might have something too), so there should be a long term technology selection plan, too. I just proposed to write down what are our goals (on short and long term if you wish), set measurable criteria, and communicate clearly the short-term and long-term priorities, in an inclusive and not exclusive way. We need to give chance to creativity and alternative solutions. This can be done better than now, and the MeeGo community/TSG/architects have to learn how to do it. [ As a side note, both Intel's and my/our viewpoint is biased. For instance we have had cool plans based on capabilities provided by tracker (among others), which promised good returns for the cost. Then, we didn't have much time and priorities allocated for MeeGo work, but assumed things about it for the future. The technology selection trend here favors the tracker type of integrating technologies, because it's been user experience centric, at least for the (recently lost) future, whereas Intel's has mainly been HW centric. Two different perceptions of MeeGo, projected down into the MW architecture. But we can still have both enabled? As more players join MeeGo, it's important we offer wide range technologies with different weight emphasis on different solutions. ] But I don't want to keep you (and myself) off from work any more. Again, sorry Arjan and others for getting too much involved in this decision, but I guess you can imagine how is it when first your own company cuts the future and then your partner too cuts some of the technologies you are working with and/or assumed to create nice things with, and all this in the way it was done. Best regards, Zoltan smime.p7s Description: S/MIME cryptographic signature ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Thursday, March 24, 2011 06:20:52 PM zoltan@nokia.com wrote: Hi Carsten, From: carsten.m...@gmail.com [mailto:carsten.m...@gmail.com Sent: 24 March, 2011 09:08 Please also remember that if there is supposed to be a technology selection, your dispute document also has to list people/companies publically committed to the task of implementation/maintenance. Actual contribution/commitment weighs harder than numbers sometimes. Both solutions have people committed to it. It's pretty obvious Intel has knowledge assets and people doing SyncEvolution/EDS already so they would probably not be interested in investing in the alternative. Which means someone else has to do the lifting. We can't ask for Intel's investment into technologies or strong arm them, nor should we. True, and at the moment they can't rely on Nokia. But Nokia does not control tracker either, most of the tracker guys are external consultants. If I was a product manager or TSG looking at the technology choice/selection I would look, even before looking at the numbers, check if there's actual resources listed that will actually do the hard lifting for technology direction and discard the technologies that doesn't have sufficient. And then evaluate based on the facts. There are two things: 1. For short term, doing the homework: MeeGo needs to maturize as fast as possible, and we need to get the releases rolling with usable content. 2. MeeGo needs to be competitive on the long term, even become the leading innovation platform of the future. Your comment and Intel's decision addressed the first part. But there is a lot of competition out there, which is pulling away on the integrated content handling technologies that e.g. tracker tries to cover (Android by big margin, and I surmise WP7 might have something too), so there should be a long term technology selection plan, too. Very well put. We have to be 10x better than the competition otherwise we are going nowhere. In my opinion adding another 'data silo' for contacts in the way switching to using EDS would do, is no better than being 1x the competion although it might be the less risky option in the short term. I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely broken with respect to sharing data between applications. As far as I know, each application is expected to have its own way of storing data and there are obvious real problems with that simplistic way of hiding the Unix file system from users. I don't get the impression that Android is much better. If we are comparing Tracker with EDS we are not comparing like with like. The problem is that we haven't got as far as implementing elegant RAD tools that allow applications to make use of the linked cross-application data in Tracker. Nor have we got as far as making use of the fact that local RDF data can be combined with data stores out on the web. For instance, you may have some music album with metadata stored in Tracker and might like to make a query to web based SPARQL endpoints such as DBpedia for further info. The RDF linked data approach allows ontologies to be linked via mechanisms such as 'SKOS' (in SQL terms I would describe that as a way of making one database schema map onto another). That way we can link local personal Nepomuk data with web based RDF resources, such as FOAF or whatever, that are out on the web of linked data. We are talking revolution here, and certainly Intel might not have the resources to make that happen in-house, but why should that slow down the community based MeeGo project? -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wed, Mar 23, 2011 at 08:23, zoltan@nokia.com wrote: It looks like it was an internal Intel decision (or at least without Nokia). I can't blame you on that, but if the governance model changed in the background, would you state that on meego.com, just to avoid fights coming from false assumptions? According to Imad Sousou at the last TSG meeting[1], the MeeGo Technical Steering Group consists of two seats: * Intel (Imad Sousou) * Nokia (currently vacant after Valtteri Halla left Nokia) Nokia are in the process of nominating someone else[2]. It sounds like these decisions were made by *part* of the MeeGo Architecture team. as no public announcements about changes to the governance structure have been made and - as half of the TSG - Nokia is still a partner. Imad also indicated that the TSG would grow - presumably in response to Nokia's board's decision[3]. However, it would be sensible to remember that this is a decision that Nokia's *board* took; not the employees of Nokia who were - and are - participating in MeeGo. The latent hostility coming through from some !@nokia.com addresses is unbecoming. Cheers, Andrew [1] http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-03-18-14.58.html [2] http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meeting.2011-03-18-14.58.log.html#l-116 - from 15:32 onwards [3] ...and presumably to give valhalla a seat again when he joins Intel. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wednesday, 23 de March de 2011 08:41:35 Andrew Flegg wrote: Imad also indicated that the TSG would grow - presumably in response to Nokia's board's decision[3]. However, it would be sensible to The growing of the TSG is to give room for others making investments and shipping (or going to ship) MeeGo devices. If you look at the minutes of the TSG meeting, you see lots of names of joining for STB and IVI work. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
From: Andrew Flegg [mailto:afl...@gmail.com] Sent: 23 March, 2011 10:42 [1] http://trac.tspre.org/meetbot/meego-meeting/2011/meego- meeting.2011-03-18-14.58.html [2] http://trac.tspre.org/meetbot/meego-meeting/2011/meego- meeting.2011-03-18-14.58.log.html#l-116 - from 15:32 onwards Thanks, it was a good read, probably I should have find it myself. But how does that change http://wiki.meego.com/Architecture ? TSG might miss a Nokia member, but architects and the process are still in place. The latent hostility coming through from some !@nokia.com addresses is unbecoming. Hostility? No, mostly confusion and question marks. There were technical arguments. And I also care about MeeGo (OK, mostly for the handset/tablet part, but still :). But I assume hidden decisions about critical architecture issues quickly made in an interregnum would ring some bells for you too, in an inverse situation? Especially when questions and arguments are ignored after? Is that the way MeeGo is supposed to work? I don't think that would attract too many contributors. Even if I am stamped hostile against this, doesn't change it. Anyway, important is to have a working architecture and right solutions for the problems. I hope these can still be discussed. I stop here. Regards, Zoltan Cheers, Andrew [1] http://trac.tspre.org/meetbot/meego-meeting/2011/meego- meeting.2011-03-18-14.58.html [2] http://trac.tspre.org/meetbot/meego-meeting/2011/meego- meeting.2011-03-18-14.58.log.html#l-116 - from 15:32 onwards [3] ...and presumably to give valhalla a seat again when he joins Intel. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ smime.p7s Description: S/MIME cryptographic signature ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wed, Mar 23, 2011 at 09:20, zoltan@nokia.com wrote: The latent hostility coming through from some !@nokia.com addresses is unbecoming. ^ Hostility? No, mostly confusion and question marks. Sorry for the confusion, please see the !. I was trying to respond to Arjan's: On Tue, Mar 22, 2011 at 21:44, Arjan van de Ven ar...@linux.intel.com wrote: The MeeGo architecture team made these decisions in consultation with the various handset and tablet architects. I know it's not popular with you and some other @nokia.com folks... but so be it. I was trying to be more polite than phrasing this as: Intel seem to be throwing stones at Nokia people, just because Nokia's board made a decision. That's not very professional. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
Hi, A quick note on meritocracies. Andrew Flegg wrote: According to Imad Sousou at the last TSG meeting[1], the MeeGo Technical Steering Group consists of two seats: * Intel (Imad Sousou) * Nokia (currently vacant after Valtteri Halla left Nokia) Companies typically don't have inherent merit. To cite one example, when Mitchell Baker left AOL (I can't remember whether she resigned or was laid off, it's irrelevant), AOL decided to appoint someone to take over from her as Chief Lizard Wrangler. But Mitchell said Hello, I'm still here - I don't work for AOL any more, but I'm *still* the Chief Lizard Wranger - and people followed her, and not the AOL appointee. I had understood that the TSG was made up of Imad Valtteri, not Intel Nokia. Has Valtteri resigned from the TSG officially? Combined with appointments of companies (whose representatives, with the exception of Yonghui Wang of China Mobile, have not sent even one email to any MeeGo lists) this makes MeeGo look less less like a meritocracy and more more like a collection of corporate partnerships. This has benefits too, don't get me wrong - there's nothing inherently wrong about an Eclipse Foundation-type trade association, but it is not what has been announced reiterated, and what I believed the project leaders wanted the project to become. If the nature of the MeeGo project changed on February 11th, it would be nice to know. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
Am Mittwoch, den 23.03.2011, 08:41 + schrieb Andrew Flegg: However, it would be sensible to remember that this is a decision that Nokia's *board* took; not the employees of Nokia who were - and are - participating in MeeGo. The latent hostility coming through from some !@nokia.com addresses is unbecoming. Thank you for pointing this out. Actually I am quite worried how arguments from people who got their hands dirty for years in PIM domain are ignored easily, simply because they are from the other team. Where is the good old assume people mean well? Arjan, did you ever consider that those Nokia people raising concerns here, are smart and dedicated persons that really care about MeeGo? Ciao, Mathias -- Mathias Hasselmann math...@openismus.com http://openismus.com/ ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wed Mar 23 2011 05:36:42 PM EET, Mathias Hasselmann math...@openismus.com wrote: Am Mittwoch, den 23.03.2011, 08:41 + schrieb Andrew Flegg: However, it would be sensible to remember that this is a decision that Nokia's *board* took; not the employees of Nokia who were - and are - participating in MeeGo. The latent hostility coming through from some !@nokia.com addresses is unbecoming. Thank you for pointing this out. Actually I am quite worried how arguments from people who got their hands dirty for years in PIM domain are ignored easily, simply because they are from the other team. Where is the good old assume people mean well? Arjan, did you ever consider that those Nokia people raising concerns here, are smart and dedicated persons that really care about MeeGo? Guys, I think this discussion and (passive?) agressiveness has gone on for too long. I would propose that if you have a problem with decisions made, present a dispute to the TSG stating your exact objections, potential solutions to the issue and let it be evaluated and let the answer to the dispute from TSG be the final word. It is a role of the TSG to solve these kind of disputes. We can't be bogged down with flamewars forever and we do need to make sure that when a decision is made by people nominated in roles where they should make the hard decisions, it is followed. Or we'll go nowhere with MeeGo. Before any of you point out that Imad from Intel is the only person in TSG at the moment, that TSG meetings are public and that decisions made are public record. I personally trust that Imad will be objective and resolve the dispute properly. Best regards, Carsten Munk MeeGo N900 hardware adaptation maintainer Ciao, Mathias -- Mathias Hasselmann math...@openismus.com http://openismus.com/ ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wed, Mar 23, 2011 at 6:09 PM, Carsten Munk cars...@maemo.org wrote: Guys, I think this discussion and (passive?) agressiveness has gone on for too long. I would propose that if you have a problem with decisions made, present a dispute to the TSG stating your exact objections, potential solutions to the issue and let it be evaluated and let the answer to the dispute from TSG be the final word. It is a role of the TSG to solve these kind of disputes. +1 We can't be bogged down with flamewars forever and we do need to make sure that when a decision is made by people nominated in roles where they should make the hard decisions, it is followed. Or we'll go nowhere with MeeGo. Not trying to troll, but you sent this email just when I was about to email my thoughts and ask about my concerns for where MeeGo is heading. Before any of you point out that Imad from Intel is the only person in TSG at the moment, that TSG meetings are public and that decisions made are public record. I personally trust that Imad will be objective and resolve the dispute properly. ++1 I'd also like to add that regardless of way the new architectural decisions were made, he's communication of the decision was excellent IMHO. I'm not sure this was not like this before, but his announcement was first of kind for me at least following the project Sometimes you need to use 'older' wheels and improve them until exhaustion before recreating them... and I think his approach could not be more healthier for the project not to mention improve release schedule and feature completeness per release. Also another note that I am trying to make through for a while about using wiki specs like Ubuntu does. I know that there's bugzilla. I don't think there could be worser tool to track specifications, not allowing you insert inline photos and images like in a proper wiki. I would like again, to propose using specs to plan ourselves ahead. it caters for easy to reach documentation (bugzilla couldn't be worse in that regard as well) for wide participation (everybody uses wiki's this days, bugzillas coward even me at times). I feel there is great objection to use proven tools and methodologies from other projects that evolved over the conservative ways of work of the open source projects of the 70s, like Ubuntu , Debian, Linaro and others similar. I can't understand why. I will try to serve as an example with my projects, but it would be great to have this for the core arch of meego. I fantasize of reading through the spec like Linaro has, understanding why decisions were made, how, what did they affect and how they are implemented. Architectural overview like we have is nice, maybe for a vendor decision maker, but not for someone interested and the bolts and bulbs of some inner subsystem like the watchdog, or DSME (we keep getting question about it , as Jeremiah asked not long ago) or policy kit etc. If those have specs upstream, then we should link them for easy access. I ask you, is it feasible to have a spec like I linked from the email I sent some time ago (a spec with drawing and charts together with text ). Or better, hover to linaro's wiki and wander through the other specs. I think if we work that way, this would be a leap forward and how we architect meego. Also, in conferences we should have bofs per spec to discuss with the people involved of its design and attack plan for implementation. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
From: Carsten Munk Sent: 23 March, 2011 18:09 I think this discussion and (passive?) agressiveness has gone on for too long. I would propose that if you have a problem with decisions made, present a dispute to the TSG stating your exact objections, potential solutions to the issue and let it be evaluated and let the answer to the dispute from TSG be the final word. It is a role of the TSG to solve these kind of disputes. We can't be bogged down with flamewars forever and we do need to make sure that when a decision is made by people nominated in roles where they should make the hard decisions, it is followed. Or we'll go nowhere with MeeGo. Before any of you point out that Imad from Intel is the only person in TSG at the moment, that TSG meetings are public and that decisions made are public record. I personally trust that Imad will be objective and resolve the dispute properly. Hello, Thank you for stepping in with this proposal. This is the way to solve it and it should have been applied already earlier. I perfectly agree with you. Since lot of time was anyway lost on the subject, and it's an important subject, perhaps it would make sense to consecrate a wiki page to it, including the main use cases to be solved, the solutions proposed, the test data sets involved, test cases used for measuring the solutions (in production type of environment and background load), and then measurements for each solution (eventually on separate pages). This work anyway needs to be done, actually a lot has already been done, so it is not waste of time. It does not need to happen entirely (including all test cases) before Imad's decision, just a few. If you don't like this, just use email or whatever way you want. But let's set a deadline for this preparation until Monday, so that Imad makes a decision on Monday. Meanwhile the work doesn't have to stop. I am only indirectly involved in the issue, sorry for making too much noise and taking your time away. Basically we can do either way with more or less trouble, just need to make sure it is the right solution, and give chance to the other solution(s) to improve against known requirements. Best regards, Zoltan Kis -- Senior Architect, People Experience (Telephony, VoIP, Instant Messaging, Presence) Meego Devices, Nokia smime.p7s Description: S/MIME cryptographic signature ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Wed, 2011-03-23 at 11:53 +0100, Dave Neary wrote: Hi, A quick note on meritocracies. Andrew Flegg wrote: According to Imad Sousou at the last TSG meeting[1], the MeeGo Technical Steering Group consists of two seats: * Intel (Imad Sousou) * Nokia (currently vacant after Valtteri Halla left Nokia) Companies typically don't have inherent merit. To cite one example, when Mitchell Baker left AOL (I can't remember whether she resigned or was laid off, it's irrelevant), AOL decided to appoint someone to take over from her as Chief Lizard Wrangler. But Mitchell said Hello, I'm still here - I don't work for AOL any more, but I'm *still* the Chief Lizard Wranger - and people followed her, and not the AOL appointee. I had understood that the TSG was made up of Imad Valtteri, not Intel Nokia. Has Valtteri resigned from the TSG officially? Combined with appointments of companies (whose representatives, with the exception of Yonghui Wang of China Mobile, have not sent even one email to any MeeGo lists) this makes MeeGo look less less like a meritocracy and more more like a collection of corporate partnerships. This has benefits too, don't get me wrong - there's nothing inherently wrong about an Eclipse Foundation-type trade association, but it is not what has been announced reiterated, and what I believed the project leaders wanted the project to become. If the nature of the MeeGo project changed on February 11th, it would be nice to know. Dave, I think you're dramatising here. Companies might not have inherent merit, but maintainers, be it an individual or a corporation, have /actual/ merit in an open source project. When the roof is on fire, the maintainer may have to step up and make decisions, regardless how unpopular they might be. It is his (intellectual and/or financial) investment that is on stake, and it is the maintainer who has to take responsibility on the outcome of a project. I don't want to rebuff criticism globally, but on meego-dev it's always about the meritocracy aspect, never about the maintainer aspect. MeeGo is still very young by any account, meritocracy is not something you build up in a few months. This is my personal opinion, I'm not a manager or leading engineer, well, except for leading characters into my text editor. - Rob ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
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
