Re: How to update developers-reference (Re: [SRM] upload of debian-reference/2.46 to stable)
On Tue, March 1, 2011 13:33, Osamu Aoki wrote:
> On Mon, Feb 28, 2011 at 09:26:01PM +0100, Philipp Kern wrote:
>> every package will enter stable-proposed-updates first. Then, if it
>> an update outside of the normal point release cycle (and those are rare)
>> gets copied to squeeze-updates for public consumption.
> Well, I just uploaded 2.46 to "stable" for debian-reference. This seems
> to be gone into stable-updates per some information I got as mail from
> Debian FTP Masters as:
No; that's not exactly what the mail says.
> | Date: Mon, 28 Feb 2011 20:04:20 +0000
> | From: Debian FTP Masters <firstname.lastname@example.org>
> | To: Osamu Aoki <email@example.com>
> | Subject: debian-reference_2.46_amd64.changes ACCEPTED into
> | Notes:
> | Mapping stable to proposed-updates.
"proposed-updates" is not "stable-updates".
> I also see Debian web pages:
> stable-updates in
> (mouse over 2.46 on debian-reference line gives stable-updates)
Here, the mouse-over says "proposed-updates". Apologies if this sounds
picky, but it's key to trying to explain the difference.
> stable-proposed-updates in
> (left side list s-p-u as 2.46)
This is correct, as is the DDPO link. "stable-proposed-updates" and
"proposed-updates" are the same thing and always have been ttbomk.
> This is confusing.
Possibly, although the above suggests that you may be helping to confuse
>> Transitively the rules for stable-proposed-updates got a bit more
>> to fix up packages and keep them useful in stable if they're broken by
>> outside influences not under our control.[*] Previously those were
>> through volatile. Now they'll be fixed in stable instead if the fixes
>> are self-contained and unlikely to cause any breakage in other packages.
>> (Thus the reference to leaf packages.)
>> I hope that clears it up.
> This part is OK.
> Question is what path package goes through and delay for each step. Are
> stable-updates and stable-proposed-updates the same thing with different
No and sort of. :)
The dak configuration needs updating slightly to make it work fully, but
the idea is that an upload with any of "stable", "proposed-updates",
"stable-proposed-updates", "squeeze", "squeeze-updates" and
"stable-updates" in the .changes will end up in the p-u-new queue; the
first four already do so, the latter two need adding on the dak side.
>From there, they will *all* go in to stable-proposed-updates, assuming
they're accepted. The SRMs will then be able to, at our discretion, copy
some, all or none of them to stable-updates. There will not be packages
in stable-updates which are not also in either s-p-u or stable if there's
been a point release since they were uploaded.
> If I trust:
I think we already mentioned that the dev-ref needs updating; that's where
this conversation started. :-)
> "stable upload"
> -> "proposed-updates-new queue"
> -> "stable-proposed-updates"
> -> (at next point release) stable
> But what has happened is
> "stable upload"
> -> "??? queue"
> -> "stable-updates"
> -> (I expect at next point release) stable
-> p-u-NEW queue
-> } s-p-u
} maybe also to stable-updates
-> stable via a point release
> How do ypu explain this differences?
Hopefully this is a little clearer now, but we are starting from a
position of prior knowledge, so please let us know if anything needs