Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
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 <cbyrum@spamaps.org>
Reply to: