Re: Some observations regardig the progress towards Debian 3.1
On Wed, 19 Nov 2003, Adrian Bunk wrote:
> On Wed, Nov 19, 2003 at 05:34:53PM +0200, Martin-Éric Racine wrote:
> > * In relation to this, Mozilla 1.3 (IMHO, the last rock-solid built
> > we've had on Debian) was good enough for Testing and should have been
> > allowed to trickle down, instead of being constantly replaced by
> > progressively buggier 1.4 and 1.5 releases. While the novelty factor of
>
> How do you back your statement that 1.4 and 1.5 are "progressively
> buggier" than 1.3?
Slower starts, clunkier and more sluggish operation, quickly slows the whole
systme to a crawl because of its ever increasin memory usage over a session.
> > My solution to this is as follow:
> >
> > 1) Only build packages against dependencies that already are in
> > Testing, always. If a new package (e.g. a new Evolution from upstream)
> > depends upon libraries or a version thereof not yet in testing, build
> > the said library against the glibc and other dependencies in Testing,
> > then build Evolution against that, then uploaded them both to Unstable
> > for their 14-day processing. This should guarantee that Testing always
>
> As said above, there is no "14-day processing"...
Whatever. It could be 50-20-5, I could care less about the exact timeframe.
You still haven't commented on the overall idea of always building upon libs and
other dependencies already in Testing, instead of building on, say, a glibc that
is in unstable, preventing a few hundred of packages from sliding into testing,
as it happened a few months ago.
> > is in a releasable state, since everything in it is only built against
> > the libraries it offers.
>
> Besides other problems, one RC bugs in the chain of packages will cause
> your proposal to fail.
Actually, no.
> > 2) unstable
> >...
> > * Trusted packages entering Debian for the first time and which were
> > built against Testing dependencies also enter the release chain here.
> > New releases of Evolution based upon GTK2 would fit into this category.
>
> The way testing works, this might effectively make it impossible for new
> so-version of libraries to ever enter testing...
This was a proposal to _change_ the way it works.
> > 4) stable
> >
> > Remains as conservative as before. Only receives uploads that fix RC
> > bugs on its existing packages.
>
> That's wrong.
>
> The rules for stable are stricter than "fix RC bugs". Except selected
> exceptions, only security fixes are allowed.
This was a proposal to _improve_ the way it works. Allowing RC fixes, not just
critical security advisories, would still be highly conservative, but would
allow for a more robust Stable as well.
> > Hopefully, the above made sense.
>
> No.
Then you might as well stop complaining that nobody has any solutions to improve
things, if you focus on nitpicking where people missed a spot on how the actual
system currently works, instead of hearing out what solutions they have.
You should also move to have the "end-users matter" part crossed out of Debian
project, instead officially calling it for the hackers-only user-hostile bloat
that it really is, and issue a press release about that.
Then spend the next 10 years wondering why the masses still ignore Debian and
prefered switching from Red Hat to Fedora (despite the FUD about its future) or
continue choosing other distributions over Debian.
Spend the same amount of time wondering why the average user would feel better
if Debian developpers had added support for non-Intel architectures to Anaconda
or to PGI, instead of spending 3 years _trying_ to reinvent the wheel and still
coming up with something that is barely any better than Woody's floppies, from
an end-user's perspective.
Anyhow, I don't intend on wasting any further time on this thread. I read what I
needed to know and got to notice, once again, what makes Debian so despicable.
--
Martin-Éric Racine, ICT Consultant
http://www.pp.fishpool.fi/~q-funk/
Reply to: