On Mon, 2005-03-07 at 20:33 +0100, Florian Lohoff wrote: > 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. >
So if 90% of users are held back by 10% of users (and I know thats not the big thing holding it back, bear with me!).. thats ok because we are sticking to our ideals? Where in the Debian ideal does it say "everybody has to be happy"? Is Debian becoming like U.S. schools with the "zero tolerance policy" attitude? > 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. > Well said. > 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. > I guess I see it as low hanging fruit. The other problems are more difficult to change. De-prioritizing those arches would help right away, and cause minimal impact to most Debian users. How much would it help with the current problems if we just picked 3 arches(mipsel, s390, ???) and said "these are not going to release with the rest of sarge"? Would it reduce the time to test the installer? Any RC bugs that were filed for those arch specific problems would be ignored.. would that be a lot? If the answer truly is "it would not help at all" then I'm done with this thread of discussion, and I'll just have to eat some crow. :) > 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. > Life cycles of 2-3 years is good (even more really.. 5 years is really ideal). But release cycles should be shorter. If you want to use debian, you have two choices right now. 3+ years old, and stable, or bleeding edge. Its amazing how much things have advanced since woody was released. MySQL 4, apache 2, 2.6 kernel. Some of these things can save you real money in a server farm. Of course, stability will save you a lot more money than performance, but we should be able to get both! It would be nice to have the choice between staying with my 3+ year old woody box, and moving up to a newer installation. Right now I don't see running sarge in production as a very easy thing to do. It certainly wouldn't feel as solid as woody does. Finally.. I'll say this because I haven't yet. If there is anything a scripter/sysadmin can do to help, I'll do it. That includes shutting up. ;) I don't have a ton of time, but I'm willing to donate what I can to the project to help. -- Clint Byrum <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
