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

Re: On Sid and Experimental


Manjul Apratim wrote:

> I cannot help but view too many apt pins
> as an intentional recipe for disaster!

If you really want to experience life on the edge, you can try this:

	echo 'APT::Default-Release "experimental";' \

Used in combination with apt-listbugs, the result generally pretty
pleasant and stable.

To piggy-back on what Martin said: the current suites all have release
management roles.  See the suite update policy at
<http://release.debian.org/> for an overview.


  the released OS distribution, which has received a lot of QA
  work.  Does not change except at point releases (every few
  months) and major release (every couple of years or so).


  where the next minor update of stable cooks.  People prepare
  packages for here directly, and although the individual fixes
  that get used are tested in unstable first, the reliability of
  the final packages is mostly due to code review.


  where the next major update of stable cooks.  No package
  should be missing dependencies, except occasionally when needed
  to get through a transition.  Packages come from unstable (with
  a few exceptions) and get tested there first.  The purpose of
  the testing suite is to make sure packages work well together
  and can function as a coherent distribution.


  where packages for testing get built and initially tested.  No
  package enters here unless the package maintainer is confident that
  it or some later version will be suitable for the next stable
  release.  Build-time dependencies of packages in unstable are taken
  from unstable, so maintainers exercise care before updating
  ABI-incompatible new versions of libraries here --- and (at least in
  simple cases) when library ABI changes happen, related packages get
  rebuilt and accumulate here before they can move all at once to
  testing.  Nevertheless, unstable can be a site of rapid change.  It
  is normal for packages in unstable to be missing dependencies that
  have not been built or uploaded yet.


  where packages are uploaded when either (a) they should not be
  uploaded to unstable to avoid disrupting an ongoing interface
  transition or (b) they are not ready for upload to unstable for some
  other reason (maybe they need more testing before reaching a large

Much of GNOME 3 falls in category (a) --- these packages are moving
from experimental to unstable in small, coherent batches so they can
migrate to testing more efficiently.

If I understand its goals correctly, CUT would also play a release
management role.  In addition to making it easier for people to test
that packages in testing work well together, it could provide the
raw material for making pre-releases of the next version of the
installation media.

Hope that clarifies a little.

Reply to: