RFC: Configuration system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux