On Wed, Jan 09, 2008 at 03:58:45PM -0500, Adam Jackson wrote: > > Linux is about choice. > > The complaints up-thread about juju and pulse are entirely valid, but > the solution is not to try to deliver two things at once. If you try to > deliver both at once you have to also deliver a way of switching between > the two. Now you have three moving parts instead of one, which means > the failure rate has gone up by a factor of _six_ (three parts, and > three interactions). We have essentially already posited that we have > insufficient developer effort to have 100%-complete features at ship > time, so asking them to take on six times the failure rate when they're > already overburdened is just madness. Alternatively, we could say that Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue? > worse than the old stack. But the chain of logic from "Linux is about > choice" to "ship everything and let the user chose how they want their > sound to not work" starts with fallacy and ends with disaster. This is right. But care should be taken not to shift from constraining the user to constraining the developper. We should ship everything that a contributor has interest in maintaining. It should not be at the expense of innovating, so breaking some packages some time because they are not ready for changes in other packages is acceptable (in rawhide). In the design of new feature, however existing stuff should be taken into account such that, if possible, previous habits are still possible and there are no regression. Developpers of new features should look at it, even to discard it, in fedora I see too much 'this is old cruft no need to look at it is broken by design' even when it is untrue. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
