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

Re: Two proposals for a better Lenny (testing related).



Ter, 2007-06-12 às 17:03 -0700, Steve Langasek escreveu:
> On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:
> > Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu:
> > > Personally I think the current system is fine.
> 
> > just a note, as user:
> 
> > The current system is fine but:
> >  - priority from unstable should less than testing or stable ( as i
> > think - not for sure - happens nowadays). On experimental has less
> > priority.
> >  - There are no guaranties that testing is always working and stable.
> >  - there are no guaranties that testing is secure (please security team,
> > can you clarify this?)
> 
> You won't find a contractual guarantee from Debian about either of these
> things, for *any* of the Debian suites.

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.
> 
> 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?).

> >  - There are no public, announced, snapshots from testing (so people can
> > download and install).
> 
> Other than the d-i betas?

yes ... for example, every 6 months ... all teams can organize to ship a
preview release of debian. Teams will know that day X at Y time  full
set of cd's will be built. so teams will have +/- stable packages in
testing and debian will have an automatic version.
d-i "per se" is not a debian release.

This will give users another view of debian.
For example, debian "lenny preview A" would be announced and people
would install it and test it. Otherwise, no one will use it.
> 
> >  - 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.
> 
> (... and this is why getting rid of experimental is a horrible idea.)

i think we cannot give up of experimental ... it's a place for ...
experimental packages and preview packages (samba 4, for example),
> 
> >  - Smooth passages are not always smooth (who had a working xorg after
> > the upgrade for 7, please raise their hands)
> 
> <raises hand>
you lucky person.
> 
> :)
> 
> >  - kernel modules simply die, when the kernel is upgraded, but the
> > modules aren't ( people using non-free nvidia modules, raise their
> > hands; people using wifi modules raise their hands)
> 
> 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 ...
automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ...
after a reboot, my xorg server will not run... when it used to.

this is a simple upgrade ... because kernel packages are always NEW, the
kernel will pass because it has no reverse dependency problems in
testing.
And, just a note ... we are talking about testing, not stable.
> 
> > So ... automatically pass to testing ... is bad.
> 
> Invalid premise -> invalid conclusion.

it's not invalid ... it's valid by the reasons above.
> 
> > So ... more package tests are need (such as test reverse depends)
> 
> What do you mean?

i mean that the passage f packages from unstable to testing needs to be
more difficult. 
for example, if a package has, for example, important or serious bugs,
should not pass to testing,even if it has security issues ... because it
will break testing.

> 
> -- 
> 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: