Your message dated Fri, 28 Feb 2014 22:26:04 +0100
with message-id <[email protected]>
and subject line Re: Bug#594461: apt-setup: Should propose using t-p-u when
testing is installed
has caused the Debian Bug report #594461,
regarding apt-setup: Should propose using t-p-u when testing is installed
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
594461: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594461
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: apt-setup
Severity: wishlist
After a (short) discussion in -devel, I came up with the proposal of
activating "testing-proposed-updates" when users install testing, in a
similar way that we currently propose activating volatile when they
install stable.
So, sending this as a bug report against apt-setup. I suggest this is
done post-squeeze.
Quoting Paul Wise ([email protected]):
> On Wed, Aug 25, 2010 at 6:38 PM, Christian PERRIER <[email protected]> wrote:
> > Quoting Russ Allbery ([email protected]):
> >
> >> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
> >>
> >> Mostly because there isn't any large pool of systems using t-p-u the way
> >> there is for unstable, so the aging process where we get testing in
> >> unstable before migrating the package never happens. This means uploads
> >
> > I wonder whether we (in D-I) could add t-p-u to the list of proposed
> > repositories when users install testing. We already propose security
> > and volatile (defaulting to both added): the same mechanism could be
> > made for t-p-u when users install testing.
>
> Sounds like a good idea to me. When they reject t-p-u you could either
> add it commented out or with pinning such that it is not selected by
> default but when packages from it are selected then they are kept
> upgraded within it until the packages migrate to testing itself. AFAIK
> to achieve that you need pinning priorities > 500 and < 1000.
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
>
>
> --
> To UNSUBSCRIBE, email to [email protected]
> with a subject of "unsubscribe". Trouble? Contact [email protected]
> Archive:
> http://lists.debian.org/[email protected]
>
>
>
> ** CRM114 Whitelisted by: WHITELIST **
>
--
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Joey Hess <[email protected]> (2010-08-26):
> Does it really make sense for users to use t-p-u? Anything can be
> uploaded there, rejected by the release team, and no upgrade path is
> necessarily provided for a system that installed a package from there
> and ends up tracking stable.
Since t-p-u → testing is an approve hint away (on the release team
side), and since virtually anything can be uploaded there as Joey
mentioned, I don't think it should be enabled by default. Good packages
will probably flow to testing quickly, while bad packages will get
filtered out.
(Another way of saying this is that t-p-u is an implementation detail
for packages to reach testing without having to migrate from unstable.
We generally try very hard to avoid going that route anyway.)
Closing this bug report accordingly.
Mraw,
KiBi.
signature.asc
Description: Digital signature
--- End Message ---
