2011/3/23 <[email protected]>: > 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 [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
