Re: Freezes and order of things



<quote who="Christian Fredrik Kalager Schaller">

> One thing that struck me today is that we have a proposal for polypaudio
> to replace esound. This change will necessarily demand some hacking on
> core modules to make it happen. Yet the decision on wether to do the
> replacement is being taken after the freeze. In my opinion this means 
> a) the decision should be taken ASAP
> b) in the future we probably want the release team to make their
> decisions before the feature freeze  :)

I think the critical mistake we made with the schedule this time around was
to clump a bunch of freezes together, resulting in the part of the above
problem, and quite a bit of confusion as to what the freeze state actually
is. I don't think we'll do that again. :-)

However, I think most of the problem with the polypaudio question was
decision making gridlock. A few people loudly opposed it, while in general
it is a better replacement for something we already ship. Because of the
gridlock, no one wanted to do the (perhaps controversial) work to make it
happen. This is kind of unfortunate.

- Jeff

-- 
linux.conf.au 2005: Canberra, Australia                http://linux.conf.au/
 
                        Great minds think different?



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