Re: 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. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: 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 vdanj...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe95728.2040...@free.fr
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe81825.6040...@debian.org
Re: 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. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe83470.3030...@bzed.de
Re: Best Practices on testing-proposed-updates vs unstable vs experimental after testing freeze
On Mon, Jun 25, 2012 at 5:50 PM, Bernd Zeimetz be...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe83470.3030...@bzed.de -- YunQiang Su -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6UL-r2GybiD98qZ3vAVX3xx1BLS9wt98AgCFRU=2p8...@mail.gmail.com
Re: 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 be...@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. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe89913.6000...@bzed.de
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w6o5t2ycrlek9hvmvgyf1np-qpli1nfk-ozmv7m-oo...@mail.gmail.com
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakcpw6xgn-8n6eekmwpaf5fezbkv5odcummftuu9dbqfphh...@mail.gmail.com
