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

Bug#594461: marked as done (apt-setup: Should propose using t-p-u when testing is installed)

Your message dated Fri, 28 Feb 2014 22:26:04 +0100
with message-id <20140228212604.GA7480@mraw.org>
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 owner@bugs.debian.org
immediately.)


-- 
594461: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594461
Debian Bug Tracking System
Contact owner@bugs.debian.org 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 (pabs@debian.org):
> On Wed, Aug 25, 2010 at 6:38 PM, Christian PERRIER <bubulle@debian.org> wrote:
> > Quoting Russ Allbery (rra@debian.org):
> >
> >> > 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 debian-boot-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/AANLkTinBF2Ktsg7ppwmv4CNz74WvhDj2vKFQ3n9wFkDn@mail.gmail.com
> 
> 
> 
>  ** CRM114 Whitelisted by: WHITELIST **
> 

--

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message --- 
Joey Hess <joeyh@debian.org> (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.

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: