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

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
>> warrants
>> an update outside of the normal point release cycle (and those are rare)
>> it
>> 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 <ftpmaster@ftp-master.debian.org>
> | To: Osamu Aoki <osamu@debian.org>
> | Subject: debian-reference_2.46_amd64.changes ACCEPTED into
> proposed-updates
> | Notes:
> | Mapping stable to proposed-updates.

"proposed-updates" is not "stable-updates".

> I also see Debian web pages:
> stable-updates          in
> http://qa.debian.org/developer.php?login=osamu@debian.org
>   (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
> http://packages.qa.debian.org/d/debian-reference.html
>   (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
yourself. :-)

>> Transitively the rules for stable-proposed-updates got a bit more
>> relaxed
>> to fix up packages and keep them useful in stable if they're broken by
>> outside influences not under our control.[*]  Previously those were
>> updated
>> 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
> alias?

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:
> http://www.debian.org/doc/developers-reference/pkgs.html#upload-stable

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

stable upload
  -> p-u-NEW queue
    -> } s-p-u
       } maybe also to stable-updates
     -> stable via a point release

> How do ypu explain this differences?

See above.

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
clarifying further.



Reply to: