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

Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]

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

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.

Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

Attachment: pgpMJtBkw8VUI.pgp
Description: PGP signature

Reply to: