Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
I am confused that where to upload packages after testing freeze.
Give a package foobar, version 1.0 is planned to be included in the
next release.
And now, the version 2.0 released, I want make it available in Debian,
in either unstable or experimental.
Now I have several choice:
1. upload 2.0 to experimental, and unstable users should install it manually.
2. upload 2.0 to unstable, and unstable users can install it directly, while
if 1.0.1 released and fixes an important bug, I have to upload it
testing-proposed-updates,
and it seems that we treated testing-proposed-updates the same as testing.
testing-proposed-updates has no several days to testing
And I am also confused by the connection of proposed-updates and updates.
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKcpw6XgN-8N6eEKmWPaf5fEZBkV5oDcuMMFTUU9DBqFPhhLrw@mail.gmai l.com">http://lists.debian.org/CAKcpw6XgN-8N6eEKmWPaf5fEZBkV5oDcuMMFTUU9DBqFPhhLrw@mail.gmai l.com
06-25-2012, 07:49 AM
Simon McVittie
Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
On 25/06/12 06:07, YunQiang Su wrote:
> 1. upload 2.0 to experimental, and unstable users should install it manually.
This is usually the right answer: if version 1.0 is intended to go in
the next Debian release, it should get as much testing as possible,
which means it should be the default for unstable users.
> And I am also confused by the connection of proposed-updates and updates.
Updates to stable or testing aren't "official" until the release team
has acknowledged them. You discuss the update with the release team,
then (if they approve) upload to *-proposed-updates. The release team
review the update and copy it to *-updates.
S
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE81825.6040105@debian.org">http://lists.debian.org/4FE81825.6040105@debian.org
06-25-2012, 09:50 AM
Bernd Zeimetz
Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
On 06/25/2012 09:49 AM, Simon McVittie wrote:
> On 25/06/12 06:07, YunQiang Su wrote:
>> 1. upload 2.0 to experimental, and unstable users should install it manually.
>
> This is usually the right answer: if version 1.0 is intended to go in
> the next Debian release, it should get as much testing as possible,
> which means it should be the default for unstable users.
Also it avoids that you have to go trough testing-proposed-updates for
fixes in wheezy - you upload to unstable, test there and if it works as
expected you ask the release team for a freeze exception to fix the
issues in wheezy.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE83470.3030109@bzed.de">http://lists.debian.org/4FE83470.3030109@bzed.de
06-25-2012, 04:45 PM
YunQiang Su
Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
On Mon, Jun 25, 2012 at 5:50 PM, Bernd Zeimetz <bernd@bzed.de> wrote:
> On 06/25/2012 09:49 AM, Simon McVittie wrote:
>> On 25/06/12 06:07, YunQiang Su wrote:
>>> 1. upload 2.0 to experimental, and unstable users should install it manually.
>>
>> This is usually the right answer: if version 1.0 is intended to go in
>> the next Debian release, it should get as much testing as possible,
>> which means it should be the default for unstable users.
I am talking about after freeze.
>
> Also it avoids that you have to go trough testing-proposed-updates for
> fixes in wheezy - you upload to unstable, test there and if it works as
> expected you ask the release team for a freeze exception to fix the
> issues in wheezy.
Some guys may prefer unstable as an roll distribution.
>
> --
> *Bernd Zeimetz * * * * * * * * * * * * * *Debian GNU/Linux Developer
> *http://bzed.de * * * * * * * * * * * * * * * *http://www.debian.org
> *GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 *DD95 EB36 171A 6FF9 435F
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/4FE83470.3030109@bzed.de
>
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAKcpw6UL-r2GybiD98qZ3vAVX3xx1BLS9wt98AgCFRU=2P8Tug@mail.gma il.com
06-25-2012, 05:00 PM
Bernd Zeimetz
Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
On 06/25/2012 06:45 PM, YunQiang Su wrote:
> On Mon, Jun 25, 2012 at 5:50 PM, Bernd Zeimetz <bernd@bzed.de> wrote:
>> On 06/25/2012 09:49 AM, Simon McVittie wrote:
>>> On 25/06/12 06:07, YunQiang Su wrote:
>>>> 1. upload 2.0 to experimental, and unstable users should install it manually.
>>>
>>> This is usually the right answer: if version 1.0 is intended to go in
>>> the next Debian release, it should get as much testing as possible,
>>> which means it should be the default for unstable users.
> I am talking about after freeze.
>>
>> Also it avoids that you have to go trough testing-proposed-updates for
>> fixes in wheezy - you upload to unstable, test there and if it works as
>> expected you ask the release team for a freeze exception to fix the
>> issues in wheezy.
> Some guys may prefer unstable as an roll distribution.
Yes, unfortunately. But luckily a lot of people do sane things like not
uploading libraries with api/abi breakages during the freeze to unstable.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE89913.6000306@bzed.de">http://lists.debian.org/4FE89913.6000306@bzed.de
06-25-2012, 05:35 PM
Aron Xu
Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
Hi,
Regarding your question, it is recommended to do as follow during freeze:
unstable: any version that you would like to hit testing soon, so it's
the version that Release Team agreed (or likely) to unblock it.
experimental: any version that won't make its way to unstable,
including usual experimental stuff as well as things that Release Team
aren't likely to have in testing during the freeze, for example
significant upstream releases.
testing-proposed-updates: only use it when you haven't followed above
suggestions, that is to say you have a higher version number in
unstable which won't migrate to testing, in the case you can't upload
your fix for the testing version to unstable as usual and you have to
upload it to testing-pu instead.
Because packages uploaded to testing-proposed-updates are unlikely to
have so much testing as in unstable, it's discouraged to be used
unless necessary (versioning issues). So please make sure that
unstable is only for versions actually destined for testing. :-)
--
Regards,
Aron Xu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAMr=8w6O5T2yCRLeK9hVmVGYF1nP-QpLi1NFk-OZmv7M-oOq0A@mail.gmail.com
06-26-2012, 06:31 AM
Vincent Danjean
Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
Le 25/06/2012 19:35, Aron Xu a écrit :
> Hi,
>
> Regarding your question, it is recommended to do as follow during freeze:
>
> unstable: any version that you would like to hit testing soon, so it's
> the version that Release Team agreed (or likely) to unblock it.
unstable would also works for new packages: they will sit here until
the release happens but they do not block anything nor prevent
migration of other packages.
> experimental: any version that won't make its way to unstable,
> including usual experimental stuff as well as things that Release Team
> aren't likely to have in testing during the freeze, for example
> significant upstream releases.
>
> testing-proposed-updates: only use it when you haven't followed above
> suggestions, that is to say you have a higher version number in
> unstable which won't migrate to testing, in the case you can't upload
> your fix for the testing version to unstable as usual and you have to
> upload it to testing-pu instead.
>
> Because packages uploaded to testing-proposed-updates are unlikely to
> have so much testing as in unstable, it's discouraged to be used
> unless necessary (versioning issues). So please make sure that
> unstable is only for versions actually destined for testing. :-)
>
> --
> Regards,
> Aron Xu
>
>
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE95728.2040803@free.fr">http://lists.debian.org/4FE95728.2040803@free.fr
07-02-2012, 04:13 AM
Philipp Kern
Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
On Tue, Jun 26, 2012 at 08:31:04AM +0200, Vincent Danjean wrote:
> Le 25/06/2012 19:35, Aron Xu a écrit :
> > unstable: any version that you would like to hit testing soon, so it's
> > the version that Release Team agreed (or likely) to unblock it.
> unstable would also works for new packages: they will sit here until
> the release happens but they do not block anything nor prevent
> migration of other packages.
Please note that this might not apply to new revisions of libraries that are
uploaded as new non-conflicting source packages and then take over the
development package.