Hello, Before this topic goes way over it's significance:
This happened because on certain product driven projects we are still using mentioned PA 0.9.19 and Policy framework that is integrated to that specific PA version. That is not something to be proud of, but it is rather the reality of life in product scope. So far, the biggest known impact of this decision is that we need to fix voice call implementation on N900 adaptation, but that is rather trivial exercise. In fact we had more problems when we enabled that stuff on PA 0.9.21 for MeeGo 1.1. We have done at least 95% of that work already, so we will introduce Policy framework with N900 adaptation shortly after PA is downgraded. So we are in fact waiting this change to happen, the objection from our side on this list was more related to naming convention and process itself. It may be, that someone else has done some work based on PA .21, but now the most important thing is to get Policy framework implemented together with PA, because in a sense those two are the brains of audio routing and some similar things on the stack. See my other comments below >From: Arjan van de Ven [[email protected]] >Sent: Wednesday, December 22, 2010 8:41 PM >On 12/22/2010 10:23 AM, Shane Bryan wrote: >> On Wed, 22 Dec 2010 14:26:27 +0800 >> "Zhang, Vivian"<[email protected]> wrote: >>> It is a business decision of reversion PA to 0.9.19 for integrating >>> voice call features on handset, >> While I don't doubt the veracity of the decision, I wonder why, yet >> again, it seems that a PROJECT impacting change was discussed and >> decided behind the "closed doors" of a PRODUCT schedule and >> requirements? I am probably just being naive... >very valid point. This should have been communicated better, because there was no reason not to do that. Perhaps part of that blaim belongs to me, because this is after all notable technological change on N900 based MeeGo 1.2 reference implementation. >From my part of view I am sorry that I didn't realize that I should have done my part of that communication. >> Never-the-less, the newsletter makes no mention of how or why the >> decision was made... which I would never think to expect for PRODUCT >> specific communications, but since this decision impacts the PROJECT as >> a whole, it ought to have been proposed and vetted out publicly (maybe >> as an RFC) so the full extent of both the technical and perceptual >> impacts can be exposed and considered. Again, I am probably just being >> naive still... Little bit of naive, because you know as well as the rest of us, that we need to get some products out in time to get all of this cool Meego work paid and justified as large. However, the decision making process and related communications should clearly have been done on open. >I think the situation is that someone had a lot of patches against pulse >audio 0.19, including policy framework integration, >and goofed in not getting their code upstream fast enough. That's very >embarrassing of course, and I think the flogging that >is happening in this thread is a clear indication of how embarrassing it >is... >but for the project, we need that integration to have any kind of viable >integration of policy framework with audio. >This going back one version is ONLY for 1.2... for 1.3 we'll be at a >more current version of PA again, since the embarrassment of not >making that would be so huge that not just the people of the patch set >look bad, but the whole of MeeGo would be the laughing >stock of the whole open source community. Thanks Arjan, what you said is valid as whole, and I certainly hope that we have learned something about this and that we are able to get our homework done on this for MeeGo 1.3. Br, //Harri _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
