On Mon, Mar 07, 2005 at 09:13:20AM -0800, Clint Byrum wrote: > I feel your pain. Its hard to keep all these buildd's for different > architectures up. That goes to the very heart of my point. > > I'm not saying Debian should totally abandon all the work done by the > various architecture teams. But to have them all dependant on eachother > creates complexity, and complexity breeds problems. > > Please understand.. I want Debian to be great. I want it to "release > when it is ready." Under the current system, being ready means achieving > an enormous number of goals that benefit a very small number of users. For the mass market see http://fedora.redhat.com/ - Debian/GNU/Linux has a more import idiology than to look for the masses. IMHO the real problem is that with the introduction of the Package Pools the focus was dragged from the released instead of pushing towards it. If i would have designed the release/package policy i would have made a release cycle which after a freeze date would only have packages accepted to the pool/release for bug fixes and NOTHING else. Drop unstable/testing alltogether. When starting with the next "to be release" name it like this and let it go for 12 Months as "unstable". Freeze - name it testing. Release after 3 Months without accepting new packages or having unstable. With this policy developers resources would have been focused on the spot. If i cant really work on my packages i might take a look at other people bugs. IMHO the number of architectures is not the real problem of release cycles. BTW: I can live with release cycles of 2-3 Years very good. As an admin of ~500 Machines i am happy not to upgrade every 6 Month. Flo -- Florian Lohoff email@example.com +49-171-2280134 Heisenberg may have been here.
Description: PGP signature