Re: Why is only the latest unstable package considered for testing?
On Mon, Apr 14, 2003 at 11:39:55PM +0200, Michael Banck wrote: On Mon, Apr 14, 2003 at 10:29:05PM +0200, Sven Luther wrote: Yes, but it is better than having our packages hold back by libvorbis and the 105 or so packages that will be breaken by its inclusion in testing, many of them have big RC bugs and such, and will not be includable in testing for a long time. Could you please back your figures up with hard data? I was looking for libvorbis stuff to NMU and had a time finding some. clanlib-vorbis still needs porting though. I doubt we are talking about '105' packages though. Taken from yesterdays update_output.txt entry at : http://ftp-master.debian.org/testing/update_output.txt skipped: libvorbis (449+583) got: 116+0: a-116 * alpha: adonthell, alsaplayer, alsaplayer-alsa, * alsaplayer-common, alsaplayer-esd, alsaplayer-gtk, * alsaplayer-nas, alsaplayer-oss, alsaplayer-text, amoeba, * artsbuilder, audacity, bitcollider-plugins, black-box, brahms, * bugsquish, bumprace, cantus, castle-combat, chromium, * circuslinux, clanlib-dev, clanlib-vorbis, crimson, * criticalmass, csmash, defendguin, easytag, enigma, fags, * frozen-bubble, gcompris, gemdropx, gjay, gl-117, gltron, * gqmpeg, gtoaster, heroes-sdl, icebreaker, jack, jumpnbump, * kdebase-audiolibs, kdebase-dev, kdemultimedia-dev, kreatecd, * langband-zterm, lbreakout2, lgeneral, libarts-mpeglib, * libopenal-dev, libopenal0, libsdl-mixer1.2, * libsdl-mixer1.2-dev, libsdl-ocaml, libsdl-ocaml-dev, * libsdl-perl, libsdl-ruby, libxine-dev, libxine0, ltris, * madbomber, mirrormagic, moon-lander, mp3blaster, mp3c, * mp3kult, mpeglib, noatun, noatun-plugins, penguin-command, * prboom, pygame, python-pyvorbis, race, ripperx, rockdodger, * rocks-n-diamonds, saytime, simplecdrx, sinek, sox, sox-dev, * sweep, terminatorx, timidity, toppler, tuxpaint, tuxpuck, * tuxracer, tuxtype, vectoroids, vegastrike, vorbis-tools, * vorbisgain, vsound, xine-ui, zinf, zinf-extras, * zinf-plugin-alsa, zinf-plugin-esound Well, there are various libvorbis entries like that, but the smallest one is 105 packages. Note that this is binary packages, not source packages, so sure, it may be less than 105 packages. Notice that this include things like artsbuilder which is part of kdemultimedia, which in turn implies that all of kde 3.1 need to be ready to enter testing. See my other mail for a more detailed list of part of these packages. Some examples are the games packaged by Christian, i didn't look at it in detail, but since these where not rebuilt since last year, chances are good that they still depend (in unstable) on the non-0a libvorbis, and thus need to be rebuilt. Not sure though. And in the end, those packages are *already* included in testing, no? Just a/some version(s) behind. Well, i don't really care about those packages, it is just that this will hold up any packages which depend on libvorbis (post 0a). I could try rebuilding those packages with the testing libvorbis, but i doubt out autobuilders will be happy if i ask them to autobuild on unstable + the testing libvorbis. Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 08:55:19AM +0200, Sven Luther wrote: On Mon, Apr 14, 2003 at 11:39:55PM +0200, Michael Banck wrote: On Mon, Apr 14, 2003 at 10:29:05PM +0200, Sven Luther wrote: Yes, but it is better than having our packages hold back by libvorbis and the 105 or so packages that will be breaken by its inclusion in testing, many of them have big RC bugs and such, and will not be includable in testing for a long time. Could you please back your figures up with hard data? I was looking for libvorbis stuff to NMU and had a time finding some. clanlib-vorbis still needs porting though. I doubt we are talking about '105' packages though. Taken from yesterdays update_output.txt entry at : http://ftp-master.debian.org/testing/update_output.txt skipped: libvorbis (449+583) got: 116+0: a-116 * alpha: adonthell, alsaplayer, alsaplayer-alsa, [...] I was not talking about the packages that are not transitioned into testing because of that. I was asking for a list of packages that *still* need recompile/porting/manual intervention. There's nothing we can do about lagging autobuilders at the moment. Anyway, I think I've seen such list edited by you in another mail. And in the end, those packages are *already* included in testing, no? Just a/some version(s) behind. Well, i don't really care about those packages, it is just that this will hold up any packages which depend on libvorbis (post 0a). I could try rebuilding those packages with the testing libvorbis, but i doubt out autobuilders will be happy if i ask them to autobuild on unstable + the testing libvorbis. Well, they will ignore you. Michael
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 10:39:51AM +0200, Michael Banck wrote: On Tue, Apr 15, 2003 at 08:55:19AM +0200, Sven Luther wrote: On Mon, Apr 14, 2003 at 11:39:55PM +0200, Michael Banck wrote: On Mon, Apr 14, 2003 at 10:29:05PM +0200, Sven Luther wrote: Yes, but it is better than having our packages hold back by libvorbis and the 105 or so packages that will be breaken by its inclusion in testing, many of them have big RC bugs and such, and will not be includable in testing for a long time. Could you please back your figures up with hard data? I was looking for libvorbis stuff to NMU and had a time finding some. clanlib-vorbis still needs porting though. I doubt we are talking about '105' packages though. Taken from yesterdays update_output.txt entry at : http://ftp-master.debian.org/testing/update_output.txt skipped: libvorbis (449+583) got: 116+0: a-116 * alpha: adonthell, alsaplayer, alsaplayer-alsa, [...] I was not talking about the packages that are not transitioned into testing because of that. I was asking for a list of packages that *still* need recompile/porting/manual intervention. There's nothing we can do about lagging autobuilders at the moment. Anyway, I think I've seen such list edited by you in another mail. Yes, but it is only partial, and i got it by starting from this list, looking at each individual package in the PTS, and guessing a bit. I believe that maybe the one which need rebuild are the ones i noted as OK or valid candidates, since many of them where built before the new libvorbis0a package. I am not really sure though, so you would have to check those. And in the end, those packages are *already* included in testing, no? Just a/some version(s) behind. Well, i don't really care about those packages, it is just that this will hold up any packages which depend on libvorbis (post 0a). I could try rebuilding those packages with the testing libvorbis, but i doubt out autobuilders will be happy if i ask them to autobuild on unstable + the testing libvorbis. Well, they will ignore you. As usual ... It could be a nice solution to this kind of solution though. Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 11:10:52AM +0200, Sven Luther wrote: It could be a nice solution to this kind of solution though. Trying to think up solutions for problems that don't exist, eh? Michael, scnr -- calc netscape 6 is only really useful for seeing how browsers used to be broken ;)
Re: Why is only the latest unstable package considered for testing?
Le mar 15/04/2003 à 08:55, Sven Luther a écrit : Well, i don't really care about those packages, it is just that this will hold up any packages which depend on libvorbis (post 0a). I could try rebuilding those packages with the testing libvorbis, but i doubt out autobuilders will be happy if i ask them to autobuild on unstable + the testing libvorbis. That wouldn't bring anything, as the libvorbis in sarge is utterly broken. If you want to help with something, please help in fixing the RC bugs in these packages. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 11:56:22AM +0200, Michael Banck wrote: On Tue, Apr 15, 2003 at 11:10:52AM +0200, Sven Luther wrote: It could be a nice solution to this kind of solution though. Trying to think up solutions for problems that don't exist, eh? So, why is the new libvrobis not in testing ? Sure, saying there is no problem and just ignoring the people that have problems is a way of not being bothered, but it doesn't help for much more than pissing your fellow developers. As said, we hold a mini-freeze for the ocaml packages and co, we worked on this since a few months, and all this for nothing, because of two small binding packages that almost nobody uses are in testing and holding us back because they depend on postgresql and libvorbis, and nobody cares if these packages enter in testing or not. Did you see the postgresql maintainer's call for help ? I notice that nobody even bothered to respond. I would do it, but really know nothing about postgresql, so i don't think i would be of any help. And because of that, i have packages ready that fix a bunch of bugs, but i have not yet uploaded because of this, and i get weekly mail from users asking me why ocaml 3.06 is not yet in testing, while it has been a valid candidate for 3 month or so. Also, i have searched for the reason of this, and with my fellow ocaml maintainers we have come to a conclusion about this, and i asked ftp-master about the removal of two packages from testing, and just got ignored. And you, you tell me i am thinking about problems that don't exist. I can't believe that. Go fix the postgresql bug or some of the libvorbis ones and then speak to me again. Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 12:40:37PM +0200, Josselin Mouette wrote: Le mar 15/04/2003 à 08:55, Sven Luther a écrit : Well, i don't really care about those packages, it is just that this will hold up any packages which depend on libvorbis (post 0a). I could try rebuilding those packages with the testing libvorbis, but i doubt out autobuilders will be happy if i ask them to autobuild on unstable + the testing libvorbis. That wouldn't bring anything, as the libvorbis in sarge is utterly broken. Then remove it and all the dependant packages, and have the new ones enter testing as their dependency are ready. You could have most of the not broken versions of these packages in testing in a day or so if you would go this route. This is not being done, and i can understand this, but nobody is also giving proper argument about why this should not be done. If you want to help with something, please help in fixing the RC bugs in these packages. Yes, sure, easy for you to say. There are so many of them, and on such a diversity of packages, i could be fixing bugs for weeks and not improve the situation. That is if i even had a fiable way of knowing what the concerned packages are. Sure i could fix the testing script to provide more usefull output, but i don't speak python, and i think they don't want it changed anyway. It is not as i am standing idle also, i have other packages i maintain and fix bug for (and respond promptly to bug reports, not let them in the dark for weeks) and i have been X upstream bug fixing lately. And what would be your pronostic for having the new KDE in sarge ? I don't use KDE, i don't do C++ programing mostly, i don't even really believe that OO is the best thing ever and i should go fix KDE bugs just so that the packages i maintain will get in testing ? I think i can use my free time in a more valuable way. Maybe the RM hopes that by not moving on this or anything, he will blackmail people to fix those bugs. But i don't believe it is a good solution, and if the package are buggy and nobody care for them, by all way, please remove them from testing, and let the rest of us who care about our packages continue to work on them. Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 01:07:02PM +0200, Sven Luther wrote: On Tue, Apr 15, 2003 at 11:56:22AM +0200, Michael Banck wrote: On Tue, Apr 15, 2003 at 11:10:52AM +0200, Sven Luther wrote: It could be a nice solution to this kind of solution though. Trying to think up solutions for problems that don't exist, eh? So, why is the new libvrobis not in testing ? Sure, saying there is no problem and just ignoring the people that have problems is a way of not being bothered, but it doesn't help for much more than pissing your fellow developers. sven# modprobe humour I think Michael was poking fun at solution to this kind of solution. :) -- Colin Watson [EMAIL PROTECTED]
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 01:10:39PM +0100, Colin Watson wrote: On Tue, Apr 15, 2003 at 01:07:02PM +0200, Sven Luther wrote: On Tue, Apr 15, 2003 at 11:56:22AM +0200, Michael Banck wrote: On Tue, Apr 15, 2003 at 11:10:52AM +0200, Sven Luther wrote: It could be a nice solution to this kind of solution though. Trying to think up solutions for problems that don't exist, eh? So, why is the new libvrobis not in testing ? Sure, saying there is no problem and just ignoring the people that have problems is a way of not being bothered, but it doesn't help for much more than pissing your fellow developers. sven# modprobe humour Mmm, sorry i misreacted then, Michael, i hope you accept my apology. I think Michael was poking fun at solution to this kind of solution. :) Well, it should have read solution to this kind of problem, naturally. Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 01:30:27PM +0200, Sven Luther wrote: If you want to help with something, please help in fixing the RC bugs in these packages. Yes, sure, easy for you to say. There are so many of them, and on such a diversity of packages, i could be fixing bugs for weeks and not improve the situation. Guess what people are trying to do. It's hunting season guys. It's bug-squashing *year*, OK? We can only release sarge if we start working on RC-bugs *NOW*, like asuffield does. I did a couple of NMUs for RC bugs in the last days - I uploaded straight to DELAYED/7-day, sent a mail with a diff to the BTS and set the bug to +pending. So far, I did not get much complaints. Oh, and #debian-bugs is still there, although it's idle... Michael
Re: Why is only the latest unstable package considered for testing?
Hi, On Tue, 15 Apr 2003 13:54:06 +, Michael Banck wrote: Guess what people are trying to do. It's hunting season guys. It's bug-squashing *year*, OK? We can only release sarge if we start working on RC-bugs *NOW*, like asuffield does. Oh, I don't know, we could start by re-classifying them as wishlist. [ducksruns] I did a couple of NMUs for RC bugs in the last days - I uploaded straight to DELAYED/7-day, sent a mail with a diff to the BTS and set the bug to +pending. So far, I did not get much complaints. Hmm. If I wanted to do something like that (not too sure yet) I'd have to go through a sponsor. That doesn't sound like a net reduction of work... -- Matthias
Re: Why is only the latest unstable package considered for testing?
On Tue, Apr 15, 2003 at 03:54:06PM +0200, Michael Banck wrote: On Tue, Apr 15, 2003 at 01:30:27PM +0200, Sven Luther wrote: Yes, sure, easy for you to say. There are so many of them, and on such a diversity of packages, i could be fixing bugs for weeks and not improve the situation. Guess what people are trying to do. It's hunting season guys. It's bug-squashing *year*, OK? Amen. -- Colin Watson [EMAIL PROTECTED]
Re: Why is only the latest unstable package considered for testing?
Matthias Urlichs [EMAIL PROTECTED] writes: On Tue, 15 Apr 2003 13:54:06 +, Michael Banck wrote: I did a couple of NMUs for RC bugs in the last days - I uploaded straight to DELAYED/7-day, sent a mail with a diff to the BTS and set the bug to +pending. So far, I did not get much complaints. Hmm. If I wanted to do something like that (not too sure yet) I'd have to go through a sponsor. That doesn't sound like a net reduction of work... No, you do not need to go through a sponsor to send a mail with a diff to the BTS. Suonpää...
Re: Why is only the latest unstable package considered for testing?
Hi, On Tue, 15 Apr 2003 17:36:56 +, Samuli Suonpaa wrote: Matthias Urlichs [EMAIL PROTECTED] writes: [ straight to DELAYED/7-day ] Hmm. If I wanted to do something like that (not too sure yet) I'd have to go through a sponsor. That doesn't sound like a net reduction of work... No, you do not need to go through a sponsor to send a mail with a diff to the BTS. *Sigh* My something like that phrase specifically referred to uploading to DELAYED. snarkySorry if that was too difficult to understand./snarky Anyway, I've earmarked the next two nights as find-a-few-RC-bugs-to-fix nights, if only to show people that I'm not just talking. ;-) -- Matthias
Re: Why is only the latest unstable package considered for testing?
Bob Proulx wrote: Just minor searching through the archive turned these up with relevent discussion. These posts, as your reply in debian-testing, concern packages that are not Valid Candidates. My question concerns perfectly working packages that are suitable for testing, yet are never considered. I did search the archives, but failed to find a post addressing this issue. -- Björn
Re: Why is only the latest unstable package considered for testing?
On Mon, Apr 14, 2003 at 09:43:28AM +0200, Björn Stenberg wrote: Bob Proulx wrote: Just minor searching through the archive turned these up with relevent discussion. These posts, as your reply in debian-testing, concern packages that are not Valid Candidates. My question concerns perfectly working packages that are suitable for testing, yet are never considered. I did search the archives, but failed to find a post addressing this issue. The reason you are seing this, is that the update_excuse file information is not enough to know why a package is not in testing, you can find more information in the update_output.txt file or the testing FAQ, but basically, for a package to be considered ready to enter testing, it needs to be a valid candidate and its inclusion in testing need not to break any other package in testing, which is why most valide candidates are not yet in testing. Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
Bjorn Stenberg wrote: Bob Proulx wrote: Just minor searching through the archive turned these up with relevent discussion. These posts, as your reply in debian-testing, concern packages that are not Valid Candidates. But they did concern how testing operates. Insight into the design of the pipeline of unstable, testing and stable. There has been a lot of discussion in general about how to improve testing to get to a release faster. Isn't that what you are trying to do here too? Improve testing so that we can generate high quality releases more quickly? My question concerns perfectly working packages that are suitable for testing, yet are never considered. Okay, let me give it another try. I have been looking at the excuses page[0] and was struck by how very old some packages are in testing, yet only the very latest bleeding edge version from unstable appears to be considered for inclusion. The version in unstable is not _supposed_ to be bleeding. It frequently is but it is not designed to be bleeding. Packages there are supposed to be staging for testing which is staging for release. If a maintainer thinks it is bleeding then it should not even go in unstable. However since sometimes you can't tell if the package has a problem until it meets the world and you have to start somewhere then unstable is the best place to start. Am I misunderstanding something, or does this approach punish projects that adhere to the Open Source motto to release often? Often is a good thing for research and development but bad for integration and testing. Therefore at least some amount of stability must be had in order to ensure it has made it through minimal testing. The 10 days to wait in unstable is very much less than often and still provides much opportunity for rapid updates. A project that released monthly, for example, should have no trouble at all with the 10 day cooking period in unstable. That would still be considered to be updated often. You are not punished unless your release cycle is less than the waiting period. And it is not really punishment. Just an impedance mismatch. The reason there is a waiting period is to give the package some exposure. Other packages will build against it. People will get a chance to try it out. How much time is enough to ensure adequate testing? If it is a very popular package then a couple of days is enough. But if it is obscure then perhaps even several months is really not enough. But surely some non-zero amount of exposure time is always required. If you are releasing really often, say the daily cvs snapshot build, then those are probably not suitable for zillions of people to be installing daily. Small ripples in the upstream current can create huge waves crashing against the far shore accompanied by inland flooding. That type of release is really more suitable for people who have adopted the package as one that they care about and are willing to find and fix bugs in. I will claim right here and now that there are different types of releases and while the daily build is a very useful one it is a different type and for a different purpose than a full distribution release. And of course there is a whole range of sizes in between. You have to know your target audience and match things appropriately. Hypothetical example: Project X makes an effort to prepare a solid release, squashing all RC bugs and making sure each target builds flawlessly. They pack it up, label it 3.0 or whatever and release it. The package goes into unstable and, being a non-critical update, needs 10 days to become a Valid Candidate[1] for testing. For a while, people have been working on a big patch to move project X from gnome to gnome2. This was submitted to the project but was delayed until after 3.0. Now that 3.0 is out the door and the users have a stable version to work with, the gnome2 patch goes in and a new version, 3.1, is released only a few days later. This version is not a valid testing candidate, since gnome2 is not yet included in testing, but it's a welcome update for those running gnome2/unstable. Now the catch: Since the testing scripts only consider the latest unstable version, the testing-ready 3.0 version is never considered. Instead, the 3.1 version is rejected (due to depending on gnome2) and the old 2.0 version is kept. The DD who updated the 3.0 version into unstable should work to make sure it enters testing. Until it does they should not upload a less stable version. They should drive the process and not let the process drive them. Since they spent a significant amount of time in the first paragraph preparing the package and squashing all bugs and getting it to build on all platforms they should not throw that work away and overwrite it with a less well tested or possibly more buggy version or they will have to start the process again. Just because upstream released another package does not mean that
Re: Why is only the latest unstable package considered for testing?
On Mon, Apr 14, 2003 at 03:14:21AM -0600, Bob Proulx wrote: The DD who updated the 3.0 version into unstable should work to make sure it enters testing. Until it does they should not upload a less stable version. They should drive the process and not let the process drive them. but often it is out of hiw hand. BTW, do you know if uploading a package to testing-update will be considered by the testing scripts if the unstable version is a new version and/or too buggy and such ? This would be a neat way to rebuilding a testing package which is holding back huge amount of other packages and just needs a rebuild, but the unstable version is not considered for this, since it depends on a huge amount of other (broken) packages. Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
On Mon, Apr 14, 2003 at 01:44:40PM -0600, Bob Proulx wrote: Sven Luther wrote: BTW, do you know if uploading a package to testing-update will be considered by the testing scripts if the unstable version is a new version and/or too buggy and such ? This would be a neat way to rebuilding a testing package which is holding back huge amount of other packages and just needs a rebuild, but the unstable version is not considered for this, since it depends on a huge amount of other (broken) packages. To the best of my knowledge there are no autobuilders for testing. The autobuilders use unstable. Therefore in order to accomplish what you suggest one would need to manually build on all of the Debian supported architectures using testing or stable and then upload the binary builds for all architectures. And there may be other gotchas too. Yes, but it is better than having our packages hold back by libvorbis and the 105 or so packages that will be breaken by its inclusion in testing, many of them have big RC bugs and such, and will not be includable in testing for a long time. I feel a bit discouraged by this, we have held a mini-freeze of the ocaml packages since december and more seriously since the new libc6 entered testing, and all this for nothing. And any further work on these packages is blocked until we either abandon this mini-freeze. I believe, but i have really no way to be sure, that the removal of two packages from testing will allow 40 or so other packages from sid to enter testing, and we, the ocaml debian packagers, have decided that this was the best course of action, both for us and for our users (which mostly use Stefano's woody backport anyway, and often complain about the situation). But i didn't even get a reply to the already 2 weeks old bug for the removal of those packages. How well, there is always other things to work on, ... (going back to see of i could best go about to transform the X cvs bi-monthly snapshots into debian packages). Friendly, Sven Luther
Re: Why is only the latest unstable package considered for testing?
On Mon, Apr 14, 2003 at 10:29:05PM +0200, Sven Luther wrote: Yes, but it is better than having our packages hold back by libvorbis and the 105 or so packages that will be breaken by its inclusion in testing, many of them have big RC bugs and such, and will not be includable in testing for a long time. Could you please back your figures up with hard data? I was looking for libvorbis stuff to NMU and had a time finding some. clanlib-vorbis still needs porting though. I doubt we are talking about '105' packages though. And in the end, those packages are *already* included in testing, no? Just a/some version(s) behind. cheers, Michael
Re: Why is only the latest unstable package considered for testing?
Bj?rn Stenberg wrote: (I first submitted this question to debian-testing, but was referred here for discussion.) [If you would be so kind as to word wrap your messages before you send them it would make reading and replying to them much easier.] Well, actually I was hoping you would search the debian-devel archives first and then bring up _new_ points as you saw fit. I did not expect you to post your original question again verbatim. You did have at least two answers to your original question already. Why is only the latest unstable package considered for testing? http://lists.debian.org/debian-testing/2003/debian-testing-200304/msg00028.html Since I helped stir the pot I will at least do some homework. Just minor searching through the archive turned these up with relevent discussion. These are all in the very recent history and not even back very far. I am sure I could find some choice gems if I looked into prior years. Before anyone posts a follow up at the very least the following threads of discussion on this list should be mandatory reading. Subject: why is it not moving to testing http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg01277.html Subject: Some myths regarding apt pinning http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg01644.html Subject: Freeze Please? http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00317.html Subject: testing, unstable, and dependencies http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00302.html Bob pgpvrjx8vcuwF.pgp Description: PGP signature
