Re: Backports, Stable releases, Testing, Oh my!
On Fri, Feb 28, 2014 at 13:18:02 +0800, Paul Wise wrote: On Fri, Feb 28, 2014 at 1:14 PM, Thomas Goirand wrote: AFAICT, it's 5 days now. The default urgency in dch is medium now, which britney interprets as 5 days for existing packages. Packages that aren't in testing have their urgency ignored IIRC and migrate after 10 days. No, packages that aren't in testing only have their urgency ignored if it's more than medium. So they're candidates for migration after either 5 or 10 days. Cheers, Julien signature.asc Description: Digital signature
Re: Backports, Stable releases, Testing, Oh my!
On Sun, Mar 2, 2014 at 12:44 AM, Julien Cristau wrote: No, packages that aren't in testing only have their urgency ignored if it's more than medium. So they're candidates for migration after either 5 or 10 days. Hmm, ok. Thanks for clarifying. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6ej7tbsmjqpmxnhooy5zehs8fnbgvhpbzyq-snnbrm...@mail.gmail.com
Re: Backports, Stable releases, Testing, Oh my!
On Wed, Feb 26, 2014 at 12:36 PM, Peter Samuelson wrote: [micah] it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. If only we had some kind of a setup where, a few days after you upload a fixed version of something, it could reenter testing. Then maybe all that hair trauma wouldn't be needed. Is 10 days really too long? The only consequence of having a package removed from testing really is the 10 day delay to get it back after the next unstable upload (assuming remaining the remaining rc bugs were fixed). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mnthsvddkb45hpnbxj+wpdk7mwqabxrgzm18exe3qf...@mail.gmail.com
Re: Backports, Stable releases, Testing, Oh my!
On 02/28/2014 09:40 AM, Michael Gilbert wrote: On Wed, Feb 26, 2014 at 12:36 PM, Peter Samuelson wrote: [micah] it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. If only we had some kind of a setup where, a few days after you upload a fixed version of something, it could reenter testing. Then maybe all that hair trauma wouldn't be needed. Is 10 days really too long? The only consequence of having a package removed from testing really is the 10 day delay to get it back after the next unstable upload (assuming remaining the remaining rc bugs were fixed). Best wishes, Mike AFAICT, it's 5 days now. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53101b27.5080...@debian.org
Re: Backports, Stable releases, Testing, Oh my!
On Fri, Feb 28, 2014 at 1:14 PM, Thomas Goirand wrote: AFAICT, it's 5 days now. The default urgency in dch is medium now, which britney interprets as 5 days for existing packages. Packages that aren't in testing have their urgency ignored IIRC and migrate after 10 days. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6hawvjon3ysyqxb6w5tdkzri6y76p+c-ra4kubd_r2...@mail.gmail.com
Re: Backports, Stable releases, Testing, Oh my!
On Tue, Feb 25, 2014 at 3:33 PM, Paul Wise p...@debian.org wrote: What shall we do? Remove from stable-bpo? Hope an update comes around? Does it make sense to revisit the rules? Does a wait until testing still make sense (ok, waiting always makes sense, but beyond the 'let it settle' thing) Autoremoval from backports possibly makes sense? My concern with autoremoving packages from backports is that it would take an extended amount of time to get the package back into backports after the RC bug is fixed; it'd have to go through the backports NEW queue again, whereas packages in unstable don't need to take a detour through the NEW queue in order to re-migrate to testing. It'd be even more annoying for folks who contribute backported packages but aren't actually the maintainers of the package; they may well be caught by surprise when a RC bug that they didn't know about causes their backports to be autoremoved, especially if it was a RC bug that only had an impact in testing/unstable, and not in a stable+backports environment. Regards, Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACZd_tBJSqg=etqhok_2qehmm-cyexjwxj-ydq5ovu9pmjg...@mail.gmail.com
Re: Backports, Stable releases, Testing, Oh my!
Hi there. * Paul Tagliamonte paul...@debian.org [2014-02-25 23:59:05 CET]: I'm sending to both -devel and backports. I'm not sure which is the correct list. If one's wrong, feel free to drop it in replies. I've been talking with a mentee about backporting procedures, and I've explained why we don't backport until a package hits tending (stable stable-bpo testing = unstable) Right, reason being to make sure (for a certain degree) that an upgrade path from stable + bpo to next-stable without bpo is possible. However, with the new testing removals from the release team (which is totally great for creating an always releasable testing, many thanks for that), we can create a situation where stable-bpo has a newer version than testing when we release (lazy maintainer never fixed the rc bug). Erm, no, not at all. A package in stable-bpo can't have a newer version than testing when we release. With the removal there can be two situations: * After fixing the issue that got the package removed from testing, the package flows in like usual into testing, and it will definitely have at least the version it had in testing before, most probably higher, but never lower. * The package doesn't flow into testing anymore before the release. If this is expected to happen, the package has to be removed from stable-bpo. What shall we do? Remove from stable-bpo? Hope an update comes around? Remove from stable-bpo if it's not expected to come back in is what we actually do, yes. And to have an overview of these situations I created myself the diffstats page: http://backports.debian.org/wheezy-backports/overview/ Looking at the not available page, I noticed that I need to remove the twisted-* packages. *heading over to franck* Does it make sense to revisit the rules? Does a wait until testing still make sense (ok, waiting always makes sense, but beyond the 'let it settle' thing) Sure the wait until testing makes sense, as much as the testing transition period in itself makes sense. There are exeptions granted (for security related uploads mostly), but yes, that rule does indeed make sense. You never know what RC might pop up that hinder the testing transition and you are then stuck with a newer version in stable-bpo than in testing for until the RC got fixed. So, no need to panic, all under control, just a bit overworked and things not happening as timely as they should. Enjoy, Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los| -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226084755.ga19...@anguilla.debian.or.at
Re: Backports, Stable releases, Testing, Oh my!
Gerfried Fuchs rho...@deb.at writes: Remove from stable-bpo if it's not expected to come back in is what we actually do, yes. And to have an overview of these situations I created myself the diffstats page: http://backports.debian.org/wheezy-backports/overview/ Looking at the not available page, I noticed that I need to remove the twisted-* packages. *heading over to franck* The only reason that this one shows up to be removed is because the package names changed in unstable/testing from twisted-* to python-twisted-* so I don't think that this should be removed. You might argue that a newer version from testing should be put into bpo and these removed, which I wont argue against, but updating the version in bpo From a new testing version should not be rushed due to this aggressive removal situation. Personally, I've found the aggressive removal from testing to be a shock in a number of cases. I understand the motivations behind it, but it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. I feel like the window for removal from testing is too short and is having negative consequences on the stress level of people whose volunteer labor contributions to Debian are already stretched thin. Most everyone I've spoken to in this situation has said that it wouldn't be so bad if they had just a couple more days. I'd like it if that shock wasn't also quickly passed on to backports and instead things were examined a little more closely before purging packages. For example, say package X has been backported at version 1.0, version 2.0 is uploaded to sid, transitions to jessie and then has an RC bug that threatens removal. The problem with the 2.0 package has to do with some security issue upstream, which looks like it will be a deep code massage to fix and will take a while, too long for the testing removal auto firing squad. The maintainer wishes that they had not uploaded 2.0 yet, because 1.0 was fine. Now backports sees the difference, because the 1.0 version has been removed from testing, so bpo now has a newer version than what is in testing. But the package is actually a *better*, but backports gets its package removed anyways. Maintainer decides to eat the epoch and re-uploads version 1.0 to get a functioning package, uploads urgency high and package transitions to testing and a backport of the same package needs to be done again in a very short period of time after it was removed. micah Churn baby churn, disco inferno! pgpKu0FFExwCH.pgp Description: PGP signature
Re: Backports, Stable releases, Testing, Oh my!
On Feb 26, 2014 10:49 AM, micah mi...@debian.org wrote: For example, say package X has been backported at version 1.0, version 2.0 is uploaded to sid, transitions to jessie and then has an RC bug that threatens removal. If the RC bug is properly versioned, then the 1.0 upload, which isn't affected, shouldn't be removed from testing. Cheers, James
Re: Backports, Stable releases, Testing, Oh my!
Hi. * micah mi...@debian.org [2014-02-26 16:48:45 CET]: Gerfried Fuchs rho...@deb.at writes: Remove from stable-bpo if it's not expected to come back in is what we actually do, yes. And to have an overview of these situations I created myself the diffstats page: http://backports.debian.org/wheezy-backports/overview/ Looking at the not available page, I noticed that I need to remove the twisted-* packages. *heading over to franck* The only reason that this one shows up to be removed is because the package names changed in unstable/testing from twisted-* to python-twisted-* so I don't think that this should be removed. The source packages were changed indeed after looking, but the removal happened over a month ago. You might argue that a newer version from testing should be put into bpo and these removed, which I wont argue against, but updating the version in bpo From a new testing version should not be rushed due to this aggressive removal situation. I am uncertain what you call an aggressive removal situation here. It happened a month ago in testing/unstable, and it was a RoQA. Your aggressive removal situation call is as unjustified as the Oh my in the subject. It would be nice if we can keep the tone civilized. The package doesn't exist in testing or unstable anymore since a month, and given that we expect from backport maintainers to track the packages they package, I would expect either an update on the situation; silence doesn't improve the situation. Personally, I've found the aggressive removal from testing to be a shock in a number of cases. Then please discuss that issue with the ftp masters or release team. As backports team we only want packages in backports which are expected to be in the next stable release. A package that isn't anymore in testing/unstable for sure won't be part of the next stable release. I understand the motivations behind it, but it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. I think you might be mixing two things up. You are speaking about removal from testing, but mean keeping them in unstable? This isn't the case here, the package was removed completely, not only from testing. I feel like the window for removal from testing is too short and is having negative consequences on the stress level of people whose volunteer labor contributions to Debian are already stretched thin. How long would be not too short for you? A month seems to be too short it seems. Sorry 'bout that. Most everyone I've spoken to in this situation has said that it wouldn't be so bad if they had just a couple more days. A day or more doesn't make much difference after a month, does it? Thing is, where would you draw the line then. A month and a week? Then the next person would say a few more days won't hurt, and the time gets extended endlessly. That doesn't us get anywhere. I'd like it if that shock wasn't also quickly passed on to backports and instead things were examined a little more closely before purging packages. Please. Quickly, a month? For example, say package X has been backported at version 1.0, version 2.0 is uploaded to sid, transitions to jessie and then has an RC bug that threatens removal. The problem with the 2.0 package has to do with some security issue upstream, which looks like it will be a deep code massage to fix and will take a while, too long for the testing removal auto firing squad. The maintainer wishes that they had not uploaded 2.0 yet, because 1.0 was fine. This is a *completely* different situation and has nothing to do with the twisted-* packages. They weren't pulled from testing, they aren't in *unstable* anymore neither. Those packages don't exist anymore. Yes, renaming is an unforunate situation, but even then, a month waiting time doesn't seem to be too unreasonable, does it? Now backports sees the difference, because the 1.0 version has been removed from testing, so bpo now has a newer version than what is in testing. But the package is actually a *better*, but backports gets its package removed anyways. backports gets packages removed which aren't available anymore. This hasn't changed at all, it's nothing new, it happened in the past. Maintainer decides to eat the epoch and re-uploads version 1.0 to get a functioning package, uploads urgency high and package transitions to testing and a backport of the same package needs to be done again in a very short period of time after it was removed. If the package still lives in unstable, the removal isn't done in backports but rather discussed on how to proceed. Like I pinged zigo today about whether he could help get the RC fixed for cloud-initramfs-tools so that testing has the package
Re: Backports, Stable releases, Testing, Oh my!
[micah] it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. If only we had some kind of a setup where, a few days after you upload a fixed version of something, it could reenter testing. Then maybe all that hair trauma wouldn't be needed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226173610.gc4...@p12n.org
Re: Backports, Stable releases, Testing, Oh my!
* Peter Samuelson pet...@p12n.org [2014-02-26 18:36:10 CET]: [micah] it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. If only we had some kind of a setup where, a few days after you upload a fixed version of something, it could reenter testing. Then maybe all that hair trauma wouldn't be needed. That area is called unstable. Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los| -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226174514.ga12...@anguilla.debian.or.at
Re: Backports, Stable releases, Testing, Oh my!
On Wed, 2014-02-26 at 09:47 +0100, Gerfried Fuchs wrote: Erm, no, not at all. A package in stable-bpo can't have a newer version than testing when we release. With the removal there can be two situations: * After fixing the issue that got the package removed from testing, the package flows in like usual into testing, and it will definitely have at least the version it had in testing before, most probably higher, but never lower. * The package doesn't flow into testing anymore before the release. If this is expected to happen, the package has to be removed from stable-bpo. What shall we do? Remove from stable-bpo? Hope an update comes around? Remove from stable-bpo if it's not expected to come back in is what we actually do, yes. And to have an overview of these situations I created myself the diffstats page: http://backports.debian.org/wheezy-backports/overview/ And if the newer version, for example, has updated a database schema in a non-backward-compatible way? Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: Backports, Stable releases, Testing, Oh my!
Nick Phillips nick.phill...@otago.ac.nz writes: And if the newer version, for example, has updated a database schema in a non-backward-compatible way? The same problem would apply to testing, so there would be a very high incentive to find a way to fix that for testing users. Backports users would then benefit from the same fix. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ios1y5em@windlord.stanford.edu
Backports, Stable releases, Testing, Oh my!
Howdy folks, I'm sending to both -devel and backports. I'm not sure which is the correct list. If one's wrong, feel free to drop it in replies. I've been talking with a mentee about backporting procedures, and I've explained why we don't backport until a package hits tending (stable stable-bpo testing = unstable) However, with the new testing removals from the release team (which is totally great for creating an always releasable testing, many thanks for that), we can create a situation where stable-bpo has a newer version than testing when we release (lazy maintainer never fixed the rc bug). What shall we do? Remove from stable-bpo? Hope an update comes around? Does it make sense to revisit the rules? Does a wait until testing still make sense (ok, waiting always makes sense, but beyond the 'let it settle' thing) Much love, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Backports, Stable releases, Testing, Oh my!
On Wed, Feb 26, 2014 at 6:59 AM, Paul Tagliamonte wrote: However, with the new testing removals from the release team (which is totally great for creating an always releasable testing, many thanks for that), we can create a situation where stable-bpo has a newer version than testing when we release (lazy maintainer never fixed the rc bug). Perhaps I'm missing something but if the RC bug never gets fixed the package will never transition to testing again so this problem will not occur? Then the stable release will not have the package and stable-backports will move to oldstable-backports. What shall we do? Remove from stable-bpo? Hope an update comes around? Does it make sense to revisit the rules? Does a wait until testing still make sense (ok, waiting always makes sense, but beyond the 'let it settle' thing) Autoremoval from backports possibly makes sense? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6hasp15jzodrqd6b8azmleqs45yqdt-zehcp4cywuf...@mail.gmail.com
Re: Backports, Stable releases, Testing, Oh my!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Am 26.02.14 00:33, schrieb Paul Wise: yes ... and the package installed from oldstable-backports is newer then oldstable. This situation we have had sometimes in the past (eg. php-suhosin). The problem that a package, which is in stable-backports, gets removed from testing is nothing new. But with the more aggressive testing removal it is more visible. Cheers, Jan. - -- Never write mail to w...@spamfalle.info, you have been warned! - -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlMNlu0ACgkQ9u6Dud+QFySiogCglXpp64gTJXEu7w9O0kizN3nJ ltsAoIvm/p3gP9nrYtAElBs1um2veQy7 =hqNx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530d96ed.4090...@cyconet.org
