How to update developers-reference (Re: [SRM] upload of debian-reference/2.46 to stable)
On Sun, Feb 27, 2011 at 04:19:24PM +0000, Adam D. Barratt wrote:
> On Sun, 2011-02-27 at 09:46 +0900, Osamu Aoki wrote:
> > On Sat, Feb 26, 2011 at 05:45:21PM +0000, Adam D. Barratt wrote:
> > > On Fri, 2011-02-25 at 22:20 +0900, Osamu Aoki wrote:
> > > > | debian-reference (2.46) stable; urgency=low
> > > > |
> > > > | * Updated Portguese translation by Américo Monteiro.
> > > > | * Fixed s/--get-selection/--get-selections/ etc. Closes: #612435
> > > > | * Reflected introduction of squeeze-updates suite which replaced
> > > > | Debian Volatile Service. Closes: #614224
> > > > | * Fixed URL for Debian Mirror Checker site. Closes: #614253
> > >
> > > Thanks for working on this. The above sounds okay; is a debdiff of the
> > > proposed upload available somewhere?
> > Here it is. (I excluded *.po and *.pot files for debdiff of dsc files
> > since they contain line numbers which is different due to rebuild and
> > causes debdiff to be 16892KB instead of 33KB).
> Thanks; please feel free to upload.
> fwiw, the suggestion that one needs "extra care" when using
> squeeze-updates is a little debatable, given that all packages in that
> suite will be merged in to stable at point release time.
Well.. debian-reference is an user document and they do not upload.
This needs to be addressed by some documents like developers-reference
needs to worry.
I think inputs from release team on such clarified definition to
developers-reference will be nice. (Since this is discussion on
developers-reference, I am moving this to debian-doc.)
I do not know who will lead but I am a bit confused here.
stable-proposed-updates is defined as:
A) a truly critical functionality problem
B) the package becomes uninstallable
C) a released architecture lacks the package
stable-updates is defined as:
D) The update is urgent and not of a security nature. Security updates
will continue to be pushed through the security archive. Examples
include packages broken by the flow of time (c.f. spamassassin and
the year 2010 problem) and fixes for bugs introduced by point
E) The package in question is a data package and the data must be updated
in a timely manner (e.g. tzdata).
F) Fixes to leaf packages that were broken by external changes (e.g.
video downloading tools and tor).
G) Packages that need to be current to be useful (e.g. clamav).
Here, I think A includes (D + E + G) in some way. F is relaxing of A
qualification rule for leaf packages. Are we removing A from
stable-proposed-updates? Basically stable-updates seems to be A with
relaxed qualification to be "critical functionality problem" but with
limitted applicable package types?