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

current specialities for NMUs



Hi,

some BSPs are just going on. In this mail, I'm summarising current
specialities:


1. Packages which depend on tiff, imagemagick, gnustep-gui0-dev, ocaml etc:

Any package which has influence on the tiff-transition, i.e. depends on
libtiff, imagemagick, gnustep-gui0-dev, ocaml, or other interconnected
libraries that are in the middle of an ABI transition. They all should
currently be considered as absolutly frozen, both in testing and unstable.



2. Packages in standard (and above) or base:

These packages are frozen, i.e. newer uploads to unstable won't go into
testing. The official way is to upload also a package to testing. To upload
a package to testing (or: testing-proposed-updates, this are just
synonyms; tpu in short), it is necessary that the version number of the
upload is smaller than the current installed package in unstable, and
larger than the current installed package in testing. So, normally, you
have to upload a package (directly or in whichever delayed you consider
appropriate), and the version for testing in one more day delayed. Also,
please remember that _only_ RC-bug fixes and translation updates are
allowed through direct testing updates. Also, a full patch and a summary
needs to be attached to the bug report, so that the RMs can easier judge
the change.

However, sometimes, the release managers are willing to push a package from
unstable to testing; in this case, only one upload is needed.

In any case where frozen packages are subject to uploads, please speak with
the release managers before.



3. KDE:

As kdelibs 3.3 is now uploaded to unstable, all KDE updates need to go
through tpu now. So, also for these changes, only RC-bug fixes and
translation updates are allowed.



4. Using testing or testing-proposed-updates:

Unless specifically allowed (i.e. frozen packages, KDE), direct uploads to
testing are strongly discouraged. Reasons for this: They are more work for
the release managers, and they have less testing.



5. How to contact release managers:

For this purpose, there exists the address debian-release@lists.debian.org.
Also, you can look at #debian-bugs on irc.debian.org; quite often are there
release managers around.




Happy hacking, and let's get the RC-bug count down.
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C



Reply to: