Reliability of data (Was: Re: Two proposals for a better Lenny (testing related).)
Ter, 2007-06-12 às 10:26 -0300, Gustavo Franco escreveu: Any idea on how to collect more reliable data in a opt-in base? Does a survey on pentabarf (or public acessible) during debconf makes sense? Huh How can opt-in data be more reliable then disperse collection? daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reliability of data (Was: Re: Two proposals for a better Lenny (testing related).)
On 6/28/07, Daniel Ruoso [EMAIL PROTECTED] wrote: Ter, 2007-06-12 às 10:26 -0300, Gustavo Franco escreveu: Any idea on how to collect more reliable data in a opt-in base? Does a survey on pentabarf (or public acessible) during debconf makes sense? Huh How can opt-in data be more reliable then disperse collection? When the disperse collection doesn't point exact to the data (yes, the data not the result) you want to analyze. In other words, that's why some people are asked for who they're going to vote in a election (opt-in base but also a disperse collection) and the statistics aren't based on how much people are reporting bugs against Debian suite X, Y or Z. :-) regards, -- stratus http://stratusandtheswirl.blogspot.com get debian @ http://get.debian.net/
Re: Two proposals for a better Lenny (testing related).
Am 2007-06-14 20:25:54, schrieb Luis Matos: i don't think this is a reliable situation. At first look, a new package version is better than it's last. If the kernel breaks at boot, the bootloader allows you to boot with the old kernel as _special_ option. Which mean YOU HAVE two different kernels installed. I had the problem where I have had ONLY the stock Debian-Kernel and after an upgrade the new revision of the kernel was not more working on my Mainboard and there was NO FALLBACK, since the upgrade Kernel replaced the previosly one. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
On 6/15/07, Michael Banck [EMAIL PROTECTED] wrote: On Thu, Jun 14, 2007 at 08:10:08PM +0200, Martijn van Oosterhout wrote: Actually, it seems to me the real problem is that when a new kernel is installed it is immediately used by the bootloader on the next reboot, without asking. That's because you installed the meta-package, saying I want to run the newest kernel without asking. If you don't want that, don't install the meta-package and install new kernel versions as they appear. Aha! I did a basic install from the CD so I had no idea there was a metapackage that did this. Now I know I can uninstall it and be happy! Thanks! Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: I think that a package that has been in unstable for a whole release cycle without entering testing should probably live in experimental or not in Debian at all. I guess that is something most people can agree on. Hm, I was tempted to think yes, of course, but how about foo-snapshot or bar-cvs? Why shouldn't they be in unstable, autobuilt and available as Build-Depends for baz-bzr? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Two proposals for a better Lenny (testing related).
On Wed, 13 Jun 2007, Felipe Sateler wrote: PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. It's not that complicated if we have the new Breaks field. I just submitted my suggestion on the package linux-latest-2.6. The idea is to have something like this: Package: linux-image-2.6-686 Version: 2.6.21+7 Breaks: kqemu-modules-2.6-686 ( 2.6.21+7), unionfs-modules-2.6-686 ( 2.6.21+7), ... That way, linux-image-2.6-686 is upgraded only if a matching kqemu-modules-2.6-686 / unionfs-modules-2.6-686 is also available. Of course if the user has not installed any of those packages, it's a no-op as it should be. Some details probably need to be worked out, but it looks like a good way to do that. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 14/06/07 at 08:31 +0200, Frank Küster wrote: Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: I think that a package that has been in unstable for a whole release cycle without entering testing should probably live in experimental or not in Debian at all. I guess that is something most people can agree on. Hm, I was tempted to think yes, of course, but how about foo-snapshot or bar-cvs? Why shouldn't they be in unstable, autobuilt I think that such packages are OK in unstable, but some might argue that they should go in experimental. and available as Build-Depends for baz-bzr? That's dangerous. baz-bzr will be allowed to transition to testing (b-deps are not considered for testing transition), but won't be able to build from source in testing, which is RC. I'm working on analyzing snapshot.d.n data to get an accurate list of when was package X last in testing ?. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Thu, 14 Jun 2007, Raphael Hertzog wrote: On Wed, 13 Jun 2007, Felipe Sateler wrote: PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. It's not that complicated if we have the new Breaks field. I just submitted my suggestion on the package linux-latest-2.6. For reference, it's bug #428783. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Lucas Nussbaum [EMAIL PROTECTED] wrote: Hm, I was tempted to think yes, of course, but how about foo-snapshot or bar-cvs? Why shouldn't they be in unstable, autobuilt I think that such packages are OK in unstable, but some might argue that they should go in experimental. and available as Build-Depends for baz-bzr? That's dangerous. baz-bzr will be allowed to transition to testing (b-deps are not considered for testing transition), but won't be able to build from source in testing, which is RC. No, I don't think that's a problem. Packages which are just regular unreleased checkouts of some version control system should have a not for release dummy RC bug anyway. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Two proposals for a better Lenny (testing related).
* Luis Matos [EMAIL PROTECTED], [2007-06-14 1:14 +0100]: Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu: Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. this makes the snapshots just like the current ones (i think cd sets are built weekly r monthly, can anyone confirm this?) They're built weekly, see http://www.debian.org/devel/debian-installer/ I don't think that we should release a snapshot of CUT each and every month. My suggestion was just to use months rather than numbers to refer to CUT snapshots, but keeping the when it's ready philosophy and all the other points of Joey's proposal: http://kitenet.net/~joey/code/debian/cut/ ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 20:27 -0400, Felipe Sateler escreveu: Luis Matos wrote: Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu: Installing a newer kernel is not an upgrade, in a sense. You are installing new software alongside the old one. Thus the usual expectations don't hold. the usual expectation that i have with a new kernel is to improve my operating system ... that includes no regressions on supporting my hardware - for example, wifi or graphic card. But it doesn't hold, since you are actually installing a _new_ package, not upgrading an existing. basically that is not true. Imagining moving system like CUT (testing) you must predict these issues. It is a New package, but one that can make the system unusable (or parts of it). PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. what about checking the *-modules-2.6.A packages available and compare them with the previous version? That would live everyone waiting for the every module to be ready, of which they may not be using some. true ... and if unstable has a low priority than testing, users ould fetch that from unstable easily. But, if testing is *always* usable, then it has to be that way. if the count of both are equal, then kernel *and* modules can go into testing. If, for some reason a module is not available or cannot migrate into testing, kernel would not migrate. Note that independent of wether modules are in testing or not, upgrading a kernel *won't* install the modules (out of tree modules, that is). You still have to install them by hand. That is what I was referring to. not true. there are meta pckages that do that for me. kernel has linux-image-2.6-k8 (for example), modules have name-module-2.6-k8 . when an new kernel is uploaded, it is upgrade because there is a new meta package. the same way, if there is new module meta package, then, the modules will be upgraded. the problem here is that the kernel meta package is upgraded *but* because there is no modules meta package, those are not upgraded. I think i am not mistaken. -- Felipe Sateler Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 17:49 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 05:32:01PM +0100, Luis Matos wrote: Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? Some packages are allowed to pass into testing even if other depends on it, but has issues that will take some time to resolve. This will make that that package, that is now in testing, will not be installable in anyway. This happens sometimes. Well, tough. Take it up with the maintainers who don't coordinate their uploads to unstable with the maintainers of related packages. The release team only breaks packages in testing when we *have* to do so to move the release forward (meaning, a net reduction in RC problems). i am not blaming the Release Team --- for real. I just want that automatic passages from unstable for testing, when debian is not in a pre-stable-release state have more verifications such as reverse depends. That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. No. The nvidia kernel packages are a particular case where the module packages were willfully broken in testing by the release team because of long-outstanding RC bugs in related nvidia packages. Again, this was a necessary trade-off which reduced the overall number of release-critical problems in testing. i am generally speaking ... the nvidia package was an example that occurred to me (and i stop using it since then). Other problems like that happened to me. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. true. nvidia-kernel (meta packge) depends on linux-image-2.6.10. a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did not pass because it is too young. You either don't know how testing works, or you don't know how the Debian kernel packages are structured. I think i know (i let the space open for the uncertain). And the kernel packages was an example on how things can be broken in testing and give ideas to prevent them to have CUT (Constantly Usable Testing). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 13:08 +0200, Emanuele Rocca escreveu: * Luis Matos [EMAIL PROTECTED], [2007-06-14 1:14 +0100]: Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu: Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. this makes the snapshots just like the current ones (i think cd sets are built weekly r monthly, can anyone confirm this?) They're built weekly, see http://www.debian.org/devel/debian-installer/ I don't think that we should release a snapshot of CUT each and every month. i fully agree ... My suggestion was just to use months rather than numbers to refer to CUT snapshots, but keeping the when it's ready philosophy and all the other points of Joey's proposal: http://kitenet.net/~joey/code/debian/cut/ agreed. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit : I just want that automatic passages from unstable for testing, when debian is not in a pre-stable-release state have more verifications such as reverse depends. I really don't understand what checks you want to add over those already being done. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Two proposals for a better Lenny (testing related).
On 6/14/07, Luis Matos [EMAIL PROTECTED] wrote: having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... if ... *if* i had used module-assistant to use nvidia graphics (or camera modules, or wifi, or what else), i would not mind to do that. Actually, it seems to me the real problem is that when a new kernel is installed it is immediately used by the bootloader on the next reboot, without asking. I explicitly check to see if there's a kernel upgrade and abort if that's the case, as I do not have the time to sort out the mess before the next reboot. Ideally, it could just install, without having it automatically used next time. Then, when I have time and everything is right, then the bootloader uses the new kernel. (This is probably possible, I just havn't worked out how yet). Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos wrote: not true. there are meta pckages that do that for me. kernel has linux-image-2.6-k8 (for example), modules have name-module-2.6-k8 . I had forgotten that those existed. I have always installed my modules and kernels directly. Taking those into account, what you say would happen. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 19:18 +0200, Josselin Mouette escreveu: Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit : I just want that automatic passages from unstable for testing, when debian is not in a pre-stable-release state have more verifications such as reverse depends. I really don't understand what checks you want to add over those already being done. I just want to ensure that *ALL* the necessary checks are made when a package steps into testing so that the package that passes don't break anything. I presented here the kernel and kernel modules case, but some other already happened to me (that cases that we just ... don't upgrade and forget). I also would like to have testing *Oficial* snapshots as demonstration of debian's current state, testing being promoted as bleeding edge system for home/power users and CUT. Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 20:10 +0200, Martijn van Oosterhout escreveu: I explicitly check to see if there's a kernel upgrade and abort if that's the case, as I do not have the time to sort out the mess before the next reboot. Ideally, it could just install, without having it automatically used next time. Then, when I have time and everything is right, then the bootloader uses the new kernel. i don't think this is a reliable situation. At first look, a new package version is better than it's last. If the kernel breaks at boot, the bootloader allows you to boot with the old kernel as _special_ option. -- Luis Matos [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
* Luis Matos ([EMAIL PROTECTED]) [070614 20:20]: Qui, 2007-06-14 às 19:18 +0200, Josselin Mouette escreveu: Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit : I just want that automatic passages from unstable for testing, when debian is not in a pre-stable-release state have more verifications such as reverse depends. I really don't understand what checks you want to add over those already being done. I just want to ensure that *ALL* the necessary checks are made when a package steps into testing so that the package that passes don't break anything. I presented here the kernel and kernel modules case, but some other already happened to me (that cases that we just ... don't upgrade and forget). Actually, they *are* done, unless overriden for good reasons by the release team (and I can only remember a few such cases in the last years, not counting removals of broken packages from testing to let a transition through). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Thu, Jun 14, 2007 at 07:18:34PM +0200, Josselin Mouette wrote: Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit : I just want that automatic passages from unstable for testing, when debian is not in a pre-stable-release state have more verifications such as reverse depends. I really don't understand what checks you want to add over those already being done. I guess he wants the reverse dependencies to be checked twice. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Thu, Jun 14, 2007 at 02:33:32PM +0100, Luis Matos wrote: kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. No. The nvidia kernel packages are a particular case where the module packages were willfully broken in testing by the release team because of long-outstanding RC bugs in related nvidia packages. Again, this was a necessary trade-off which reduced the overall number of release-critical problems in testing. i am generally speaking ... the nvidia package was an example that occurred to me (and i stop using it since then). Other problems like that happened to me. It's an example that does not support your thesis. I have explained to you that packages are *not* propagated automatically to testing when they break the installability of other packages present in testing; that the nvidia modules packages include metapackages designed to keep the modules in sync with the kernel; and that the nvidia modules were specifically broken *by the release team* during the etch release because this was the lesser evil. You insist that there need to be more automatic checks for testing, but you haven't identified any checks that aren't already in place. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 14:40 -0700, Steve Langasek escreveu: It's an example that does not support your thesis. I have explained to you that packages are *not* propagated automatically to testing when they break the installability of other packages present in testing; that the nvidia modules packages include metapackages designed to keep the modules in sync with the kernel; and that the nvidia modules were specifically broken *by the release team* during the etch release because this was the lesser evil. You insist that there need to be more automatic checks for testing, but you haven't identified any checks that aren't already in place. yes, i failed to show an existing situation ... i no longer use testing. I know how the passage is done. dependencies are checked. But, i had issues in the past (etch testing cycle). Since Gustvo raised the testing problems, i thought i should gave my word has *testing* user. You grabbed the nvidia problem ... that was just one. Other was with xorg and xbase-clients (a newer version of xbase-clients[0] was needed), when the xorg 7.0 x11-common package entered testing. xorg 7.0 (or 6.9 ... i don't remember) dropped the use of the symlink to /usr/X11/bin (or other place, i can't remember) ... i even opened a bug [1] (which i closed a few weeks ago - this was the 6.x to 6.9 transition). i just want to say that things like these can't happen ... (in this case, reverse dependencies where ok ... by the way). [0] http://packages.debian.org/unstable/x11/xbase-clients [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370370 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Thu, Jun 14, 2007 at 08:10:08PM +0200, Martijn van Oosterhout wrote: Actually, it seems to me the real problem is that when a new kernel is installed it is immediately used by the bootloader on the next reboot, without asking. That's because you installed the meta-package, saying I want to run the newest kernel without asking. If you don't want that, don't install the meta-package and install new kernel versions as they appear. Also, see Raphael Hertzog's comment about Breaks: which looks very promising for solving the rest of your issues (unless you install stuff not using module-assistant or an equivalent) Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Michael Banck wrote: On Thu, Jun 14, 2007 at 08:10:08PM +0200, Martijn van Oosterhout wrote: Actually, it seems to me the real problem is that when a new kernel is installed it is immediately used by the bootloader on the next reboot, without asking. That's because you installed the meta-package, saying I want to run the newest kernel without asking. If you don't want that, don't install the meta-package and install new kernel versions as they appear. The behavior Martijn explains is because update-grub doesn't update the default kernel. This means that if you had a default 0, and the new kernel gets at the top of the list (which is usually the case), it will get booted next time -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
* Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]: On 12/06/07 at 22:23 +0200, Luk Claes wrote: NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? We have that policy, just nobody who does the QA-bits needed to make that happen. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) AFAIR apart from having to edit a few config files it was quite painless (I've upgraded when Xorg was still in experimental). OTOH the current xserver-xorg-video-ati snapshot in experimental is not suitable for everyday use (the crash in DPMS is a blocker for me) so I'd be quite annoyed if it was uploaded to unstable; but being able to easily test new versions to see if the bugs are still there is very useful. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 05:40:29PM -0300, Gustavo Franco wrote: I disagree, that's what we've with experimental today mainly due to the fact that there's just a few packages there. Consider everybody uploading every package for unstable instead. Experimental can and does contain packages that are _known_ to be broken and unusable. Uploading these to unstable would mean that no one would test unstable any more (right now you can _decide_ if you want to risk installing known-broken packages from experimental; removing experimental also removes that choice). And if no one tests unstable because it's just too broken, then bugs will not be found before packages migrate to testing (the method of migration, being manual or automatic does not matter here at ALL), meaning the quality of testing would drop significantly. I don't see that as an improvement... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Ter, 2007-06-12 às 17:03 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu: Personally I think the current system is fine. just a note, as user: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) You won't find a contractual guarantee from Debian about either of these things, for *any* of the Debian suites. look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). - There are no public, announced, snapshots from testing (so people can download and install). Other than the d-i betas? yes ... for example, every 6 months ... all teams can organize to ship a preview release of debian. Teams will know that day X at Y time full set of cd's will be built. so teams will have +/- stable packages in testing and debian will have an automatic version. d-i per se is not a debian release. This will give users another view of debian. For example, debian lenny preview A would be announced and people would install it and test it. Otherwise, no one will use it. - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. (... and this is why getting rid of experimental is a horrible idea.) i think we cannot give up of experimental ... it's a place for ... experimental packages and preview packages (samba 4, for example), - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) raises hand you lucky person. :) - kernel modules simply die, when the kernel is upgraded, but the modules aren't ( people using non-free nvidia modules, raise their hands; people using wifi modules raise their hands) That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. And, just a note ... we are talking about testing, not stable. So ... automatically pass to testing ... is bad. Invalid premise - invalid conclusion. it's not invalid ... it's valid by the reasons above. So ... more package tests are need (such as test reverse depends) What do you mean? i mean that the passage f packages from unstable to testing needs to be more difficult. for example, if a package has, for example, important or serious bugs, should not pass to testing,even if it has security issues ... because it will break testing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. Then create an empty nvidia-module package that depends on the latest nvidia-module-X.Y.Z package and conflicts with linux-image-$ARCH X.Y.Z. Just because you're using non-free kernel modules does not mean that everyone else _not_ using those modules should be penalized. Or alternatively, just reboot with the old kernel just like you'd do when you found out that any random driver you happen depend on stops working in the new kernel version. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) You won't find a contractual guarantee from Debian about either of these things, for *any* of the Debian suites. look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. You are never going to get a statement from the Debian project telling users to use one suite or another (or at least, you shouldn't); the most we should be doing is giving users a list of pros and cons for each suite and letting them decide which fits their needs. I'm all in favor of reducing the number of decisions users have to make *in the software* :), but on something as high-level as which distro/suite to use, misestimating a user's needs is the kind of thing that will sour the user on Debian for a very long time. There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). More strict upload rules for what? - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to unstable? Today, no? In a new scenario where unstable isn't automatic? Yes. Shall we try it and see whether all the release team quits in frustration and disgust, making lenny's release cycle the longest ever? FUD. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco [EMAIL PROTECTED] writes: On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to unstable? Today, no? In a new scenario where unstable isn't automatic? Yes. That idea is so crappy that you should probably be hit over the head with a stick. Each shlib-bumping upload of glibc to unstable means that it needs to transition before all other r-deps can move to testing. Uploading experimental glibcs that are far from ready to unstable is the perfect way to get the release team to quit. Marc -- BOFH #287: Telecommunications is downshifting. pgpObT6G2RIwM.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On 13/06/07 at 11:19 +0200, Andreas Barth wrote: * Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]: On 12/06/07 at 22:23 +0200, Luk Claes wrote: NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? We have that policy, just nobody who does the QA-bits needed to make that happen. What would be those QA bits ? It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). I could even work on that during debconf, but then, there's the problem of knowing who has the authority to remove packages from unstable. Such tasks don't get you a lot of karma points, so, if removals are not requested by someone with authority (release team or ftpmaster), this will probably result in a lot of flames. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 08:02:53AM -0300, Gustavo Franco wrote: On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to unstable? Today, no? In a new scenario where unstable isn't automatic? Yes. ITYM in a scenario where we stop bothering to use britney for modular transitions into testing because it no longer works, and we replace it instead with a periodic forklift copy from unstable to testing with all bugs and all installability problems caused by builds, and while we're at it let's go back to causing it frozen, HTH HAND. Shall we try it and see whether all the release team quits in frustration and disgust, making lenny's release cycle the longest ever? FUD. My bad, let me try to eliminate the uncertainty: you're designing in a vacuum, you haven't bothered to inform yourself how testing works and therefore have failed to understand the consequences of your proposal in spite of my efforts to hint you in the right direction, and it's a dumb idea. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Lucas Nussbaum [EMAIL PROTECTED] writes: On 13/06/07 at 11:19 +0200, Andreas Barth wrote: * Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]: On 12/06/07 at 22:23 +0200, Luk Claes wrote: unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? We have that policy, just nobody who does the QA-bits needed to make that happen. What would be those QA bits ? Automatic checks and reports. It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Yes. One would just need to do it (and decide some basic rules)... I could even work on that during debconf, but then, there's the problem of knowing who has the authority to remove packages from unstable. Such tasks don't get you a lot of karma points, so, if removals are not requested by someone with authority (release team or ftpmaster), this will probably result in a lot of flames. I think that a package that has been in unstable for a whole release cycle without entering testing should probably live in experimental or not in Debian at all. I guess that is something most people can agree on. Marc -- BOFH #337: the butane lighter causes the pincushioning pgpRPbtyZsE2b.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
* Gustavo Franco [Mon, 11 Jun 2007 18:20:17 -0300]: * Switch unstable (release) for not automatic updates This seems like the key of your proposal, and this is, in simple words and AIUI, why it would not bring any improvements: - Our main objective is to have as few bugs in testing as possible, since testing is what becomes stable. - Our current way to achieve that is by extensive testing of unstable; as Joey Hess pointed out, most bug reports come from people using unstable, and we use those bug reports to keep packages in bad shape out of testing, and thus out of stable. - By swithing unstable to NotAutomatic, you expect to get more users of testing instead, thus getting more people to test testing, and find bugs *there*. Which is bad, because bugs are discovered *once the packages have entered testing*, which is too late. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org — As the ship lay in Boston Harbor, a party the colonists dressed as red Indians boarded the vessel, behaved very rudely, and threw all the tea overboard, making the tea unsuitable for drinking. Even for Americans. -- George W. Banks in “Mary Poppins” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote: It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Such a list exists: http://bjorn.haxx.se/debian/oldest.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 13/06/07 at 15:19 +0100, Paul Wise wrote: On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote: It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Such a list exists: http://bjorn.haxx.se/debian/oldest.html Yes, but there's a bug. Let's take eglade as an example. The list says 1341 days. Actually, it is 1341 days since that package last entered testing. But it was in testing on 2006-11-20 (it was removed from testing on 2006-11-21). Which is much shorter than 1341 days, and also more acceptable. The correct fix for this would probably be to analyze the Sources files on snapshot.d.n... -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Lucas Nussbaum [EMAIL PROTECTED] writes: On 13/06/07 at 15:19 +0100, Paul Wise wrote: On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote: It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Such a list exists: http://bjorn.haxx.se/debian/oldest.html Yes, but there's a bug. Let's take eglade as an example. The list says 1341 days. Actually, it is 1341 days since that package last entered testing. But it was in testing on 2006-11-20 (it was removed from testing on 2006-11-21). Which is much shorter than 1341 days, and also more acceptable. Yeah, but I guess you need to ignore that day anyway, because I seem to remember that this was a britney problem that marked all packages as rc-bug-free or something. Marc -- Fachbegriffe der Informatik - Einfach erklärt 134: Benutzerfreundlichkeit Der Benutzer hat zum Admin freundlich zu sein. (Thorsten Fenk) pgpuPk4XvlAdY.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
Le mardi 12 juin 2007 à 17:40 -0300, Gustavo Franco a écrit : I disagree, that's what we've with experimental today mainly due to the fact that there's just a few packages there. Consider everybody uploading every package for unstable instead. This has already been tried by Fedora and Mandriva, which ship development versions of their packages in the top-of-the-edge releases. The result is that developers are more focused on how to deal with utter breakage of their own installation than on improving software they maintain. Please, avoid that. And do never, ever forget that rule before uploading: UNSTABLE PACKAGES SHOULD BE RELEASE QUALITY Mistakes happen, but to detect them we need people using unstable, and people won't use a completely broken distribution. People knowingly uploading a package unsuitable for a stable release should be forced into working as d-i release manager for 3 months. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 03:45 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. You are never going to get a statement from the Debian project telling users to use one suite or another (or at least, you shouldn't); the most we should be doing is giving users a list of pros and cons for each suite and letting them decide which fits their needs. I'm all in favor of reducing the number of decisions users have to make *in the software* :), but on something as high-level as which distro/suite to use, misestimating a user's needs is the kind of thing that will sour the user on Debian for a very long time. Yes, but debian *only* publicites the use of stable (that home users or desktop users tag as stale). If you publicity say that testing (or maybe this should be renamed :( ) is the way for an up-to-date, latest software distribution , then they will use it. for now it only states that testing is ... testing, right? There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). More strict upload rules for what? To have security updates in testing, easily and stable ... not to upgrade a new version into testing that can break stuff, or some mixed unstable and testing upload. - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? Some packages are allowed to pass into testing even if other depends on it, but has issues that will take some time to resolve. This will make that that package, that is now in testing, will not be installable in anyway. This happens sometimes. That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. true. nvidia-kernel (meta packge) depends on linux-image-2.6.10. a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did not pass because it is too young. nvidia-kernel is unusable. Or the user reboots with the new kernel, or edits by hand the xorg.conf . I used testing since about 3 months after sarge was released ... it was quite stable, but some transitions broke my system and it should not happen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 12:39 +0200, Gabor Gombas escreveu: On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. Then create an empty nvidia-module package that depends on the latest nvidia-module-X.Y.Z package and conflicts with linux-image-$ARCH X.Y.Z. Just because you're using non-free kernel modules does not mean that everyone else _not_ using those modules should be penalized. but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. you had the example with nvidia modules, what about wifi modules ... what about ... camera modules (i think they are all in the same source package now). They all BREAK in this case. How many of debian developers and contributors use these modules? Or alternatively, just reboot with the old kernel just like you'd do when you found out that any random driver you happen depend on stops working in the new kernel version. that is an *extreme* situation ... when there is BUG in the software ... not just because some package entered testing and broke your system. Gabor cheers, Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... if ... *if* i had used module-assistant to use nvidia graphics (or camera modules, or wifi, or what else), i would not mind to do that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos [EMAIL PROTECTED] writes: having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... If you're using non-free drivers, the first part of your sentence above doesn't apply. Usually, however, those non-free drivers that are built for each kernel get built before the new kernel migrates to testing, but given that those builds can't be handled by the general mechanism for building add-on modules, I don't think the currency of those builds can be guaranteed. My recommendation is to always use module-assistant for all non-free drivers that you want to use. That way, if there is a build in non-free, you can be pleasantly surprised, but your normal method will always work. Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote: Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. Could you please elaborate on this mechanism, or point to an URL? (If it's been discussed here and I just missed it, I apologize -- I skip most of -devel these days :-) ) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos wrote: Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... Installing a newer kernel is not an upgrade, in a sense. You are installing new software alongside the old one. Thus the usual expectations don't hold. PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Steinar H Gunderson [EMAIL PROTECTED] writes: On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote: Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. Could you please elaborate on this mechanism, or point to an URL? (If it's been discussed here and I just missed it, I apologize -- I skip most of -devel these days :-) ) http://packages.qa.debian.org/l/linux-modules-contrib-2.6.html My understanding of the goal is that this package will build-depend on the source packages of all the free external drivers that can support this sort of automated build and then only the linux-modules-contrib maintainers have to deal with the ever-changing exact list of kernel versions for which modules should be built. I don't know how far along this is yet. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Russ Allbery [EMAIL PROTECTED] writes: Steinar H Gunderson [EMAIL PROTECTED] writes: On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote: Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. Could you please elaborate on this mechanism, or point to an URL? (If it's been discussed here and I just missed it, I apologize -- I skip most of -devel these days :-) ) http://packages.qa.debian.org/l/linux-modules-contrib-2.6.html Also, and more interestingly: http://packages.qa.debian.org/l/linux-modules-extra-2.6.html contrib is just the ones that go into contrib, of course. (D'oh.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... If you're using non-free drivers, the first part of your sentence above doesn't apply. I agree ... so what about the linux-modules-contrib-2.6 source package? Usually, however, those non-free drivers that are built for each kernel get built before the new kernel migrates to testing, but given that those builds can't be handled by the general mechanism for building add-on modules, I don't think the currency of those builds can be guaranteed. agreed. My recommendation is to always use module-assistant for all non-free drivers that you want to use. That way, if there is a build in non-free, you can be pleasantly surprised, but your normal method will always work. i don't think that this is useful in a debian way. That is equal to tell the maintainer to stop his work. Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. i hope so. i want to tell a couple of things: 1. My critic goes for the automatic passage of packages that make other packages (already available in testing) uninstallable or conflictive. In these 2 sets are packages that have reverse depends and, for example, the kernel. 2. You, like other, confirm this situation, but for some reason, you just don't explicit agree with it. 3. My main objective is to turn testing an *REAL* alternative for stable. I've used testing (now i am running stable). It's quite stable, but some upgrades break stuff. This breakage should not happen and packages that cause breakage should not pass into testing. 4. Making testing more visible as a bleeding edge (+/-) *stable* distribution would be a nice thing and people would appreciate. Making snapshots (full cd sets called previews, for one example) would make it visible and useful. Users with testing (commonly home or power users) can see it's system evolute, while it remains stable, usable and bleeding edge (stability would be preferred over bleeding edge). 5. CUT is *THE* option for testing that would permit this. just my thoughts. Luis Matos -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
* Joey Hess [EMAIL PROTECTED], [2007-06-11 19:56 -0400]: Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ Snapshots should be made available regularly, so that users who need a firm foundation for deployment have one. They'd be numbered, so we could call them cut 4, cut 5, etc. Each would be a snapshot of testing at a point when it was in especially good shape. Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. I realize that 'freezing' testing when it is in good shape we adhere to the when it's ready philosophy, but can you think of a rough estimate about how often it could happen? ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu: Luis Matos wrote: Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... Installing a newer kernel is not an upgrade, in a sense. You are installing new software alongside the old one. Thus the usual expectations don't hold. the usual expectation that i have with a new kernel is to improve my operating system ... that includes no regressions on supporting my hardware - for example, wifi or graphic card. PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. what about checking the *-modules-2.6.A packages available and compare them with the previous version? if the count of both are equal, then kernel *and* modules can go into testing. If, for some reason a module is not available or cannot migrate into testing, kernel would not migrate. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu: * Joey Hess [EMAIL PROTECTED], [2007-06-11 19:56 -0400]: Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ Snapshots should be made available regularly, so that users who need a firm foundation for deployment have one. They'd be numbered, so we could call them cut 4, cut 5, etc. Each would be a snapshot of testing at a point when it was in especially good shape. Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. this makes the snapshots just like the current ones (i think cd sets are built weekly r monthly, can anyone confirm this?) I realize that 'freezing' testing when it is in good shape we adhere to the when it's ready philosophy, but can you think of a rough estimate about how often it could happen? think about transitions .. let's get etch release cycle example. i think 2 or 3 snapshots would be good. (not time ordered) 1. transition to xorg 2. new gnome version 3. new kde version 4. new gcc version these are quite predictable, and i think the main objective is not FULL stability, but to have a work base. So, if we predict that in the next month a big transition will be made, then, a snapshot will be made with the transition objectives. When they are accomplished, debian would ship a snapshot. By scheduling the snapshot, other maintainers can upload their new packages that will be included in the snapshot. remind you that if packages only pass to testing *ready for stable* (more or less) any snapshot would be quite stable and usable (+/- like an ubuntu release - this was a bad joke). Having this *release* would make people to use more debian. Of course the system would be continuously updated. ciao, ema best regards, Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos [EMAIL PROTECTED] writes: Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu: My recommendation is to always use module-assistant for all non-free drivers that you want to use. That way, if there is a build in non-free, you can be pleasantly surprised, but your normal method will always work. i don't think that this is useful in a debian way. That is equal to tell the maintainer to stop his work. I think this is a ridiculous exaggeration. module-assistant is not difficult to use. Installing the correct kernel modules for your kernel is a one-line command. i want to tell a couple of things: 1. My critic goes for the automatic passage of packages that make other packages (already available in testing) uninstallable or conflictive. In these 2 sets are packages that have reverse depends and, for example, the kernel. 2. You, like other, confirm this situation, but for some reason, you just don't explicit agree with it. For non-free, this is inevitable without significant changes to the way that Debian works that I don't believe will happen. Debian has provided a different solution in the form of module-assistant that in my experience works great. I recommend that you learn how to use it rather than tilting at windmills. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 11:53:24AM +0200, Gabor Gombas wrote: On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) AFAIR apart from having to edit a few config files it was quite painless (I've upgraded when Xorg was still in experimental). OTOH the current xserver-xorg-video-ati snapshot in experimental is not suitable for everyday use (the crash in DPMS is a blocker for me) so I'd be quite annoyed if it was uploaded to unstable; but being able to easily test new versions to see if the bugs are still there is very useful. By the time it hit testing it worked pretty well for most people. We broke a few things, but it was nice for just about everyone. Everyone except those people using proprietary drivers, but they know they've already dug their own grave there. If Luis wants to keep whining about it, I suggest he talk to nvidia. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
David Nusinow [EMAIL PROTECTED] writes: By the time it hit testing it worked pretty well for most people. We broke a few things, but it was nice for just about everyone. Everyone except those people using proprietary drivers, but they know they've already dug their own grave there. If Luis wants to keep whining about it, I suggest he talk to nvidia. I didn't have many problems even with proprietary drivers. I thought it went quite smoothly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 16:18 -0700, Russ Allbery escreveu: For non-free, this is inevitable without significant changes to the way that Debian works that I don't believe will happen. Debian has provided a different solution in the form of module-assistant that in my experience works great. I recommend that you learn how to use it rather than tilting at windmills. this is not a discussion on how to support non-free drivers ... module-assistant is not an answer to the modules-contrib and modules-extra (at least). (i have used module-assistant and i think is a great tool) the problem here (that happened to me with other packages) is that some packages with reverse dependencies passed into testing making other packages uninstalable. kernel and modules is just one problem. my point here is that i think the current structure is ok, but ... the passage to testing has to be done with more care (care it already has). i am not whining about the use of nvidia non-free drivers ... i am whining about have a good CUT and *THAT* requires the paragraph before. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 19:20 -0400, David Nusinow escreveu: By the time it hit testing it worked pretty well for most people. We broke a few things, but it was nice for just about everyone. Everyone except those people using proprietary drivers, but they know they've already dug their own grave there. If Luis wants to keep whining about it, I suggest he talk to nvidia. lol ... the passage from xorg 6 to 7 was a big passage ... i had some uninstalable packges (not nvidia related), i even opened a bug[0], that i closed some weeks ago when i reviewed the bugs i've submitted. this is one example about the problem i am trying to get attention to. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370370 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 05:32:01PM +0100, Luis Matos wrote: Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? Some packages are allowed to pass into testing even if other depends on it, but has issues that will take some time to resolve. This will make that that package, that is now in testing, will not be installable in anyway. This happens sometimes. Well, tough. Take it up with the maintainers who don't coordinate their uploads to unstable with the maintainers of related packages. The release team only breaks packages in testing when we *have* to do so to move the release forward (meaning, a net reduction in RC problems). That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. No. The nvidia kernel packages are a particular case where the module packages were willfully broken in testing by the release team because of long-outstanding RC bugs in related nvidia packages. Again, this was a necessary trade-off which reduced the overall number of release-critical problems in testing. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. true. nvidia-kernel (meta packge) depends on linux-image-2.6.10. a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did not pass because it is too young. You either don't know how testing works, or you don't know how the Debian kernel packages are structured. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Mon, 11 Jun 2007 18:20:17 -0300, Gustavo Franco [EMAIL PROTECTED] said: 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates This is one of the worst proposals I have seen. Removing experimental means that there is no place to pout in packages which are probably broken, but really interested persons should please test. There would be no way of distinguishing those from new packages, ought to be OK, please test stuff. Prevent auto up0dating, means that, along with the above change, unstable becomes too annoying to run. With people no longer running unstable, bugs do not get caught. Instead, bugs propogate to testing. So, effectively, you have removed testing (and relabled unstable as testing). With no real bug triage before testing, we are back to the old release dilemma: the distribution we release from has lots of bugg packages. Welcome back to 1/2 year long freezes. Why one earth would w3e want to regress to the days before testing? manoj -- Quick, sing me the BUDAPEST NATIONAL ANTHEM!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Mon, Jun 11, 2007 at 07:56:13PM -0400, Joey Hess wrote: This assumes that experimental is used by a lot of people, which I doubt, especially given the default apt pins and the numbers above. There's also the fact that if you remove experimental it's easy enough for people to set up their apt repositories somewhere if they want to provide packages outside of unstable. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
* Joey Hess [EMAIL PROTECTED] [2007-06-11 19:56]: Gustavo Franco wrote: * developers and most active contributors are pretty much using only stable or unstable and not testing. What's your data? It is well known that 87.9% of the assertions made by Debian developers in the mailing lists are not based on factual data. (Please, do not ask me where I got that figure from :-) -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: Sorry, i forgot CUT it looks like a 0 proposal since it came first. How and when do you plan to start a team for that and have you considered who from other teams will need to join/agree on the idea? I don't necessarily start a team for every proposal I make. :-) I'm interested to see what the general reception is to the ideas in CUT, I don't know if I've identified everything that needs to be done, or have perhaps chosen some things to do that arn't really necessary. A fun though not entirely reliable data source is the APT prefers lines inserted by reportbug in bug reports. A quick grep[1] of the BTS gives: 51988 APT prefers unstable 30351 APT prefers testing 2076 APT prefers stable 420 APT prefers experimental (...) (For bonus fun, someone could graph how these change over time..) Any idea on how to collect more reliable data in a opt-in base? Does a survey on pentabarf (or public acessible) during debconf makes sense? The numbers are not entirely reliable since a) not everyone uses reportbug b) some people run reportbug on a machine that doesn't have the bug c) some people file many more bugs reports than others d) it's likey that users of some suites tend to generate more bug reports than others e) there's no differentiation between developers and users d) duplicate bugs are not accounted for But I do think that the numbers are a pretty good indication of how much use testing receives by the kind of user/developer who contributes to Debian. It's not clear to me how a straw poll at Debconf would result in better numbers. Wrong, if I'm asking for experimental removal I'm assuming that there's not a lot of people using that. Considering the rest of your argument, definitely a lot of people will use testing instead this 'new unstable'. Do you see? No, I don't understand. As I said, unstable will not become significantly more unstable if all experimental uploads are directed there. -- see shy jo signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: Let me outline the 'testing' pros and cons from my point of view: cons - * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. Packages won't transition if they are not ready. This can mean: not built on all release archs, not installable in testing, making other packages in testing uninstallable, having more RC bugs in unstable than in testing or not waiting long enough in unstable. The Release Team can force packages in, block packages from going in, change the waiting time and hint some packages to go in together. I've two different proposals to address the cons trying to avoid as much as possible create new cons, they are: 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental Which would remove a testing ground which doesn't influence the releasability of a package. People are urged to upload to experimental if the version they're uploading is not meant to transition to testing. I don't see what advantage removing experimental has? * Switch unstable (release) for not automatic updates They are only automatic as far as the Release Team wants them to be as explained earlier... [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. This might be better solved by CUT IMHO. 2) The 'remove testing' proposal * Add enough experimental autobuilders for our target architectures There are experimental autobuilders for all archs. * Warn developers and contributors that experimental is for transitions and adopt a sort of 'if in doubt upload to experimental' approach. It's really important This is more or less what unstable is meant for at the moment... The developers and contributors might keep using unstable and some pieces of experimental. Things will get harder during freeze, but I believe it's still better than we've today unless developers and contributors don't cooperate out of freeze and ignore the 'experimental if in doubt' approach. That's a status quo AFAICS. As a Release Team we are thinking about solutions to improve testing migration like using versioning instead of less RC bugs, better udeb handling, automate easy hinting, ease library transitions etc. which would IMHO help CUT. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote: Gustavo Franco wrote: Sorry, i forgot CUT it looks like a 0 proposal since it came first. How and when do you plan to start a team for that and have you considered who from other teams will need to join/agree on the idea? I don't necessarily start a team for every proposal I make. :-) Oh, i just followed the I propose that we form a team sentence you wrote there. :-P I'm interested to see what the general reception is to the ideas in CUT, I don't know if I've identified everything that needs to be done, or have perhaps chosen some things to do that arn't really necessary. I think that the proposal is good and we need bless and a team with people from the following others teams: RM team, security testing team, d-i and probably kernel. This new team will work for CUT and be its voice inside the others teams, exactly as we do with Debian Desktop. Debian Desktop as a whole isn't a goal of every related team involved, but the people involved in the Debian Desktop are able to make a difference for our aims in each one of them. A fun though not entirely reliable data source is the APT prefers lines inserted by reportbug in bug reports. A quick grep[1] of the BTS gives: 51988 APT prefers unstable 30351 APT prefers testing 2076 APT prefers stable 420 APT prefers experimental (...) (For bonus fun, someone could graph how these change over time..) Any idea on how to collect more reliable data in a opt-in base? Does a survey on pentabarf (or public acessible) during debconf makes sense? The numbers are not entirely reliable since a) not everyone uses reportbug b) some people run reportbug on a machine that doesn't have the bug c) some people file many more bugs reports than others d) it's likey that users of some suites tend to generate more bug reports than others e) there's no differentiation between developers and users d) duplicate bugs are not accounted for But I do think that the numbers are a pretty good indication of how much use testing receives by the kind of user/developer who contributes to Debian. It's not clear to me how a straw poll at Debconf would result in better numbers. Do you think that the numbers are positive in terms of testing usage, really? I see the numbers even if not that reliable as proof of my argument that just a few (almost half if compared with unstable) bug reporters are actually using testing. Not better numbers, but statistics: x% of developers are using foo or bar. Wrong, if I'm asking for experimental removal I'm assuming that there's not a lot of people using that. Considering the rest of your argument, definitely a lot of people will use testing instead this 'new unstable'. Do you see? No, I don't understand. As I said, unstable will not become significantly more unstable if all experimental uploads are directed there. Exactly the first proposal, remove experimental and upload everything to unstable with the difference that unstable will become not automatic as experimental is today. Keep migration from unstable to testing as it's and that's it. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Hi Luk, On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote: Gustavo Franco wrote: (...) * Switch unstable (release) for not automatic updates They are only automatic as far as the Release Team wants them to be as explained earlier... I'm not writing about automatic transition from unstable to testing through scripts. It was about the Release file. It's pretty much the key of that proposal and why I've suggested remove experimental, because in a scenario that we switch unstable to not automatic, experimental will be redundant. [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. This might be better solved by CUT IMHO. Probably, but the remove experimental and CUT proposals could be implemented at the same time. (...) As a Release Team we are thinking about solutions to improve testing migration like using versioning instead of less RC bugs, better udeb handling, automate easy hinting, ease library transitions etc. which would IMHO help CUT. Could you please write more about the versioning instead of less RC bugs idea? thanks, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote: Considering that we know that experimental is not a full branch and there's no migration from experimental to unstable, do you agree then we could remove experimental and switch unstable automatic nature to not automatic (release) and keep it's current features: 'full' branch, migration from unstable to testing and others ? Eh, I don't think I understand what you're suggesting here. Perhaps a few questions will help: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? Personally, I think the net effect on _unstable_ achieved by removing _experimental_ will be zero. * What do you mean by switch unstable automatic nature to not automatic * How does that fit in with keep it's current features: 'full' branch, migration from unstable to testing and others? I'm afraid you've completely lost me in that bit of your suggestion. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: Do you think that the numbers are positive in terms of testing usage, really? I see the numbers even if not that reliable as proof of my argument that just a few (almost half if compared with unstable) bug reporters are actually using testing. Not better numbers, but statistics: x% of developers are using foo or bar. For testing to remain at a good quality level, there needs to be a large group of people using (and testing) unstable. That nearly 2x as many bugs are filed from unstable as from testing indicates to me that a healthy number of people are using unstable. I'd be happy if there were an even larger number of users happily using testing, without encountering and filing a lot of bug reports. As seems to be to case with stable[1]. The number of bug reports filed from testing actually seems high to me. Although it's hard to say without more analysis (perhaps looking at the severities of those bugs). Exactly the first proposal, remove experimental and upload everything to unstable with the difference that unstable will become not automatic as experimental is today. Keep migration from unstable to testing as it's and that's it. Making apt not automatically upgrade to newer versions from unstable doesn't seem useful. It's useful in the case of exeperimental because any given user of experimental only wants to pull a few packages from it. Most users of unstable want to pull _all_ available updates from it. -- see shy jo [1] We know from popcon that currently three times as many users use stable as unstable+testing. signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Wouter Verhelst [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote: Considering that we know that experimental is not a full branch and there's no migration from experimental to unstable, do you agree then we could remove experimental and switch unstable automatic nature to not automatic (release) and keep it's current features: 'full' branch, migration from unstable to testing and others ? Eh, I don't think I understand what you're suggesting here. Perhaps a few questions will help: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? Personally, I think the net effect on _unstable_ achieved by removing _experimental_ will be zero. I think it will have a positive effect if we add 'NotAutomatic: yes' into unstable release file. * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. * How does that fit in with keep it's current features: 'full' branch, migration from unstable to testing and others? We've no experimental to unstable migration as you know, but the 'new unstable' should keep its current features as full branch (all the packages) and migration. I'm afraid you've completely lost me in that bit of your suggestion. I hope I was more clear now and you figure out the impact of this change. :-) thanks, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote: Gustavo Franco wrote: Do you think that the numbers are positive in terms of testing usage, really? I see the numbers even if not that reliable as proof of my argument that just a few (almost half if compared with unstable) bug reporters are actually using testing. Not better numbers, but statistics: x% of developers are using foo or bar. For testing to remain at a good quality level, there needs to be a large group of people using (and testing) unstable. That nearly 2x as many bugs are filed from unstable as from testing indicates to me that a healthy number of people are using unstable. Exactly my point, again: Contributors and developers are using unstable or stable more than testing. I would like to see a scenario where we keep a lot of people using unstable with no automatic updates to force them pick how and what much of that they want, but at the same time use as base of their system testing. There's no better way to make CUT a reality, IMHO. The two proposals (CUT and 'remove experimental and change unstable to not automatic updates') aren't mutually exclusive. (...) Exactly the first proposal, remove experimental and upload everything to unstable with the difference that unstable will become not automatic as experimental is today. Keep migration from unstable to testing as it's and that's it. Making apt not automatically upgrade to newer versions from unstable doesn't seem useful. It's useful in the case of exeperimental because any given user of experimental only wants to pull a few packages from it. Most users of unstable want to pull _all_ available updates from it. I don't get it, as you also realized: unstable _is_ experimental. Let us develop over testing with some pieces of unstable, no need to have two experimental branches once we switch unstable to not automatic updates. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tuesday 12 June 2007 21:40, Gustavo Franco wrote: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? I think it will have a positive effect if we add 'NotAutomatic: yes' into unstable release file. Are you also willing to promote uploading packages that are quite probably broken in some ways, but the maintainer still would like to see tested to unstable? I don't think I would like that at all! An essential difference between unstable and experimental is that unstable has should be working packages, while experimental has quite likely still has issues packages. If experimental were dropped, how the hell am I supposed to distinguish between the two? Personally I think the current system is fine. I certainly don't think I would like the hassle of having to decide for myself (based on no available information) if I should upgrade a package or not. For me, the only reasons _not_ to upgrade a package in unstable are: - broken dependencies: handled perfectly fine by packing tools, to be expected for unstable - severe known issues: should be fixed ASAP by maintainer; aptitude makes it really easy to forbid a known broken version but automatically update once a new (hopefully fixed) version becomes available Cheers, FJP pgpVbDp3Z19RX.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On Tuesday 12 June 2007 21:51, Gustavo Franco wrote: I don't get it, as you also realized: unstable _is_ experimental. No, it most certainly is *not*, and any developers who treat it as such should be drawn and quartered. pgpvlthFzQSRb.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: On 6/12/07, Wouter Verhelst [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote: Considering that we know that experimental is not a full branch and there's no migration from experimental to unstable, do you agree then we could remove experimental and switch unstable automatic nature to not automatic (release) and keep it's current features: 'full' branch, migration from unstable to testing and others ? Eh, I don't think I understand what you're suggesting here. Perhaps a few questions will help: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? Personally, I think the net effect on _unstable_ achieved by removing _experimental_ will be zero. I think it will have a positive effect if we add 'NotAutomatic: yes' into unstable release file. Doing that would just annoy people, nothing more. Those who only have 'unstable' lines in their sources.list will not see any change. Those who have only 'testing' in their sources.list will not see any change, either. The only people who will see any difference from your proposed change are people who have sources.list lines for multiple distributions in their sources.list, and these are typically advanced users already anyway, with perhaps a rather complex set of apt preferences. Given that, I don't think you'd be able to achieve any postive effect by changing the defaults of what happens if you add both unstable and testing entries to sources.list. Additionally, there's no need to drop experimental if you want to make this type of change. If you want to encourage more people to use testing, fine; that's not a bad idea in itself. But by changing the defaults of what happens in something that really is a corner case and by removing something else that's totally unrelated, you don't do that. Rather, you annoy people who know what the current defaults are, and who expect that these defaults haven't been randomly changed while they weren't watching. [...] -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote: Gustavo Franco wrote: Do you think that the numbers are positive in terms of testing usage, really? I see the numbers even if not that reliable as proof of my argument that just a few (almost half if compared with unstable) bug reporters are actually using testing. Not better numbers, but statistics: x% of developers are using foo or bar. For testing to remain at a good quality level, there needs to be a large group of people using (and testing) unstable. That nearly 2x as many bugs are filed from unstable as from testing indicates to me that a healthy number of people are using unstable. Exactly my point, again: Contributors and developers are using unstable or stable more than testing. I would like to see a scenario where we keep a lot of people using unstable with no automatic updates to force them pick how and what much of that they want, but at the same time use as base of their system testing. There's no better way to make CUT a reality, IMHO. The two proposals (CUT and 'remove experimental and change unstable to not automatic updates') aren't mutually exclusive. (...) Exactly the first proposal, remove experimental and upload everything to unstable with the difference that unstable will become not automatic as experimental is today. Keep migration from unstable to testing as it's and that's it. Making apt not automatically upgrade to newer versions from unstable doesn't seem useful. It's useful in the case of exeperimental because any given user of experimental only wants to pull a few packages from it. Most users of unstable want to pull _all_ available updates from it. I don't get it, as you also realized: unstable _is_ experimental. Let us develop over testing with some pieces of unstable, no need to have two experimental branches once we switch unstable to not automatic updates. NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. experimental is playground, uploading packages to experimental if one is not sure they are good candidates for testing is what people should do. I don't get it at all why removing experimental would bring us anything but a more experimental unstable... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote: Gustavo Franco wrote: On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote: Gustavo Franco wrote: Do you think that the numbers are positive in terms of testing usage, really? I see the numbers even if not that reliable as proof of my argument that just a few (almost half if compared with unstable) bug reporters are actually using testing. Not better numbers, but statistics: x% of developers are using foo or bar. For testing to remain at a good quality level, there needs to be a large group of people using (and testing) unstable. That nearly 2x as many bugs are filed from unstable as from testing indicates to me that a healthy number of people are using unstable. Exactly my point, again: Contributors and developers are using unstable or stable more than testing. I would like to see a scenario where we keep a lot of people using unstable with no automatic updates to force them pick how and what much of that they want, but at the same time use as base of their system testing. There's no better way to make CUT a reality, IMHO. The two proposals (CUT and 'remove experimental and change unstable to not automatic updates') aren't mutually exclusive. (...) Exactly the first proposal, remove experimental and upload everything to unstable with the difference that unstable will become not automatic as experimental is today. Keep migration from unstable to testing as it's and that's it. Making apt not automatically upgrade to newer versions from unstable doesn't seem useful. It's useful in the case of exeperimental because any given user of experimental only wants to pull a few packages from it. Most users of unstable want to pull _all_ available updates from it. I don't get it, as you also realized: unstable _is_ experimental. Let us develop over testing with some pieces of unstable, no need to have two experimental branches once we switch unstable to not automatic updates. NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. experimental is playground, uploading packages to experimental if one is not sure they are good candidates for testing is what people should do. I believe we all know and read the official documents we can diverge about how people are actually using the branches, but that's not the point. I don't get it at all why removing experimental would bring us anything but a more experimental unstable... Sure, a more experimental (and not automatic) unstable and heavily used testing from where we do main development and could generate CUT images easily. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote: Gustavo Franco wrote: On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote: Gustavo Franco wrote: I don't get it at all why removing experimental would bring us anything but a more experimental unstable... Sure, a more experimental (and not automatic) unstable and heavily used testing from where we do main development and could generate CUT images easily. Next to having a more experimental base for testing migration which wouldn't help the Release Team at all and an unstable that probably would be used less what would it bring? Sorry, but I'm still not understanding in which way removing experimental would help. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote: Gustavo Franco wrote: Hi Luk, On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote: Gustavo Franco wrote: (...) * Switch unstable (release) for not automatic updates They are only automatic as far as the Release Team wants them to be as explained earlier... I'm not writing about automatic transition from unstable to testing through scripts. It was about the Release file. It's pretty much the key of that proposal and why I've suggested remove experimental, because in a scenario that we switch unstable to not automatic, experimental will be redundant. Ok, I misunderstood what you meant. Making unstable not automatic would mean less testing of individual versions in unstable AFAICS which is a bad thing IMHO. I disagree, that's what we've with experimental today mainly due to the fact that there's just a few packages there. Consider everybody uploading every package for unstable instead. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. I'm not at all sure that it means we won't have less people using unstable, even more every version that is uploaded to unstable... I believe that people will use testing as base for contribute and develop using lots of packages from unstable, differently from what we've with experimental as outlined above. (...) regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: Hi Luk, On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote: Gustavo Franco wrote: (...) * Switch unstable (release) for not automatic updates They are only automatic as far as the Release Team wants them to be as explained earlier... I'm not writing about automatic transition from unstable to testing through scripts. It was about the Release file. It's pretty much the key of that proposal and why I've suggested remove experimental, because in a scenario that we switch unstable to not automatic, experimental will be redundant. Ok, I misunderstood what you meant. Making unstable not automatic would mean less testing of individual versions in unstable AFAICS which is a bad thing IMHO. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. I'm not at all sure that it means we won't have less people using unstable, even more every version that is uploaded to unstable... (...) As a Release Team we are thinking about solutions to improve testing migration like using versioning instead of less RC bugs, better udeb handling, automate easy hinting, ease library transitions etc. which would IMHO help CUT. Could you please write more about the versioning instead of less RC bugs idea? It's only in it's planning stage, but would at least include RC bug versioning support in britney... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 12 June 2007 21:40, Gustavo Franco wrote: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? I think it will have a positive effect if we add 'NotAutomatic: yes' into unstable release file. Are you also willing to promote uploading packages that are quite probably broken in some ways, but the maintainer still would like to see tested to unstable? Promote 'quite probably broken in some ways' stuff isn't the motto. Upload everything that we've in experimental actually seems to be more appropriate. I don't think I would like that at all! An essential difference between unstable and experimental is that unstable has should be working packages, while experimental has quite likely still has issues packages. If experimental were dropped, how the hell am I supposed to distinguish between the two? That's the point, you would be using testing for development and cherry picking changes from unstable manually. Remember that in this scenario we still have unstable to testing transition so if you don't push stuff manually it will get there anyway, probably the second step would fine tune the unstable to testing metric but RM team already has some ideas on this camp as Luk pointed out. Personally I think the current system is fine. I certainly don't think I would like the hassle of having to decide for myself (based on no available information) if I should upgrade a package or not. For me, the only reasons _not_ to upgrade a package in unstable are: As i wrote above you don't need to decide from a user point of view, considering that the testing scripts sooner or later will do that for you, of course a lot of people will push the latest GNOME, whatever from this new unstable to user over testing and then I believe it will help our next release. (...) regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 05:32:21PM -0300, Gustavo Franco wrote: On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote: NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. experimental is playground, uploading packages to experimental if one is not sure they are good candidates for testing is what people should do. I believe we all know and read the official documents we can diverge about how people are actually using the branches, but that's not the point. This is not a matter of opinion; both experimental and unstable have a clear and well-defined meaning. Using either in a different way than what they are intended to do will *break* Debian. Don't do that. If people use experimental incorrectly, then that's a bug. It certainly isn't something we should be happy or even encouraging. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 05:25:59PM -0300, Gustavo Franco wrote: Promote 'quite probably broken in some ways' stuff isn't the motto. Upload everything that we've in experimental actually seems to be more appropriate. Eh, you lost, now. Please go read what experimental is for. I don't think I would like that at all! An essential difference between unstable and experimental is that unstable has should be working packages, while experimental has quite likely still has issues packages. If experimental were dropped, how the hell am I supposed to distinguish between the two? That's the point, you would be using testing for development and cherry picking changes from unstable manually. That doesn't work. Packages migrate from unstable to testing in only ten days; if people know that, nobody ever bothers to manually force package upgrades. [...] -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 12/06/07 at 22:23 +0200, Luk Claes wrote: NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Lucas Nussbaum wrote: On 12/06/07 at 22:23 +0200, Luk Claes wrote: NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? Actually, I support that. What about a push from unstable to experimental when a package fails to behave ? (given reasonable amount of time and notice, of course). This way, I tend to believe more people would have their eyes on experimental, and that might solve some of the problems adressed in this thread. Regards, Vincent -- Vincent Fourmond, Debian Developer http://vincent.fourmond.neuf.fr/ -- pretty boring signature, isn't it ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007, Luk Claes wrote: Making unstable not automatic would mean less testing of individual versions in unstable AFAICS which is a bad thing IMHO. I wonder whether it would make sense to suggest default pinning levels in Release files to allow people in testing to add unstable safely without relying on the default release. Not sure it would be useful for backports anymore since these do use NotAutomatic already. Currently, we only distinguish: - NotAutomatic / Automatic - default release or not all other cases have to be handled by the end user/admin; but we could (instead?) pin experimental/unstable/testing/backports/stable for users by default in the Release files to some sane values which they may override. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue June 12 2007 02:25:59 pm Gustavo Franco wrote: That's the point, you would be using testing for development and cherry picking changes from unstable manually. Remember that in this scenario we still have unstable to testing transition so if you don't push stuff manually it will get there anyway, probably the second step would fine tune the unstable to testing metric but RM team already has some ideas on this camp as Luk pointed out. Hmm, Testing came about as a permanent archive so that developers could continue to work on new stuff during the long pre-release freeze[1]. For some reason they choose to make Testing permanent and devise an automatic transfer scheme rather than expand use of the existing Experimental archive (which is what your scheme is effectively doing). Why did they make that choice, and what has changed which warrants choosing differently today? - Bruce [1] that Testing can also be used to track how the next release is shaping up was more of a side-benefit than prime motivation; and it should not be surprising that most developers run Unstable because historically Testing only became relevent just prior to a release -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu: Personally I think the current system is fine. just a note, as user: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) - There are no public, announced, snapshots from testing (so people can download and install). - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Package conflicts, etc, etc. (i used etch when it was testing since almost sarge's release). - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) - kernel modules simply die, when the kernel is upgraded, but the modules aren't ( people using non-free nvidia modules, raise their hands; people using wifi modules raise their hands) ... ... So ... automatically pass to testing ... is bad. So ... more package tests are need (such as test reverse depends) Then, announce snapshots and that testing is (+/-) STABLE, USABLE and SECURE, presenting users with a clear message in debian's site. best regards Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Ter, 2007-06-12 às 23:32 +0200, Vince HK escreveu:
Lucas Nussbaum wrote:
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
NO!
unstable is meant for packages that should be in the next stable release,
as such only packages that are in the maintainer's opinion ready to
migrate
to testing should be uploaded to unstable.
Then shouldn't we have a more aggressive policy about removals from
unstable, for packages that have failed to get into testing during the
past n months ?
Actually, I support that. What about a push from unstable to
experimental when a package fails to behave ? (given reasonable amount
of time and notice, of course).
Also providing apt with an option like apt-get install --reinstall
{oldstable, stable, testing, unstable} would be nice.
experimenting packages from experimental would be easy, and reverting
those test would be also.
This way, I tend to believe more people would have their eyes on
experimental, and that might solve some of the problems adressed in this
thread.
Regards,
Vincent
--
Vincent Fourmond, Debian Developer
http://vincent.fourmond.neuf.fr/
-- pretty boring signature, isn't it ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to unstable? Shall we try it and see whether all the release team quits in frustration and disgust, making lenny's release cycle the longest ever? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu: Personally I think the current system is fine. just a note, as user: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) You won't find a contractual guarantee from Debian about either of these things, for *any* of the Debian suites. There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. - There are no public, announced, snapshots from testing (so people can download and install). Other than the d-i betas? - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. (... and this is why getting rid of experimental is a horrible idea.) - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) raises hand :) - kernel modules simply die, when the kernel is upgraded, but the modules aren't ( people using non-free nvidia modules, raise their hands; people using wifi modules raise their hands) That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). So ... automatically pass to testing ... is bad. Invalid premise - invalid conclusion. So ... more package tests are need (such as test reverse depends) What do you mean? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Am Dienstag, den 12.06.2007, 17:25 -0300 schrieb Gustavo Franco: On 6/12/07, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 12 June 2007 21:40, Gustavo Franco wrote: * What effect do you think removing experimental will have on unstable? * How do you think it will have that effect? I think it will have a positive effect if we add 'NotAutomatic: yes' into unstable release file. Are you also willing to promote uploading packages that are quite probably broken in some ways, but the maintainer still would like to see tested to unstable? Promote 'quite probably broken in some ways' stuff isn't the motto. Upload everything that we've in experimental actually seems to be more appropriate. This means uploading of VCS snapshots to unstable, making all unstable users to snapshot testers (see e.g. glibc 2.6 snapshot in experimental). IMHO this is not a good idea. The only ways to workaround this are IMHO: (A) Allow direct upload into testing. That means, testing users are not longer protected against possible serious issues, that would have been normally detected during 10-days-period in unstable. Or (B) rename such packages, so you can have the stable and the development branch of a package side-by-side in unstable. The latter may work sometimes, but it can also be a horrible situation for the maintainer. But in every case, you will not longer have a branch for testing of packages, that are quite probably broken in some ways, but the maintainer still would like to see tested. The choice only is: Upload such a package to replace a (very probably) stable and tested branch or don't upload it at all. I cannot see any advantage. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Two proposals for a better Lenny (testing related).
I would like to ask you interested in our next release to stop and look at 'testing' for a while. I believe that now, during the start of a development cycle and during debcamp/debconf we've a interesting opportunity to review pros and cons of our current approach. We believe that 'testing' means that things shouldn't break as badly as in unstable or experimental. That's important understand the automatic update concept of unstable and the experimental non-automatic nature. In other words use unstable means that upgrade is dangerous, use unstable and experimental means that you pick how much more of the danger you want from there (experimental). Let me outline the 'testing' pros and cons from my point of view: pros - * testing is under control of release team, it's supposed to be harder to a random developer break our next release * testing is our 'daily updated' release snapshot cons - * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. * developers and most active contributors are pretty much using only stable or unstable and not testing. I've two different proposals to address the cons trying to avoid as much as possible create new cons, they are: 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. 2) The 'remove testing' proposal * Add enough experimental autobuilders for our target architectures * Warn developers and contributors that experimental is for transitions and adopt a sort of 'if in doubt upload to experimental' approach. It's really important The developers and contributors might keep using unstable and some pieces of experimental. Things will get harder during freeze, but I believe it's still better than we've today unless developers and contributors don't cooperate out of freeze and ignore the 'experimental if in doubt' approach. Note that it reduces RM team power during the development cycle, the first suggested approach doesn't. be cool, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. Of course we have a team of RMs who are able override that and apply as complex a metric as you'd like on a special-case basis. As well as urgency=high in the changelog. The tendency of dependency chains can block transitions, and keep RC bugs open unduely long in testing is a much worse problem with speed of testing migration. Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ * developers and most active contributors are pretty much using only stable or unstable and not testing. What's your data? A fun though not entirely reliable data source is the APT prefers lines inserted by reportbug in bug reports. A quick grep[1] of the BTS gives: 51988 APT prefers unstable 30351 APT prefers testing 2076 APT prefers stable 420 APT prefers experimental 373 APT prefers testing-proposed-updates 220 APT prefers oldstable 190 APT prefers proposed-updates 60 APT prefers dapper-updates 50 APT prefers dapper 30 APT prefers breezy-updates 24 APT prefers edgy-updates 17 APT prefers breezy 16 APT prefers feisty-updates 13 APT prefers edgy 10 APT prefers hoary-updates 10 APT prefers feisty 10 APT prefers breezy-security 7 APT prefers sarge 7 APT prefers etch 7 APT prefers dapper-security (For bonus fun, someone could graph how these change over time..) 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. This assumes that experimental is used by a lot of people, which I doubt, especially given the default apt pins and the numbers above. Experimental is already only rarely uploaded to -- 1 in 20 packages have a version in experimental (some of them outdated). I've seen plenty of cases of developers complaining that they uploaded to experimental and got too little additional testing from doing so. Moving the line between experimental and unstable might drive some people to testing, but I don't feel it will be many, especially as many developers upload even risky changes to unstable already. If you want more users to use testing, see CUT. If you want more developers to use testing, I firstly don't entirely see the point, but providing better tools for developers to develop for unstable while using testing might help. 2) The 'remove testing' proposal Amoung many other problems this postpones most work on the installer until the release it will install is frozen. -- see shy jo [1] [EMAIL PROTECTED]:/org/bugs.debian.org/spool/db-hfind -name \*.log | xargs grep 'APT prefers' | uniq | sed -e 's/.*: *//' -e 's/ *$//' | sort | uniq -c | sort -rn signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
On Mon, Jun 11, 2007 at 06:20:17PM -0300, Gustavo Franco wrote: I would like to ask you interested in our next release to stop and look at 'testing' for a while. I believe that now, during the start of a development cycle and during debcamp/debconf we've a interesting opportunity to review pros and cons of our current approach. We believe that 'testing' means that things shouldn't break as badly as in unstable or experimental. That's important understand the automatic update concept of unstable and the experimental non-automatic nature. In other words use unstable means that upgrade is dangerous, use unstable and experimental means that you pick how much more of the danger you want from there (experimental). Let me outline the 'testing' pros and cons from my point of view: pros - * testing is under control of release team, it's supposed to be harder to a random developer break our next release * testing is our 'daily updated' release snapshot cons - * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. * developers and most active contributors are pretty much using only stable or unstable and not testing. I've two different proposals to address the cons trying to avoid as much as possible create new cons, they are: 1) The 'remove experimental' proposal experimental is not a 'full' branch like stable, testing or unstable. It only has a handfull of package built for it (at least that is what I have seen from reading debian-devel-changes) Also, there is no transition from experimental to unstable. checkout my diagram at http://mysite.verizon.net/kevin.mark/ (there is an older,not updated dia source in spanish if that is helpful) -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgpq8hVMq1eZy.pgp Description: PGP signature
