On Fri, 2012-04-27 at 14:22 +0200, David Henningsson wrote: > On 04/26/2012 12:49 PM, Tanu Kaskinen wrote: > > One of the [[Software/PulseAudio/GSoC2012|Google Summer of Code project > > ideas for 2012]] was a "configuration system". The configuration system > > was not among the selected projects, but the system was seen as a > > priority, > > While I believe that this will probably be something nice to have, on my > end I don't see this project as a priority. > > For me, I would prioritise the stuff that's long overdue: > > * Get 2.0 out the door I agree that this should be the top priority. The reason why I worked on something else than the blocker bugs is is that there's not much to do with the three blocker bugs: I'm waiting for more feedback from the alsa guys regarding the 4-channel input proposal before sending the final version of the fix for [1], and I'm waiting for more feedback about the fix for [2] (now that I have your and Arun's comments, though, I think I'll push the fix soon - do you want to check the final patches before that?). I expect [3] not to get fixed for 2.0. The configuration system proposal was something that I promised to do, and I haven't made any other promises, so that's what I prioritized above everything else. [1] https://bugs.freedesktop.org/show_bug.cgi?id=45813 [2] https://bugs.freedesktop.org/show_bug.cgi?id=47156 [3] https://bugs.freedesktop.org/show_bug.cgi?id=47158 > * Review/merge the UCM stuff > > * Implement Colin's priority list routing > > But if it's really a prerequisite to make the GSoC students productive, > I guess there isn't much choice than to get it up and working really fast... I don't see it as a prerequisite. I see it as a way to save work and save us from more protocol updates and client API extensions that shouldn't be needed. > >so the plan now is to design and implement the important bits > > (the client API and the server-side infrastructure) ourselves within May > > 2012 or so (the reason for the tight schedule is that we'd like the GSoC > > students to benefit from this new system). Porting the existing > > configuration to the new system is not a matter of urgency. All the > > existing stuff has to be kept in mind while doing the design, though, so > > that the porting work is possible to do when that time comes. > > Is there a plan for making "when that times comes" != "never"? This is > not meaning to be sarcastic - more I'm being curious about your thoughts > on the topic. No plan as far as I know. -- Tanu
