Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 03:45 -0700, Steve Langasek escreveu:
> On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
>
> > look ... i don't want guaranties ... you know what i mean ... want a
> > place where it says "testing HAS security support, we focus on having it
> > stable. I don't want written contract ... i want a desktop user to
> > discard stable and use testing. For that debian needs do publicly advice
> > the use of testing in these cases ... and i mean for real.
>
> You are never going to get a statement from the Debian project telling users
> to use one suite or another (or at least, you shouldn't); the most we should
> be doing is giving users a list of pros and cons for each suite and letting
> them decide which fits their needs. I'm all in favor of reducing the number
> of decisions users have to make *in the software* :), but on something as
> high-level as which distro/suite to use, misestimating a user's needs is the
> kind of thing that will sour the user on Debian for a very long time.
Yes, but debian *only* publicites the use of stable (that home users or
desktop users tag as "stale"). If you publicity say that testing (or
maybe this should be renamed :( ) is the way for an up-to-date, latest
software distribution , then they will use it.
for now it only states that testing is ... testing, right?
>
> > > There is a testing security team that addresses unembargoed security issues
> > > in testing. Fixes for embargoed security issues are generally not prepared
> > > in advance for testing. However, more people have access to work on the
> > > unembargoed security issues anyway (in the general case: anyone can upload
> > > to t-p-u), so it's not definite that stable is always more secure than
> > > testing.
>
> > So, maybe, have more strict upload rules? Or, on the other way,
> > maintainers can upload packages directly into testing (from t-p-u?).
>
> More strict upload rules for what?
To have security updates in testing, easily and stable ... not to
upgrade a new version into testing that can break stuff, or some mixed
unstable and testing upload.
>
> > > > - Testing simply moves too fast and the automatically passage process
> > > > between unstble and testing *DOES* break testing. For one example,
> > > > package "foo" requires package "bar<=0.3" but package "bar 0.4"
> > > > automatically passes to testing.
>
> > > Um, no. That does not happen automatically. In rare cases it happens
> > > because the release team has overridden the installability check for a
> > > package, because maintainers have not coordinated their transitions in
> > > unstable and as a result something needs to be broken to ever get any of the
> > > packages updated because you can't get 300 maintainers to get their packages
> > > in a releasable state *and* leave them alone long enough to transition to
> > > testing as a group.
>
> > So please, don't do those "oh, let them pass" transitions ... they BREAK
> > stuff ... for real.
>
> What?
Some packages are allowed to pass into testing even if other depends on
it, but has issues that will take some time to resolve. This will make
that that package, that is now in testing, will not be installable in
anyway. This happens sometimes.
>
> > > That's a problem of the packaging of those kernel modules, then, not a
> > > problem of testing per se; even if you track stable and therefore the
> > > problem only affects you once every two years, it's still a problem that
> > > should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686
> > > (oh look, this one already exists).
>
> > kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
> > time (they are not free, right?) ... kernel passes to testing ...
>
> That doesn't happen.
well ... it happened to me before etch was released ... in such a way
that i gave up using them.
>
> > this is a simple upgrade ... because kernel packages are always NEW, the
> > kernel will pass because it has no reverse dependency problems in
> > testing.
>
> False.
true.
nvidia-kernel (meta packge) depends on linux-image-2.6.10.
a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did
not pass because it is too young.
nvidia-kernel is unusable.
Or the user reboots with the new kernel, or edits by hand the
xorg.conf .
I used testing since about 3 months after sarge was released ... it was
quite stable, but some transitions broke my system and it should not
happen.
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> vorlon@debian.org http://www.debian.org/
>
>
Reply to: