First pass all buildds before entering unstable
Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. I guess this would be not really hard to implement. Just ignore me if this is a stupid idea Andreas.
Re: First pass all buildds before entering unstable
Am 19.11.03 um 07:42:18 schrieb Andreas Tille: After each buildd was able to build a package the whole set with all architectures enters unstable at once. Yeah, cool. That would get rid of many buggy packages. And many clean ones. Some buildd are horribly behind time. No offence meant, it's not necessarily sloppy maintainers, rather it's slow computers and extremely complex packages. Take workrave, for instance. Perfectly stable, as far as I can tell. Not built recently on m68k (because of libgnomeuimm2.0-dev), not built on alpha for a very long time (same reason). It's not in testing, which is bad enough, with your idea only ancient versions would be in unstable. Don't get me wrong. I actually quite like the thought. It just won't work. Perhaps limit it to when it's built for i386, powerpc, hppa and arm. (That's were I got all my architecture-dependent bugs from, and they are all quite current.) Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 08:48:10AM +0100, Michael Piefel wrote: Am 19.11.03 um 07:42:18 schrieb Andreas Tille: After each buildd was able to build a package the whole set with all architectures enters unstable at once. I like the idea. Yeah, cool. That would get rid of many buggy packages. And many clean ones. Some buildd are horribly behind time. No offence meant, it's not necessarily sloppy maintainers, rather it's slow computers and extremely complex packages. I don't think the speed of some of our buildd would be the point. Sooner or later the new packages will be compiled on our buildd: better before entering Debian than after and.. Take workrave, for instance. Perfectly stable, as far as I can tell. Not built recently on m68k (because of libgnomeuimm2.0-dev), not built on alpha for a very long time (same reason). It's not in testing, which is bad enough, with your idea only ancient versions would be in unstable. I think this is not what Andreas ment: I suppose he was trying to drop FTBFS bugs for those new packages missing correct Build-* fields. Packages that cannot be built because of correct source fields but missing dependencies, should not receive bugs (AFAICT) Don't get me wrong. I actually quite like the thought. It just won't work. Perhaps limit it to when it's built for i386, powerpc, hppa and arm. (That's were I got all my architecture-dependent bugs from, and they are all quite current.) IMHO it would indeed work, if only we consider meaningful buildd reports (for what is our purpose). ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: First pass all buildds before entering unstable
In article [EMAIL PROTECTED] you wrote: Take workrave, for instance. Perfectly stable, as far as I can tell. Not built recently on m68k (because of libgnomeuimm2.0-dev), not built on alpha for a very long time (same reason). It's not in testing, which is bad enough, with your idea only ancient versions would be in unstable. http://m68k.bluespice.org/cgi/package_status?m68k_pkg=libgnomeuimm2.0-devsearchtype=go - libgnomeuimm2.0-dev not registered http://m68k.bluespice.org/cgi/package_status?m68k_pkg=libgnomeuimm2.0searchtype=go - libs/libgnomeuimm2.0_2.0.0-4: Installed by younie-crest [optional:out-of-date] Previous state was Uploaded until 2003 Nov 18 11:28:19 http://m68k.bluespice.org/cgi/package_status?m68k_pkg=workravesearchtype=go - gnome/workrave_1.4.1-1: Failed by schmitz-q650 [optional:out-of-date] Reasons for failing: [Category: none] uninstallable b-d E: Couldn't find package libgnomeuimm2.0-dev Previous state was Building until 2003 Nov 07 02:46:31 Maybe you want to request a rebuild on [EMAIL PROTECTED] -- Ciao... // Ingo \X/
Re: First pass all buildds before entering unstable
Andreas Tille wrote: Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. No!!! it would delay to much the entry of some important packages in unstable. It would maybe improve some architectures, but definitely would reduce extensive testing of newer versions. Unstable IMHO should be more near to upstream-side as possible, to improve GNU/Linux at whole, not only the Debian distributions. BTW: How many developers have access and know how to test packages in *all* other architectures? So it would be more pressure on developers with architectures specific knowelenge. ciao giacomo
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote: Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. People are bickering enough as it is when packages don't move into testing that we don't need this extra reason for them to bicker :-) This would get us rid of all those packages in unstable with Does not build on ... Unstable is there for that kind of things. And to detect other kinds of bugs, too. If you're going to keep packages in incoming like this, people won't be able to test it until it's built on all architectures. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 09:44:31AM +0100, Giacomo A. Catenazzi wrote: No!!! it would delay to much the entry of some important packages in unstable. It would maybe improve some architectures, but definitely would reduce extensive testing of newer versions. In which way would it improve some architectures and not the overall Debian quality? why would it reduce extensive testing of newer versions? Rejecting a package which is not buildable on a spacific architecture, because of an unpstream or maintainer fault, is a semi-automatic testing that can be implemented. If we let it in and then we auto-build it, we get a new package with FTBFS (i.e RC) bugs and slow down release even more. If we auto-build it first and, if no upstream/package faults, we let it in, we get less RC bugs. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote: I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. Neither i. This is why i would like to receive baklogs mailed to maintainer if autobuild fails. But i would like to receive backlogs even for pre-autobuilds, so that i could fix the problem, contact the upstream etc. BTW, i think that the correct workflow would be: Move package from incoming to autobuild. If all architectures build, continue (as before this change); else, if not builded but is not upstrea/maintainer fault, continue (as before this change). Else reject the package. Unstable is there for that kind of things. And to detect other kinds of bugs, too. If you're going to keep packages in incoming like this, people won't be able to test it until it's built on all architectures. If we stay as it is, we'll continue to get slowed by badly built packages/softwares. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgpykhdfZUnbE.pgp Description: PGP signature
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Luca - De Whiskey's - De Vitis wrote: If we let it in and then we auto-build it, we get a new package with FTBFS (i.e RC) bugs and slow down release even more. If we auto-build it first and, if no upstream/package faults, we let it in, we get less RC bugs. Exactly this was the idea. I'm unsure whether experimental could serve as this kind of staging area. Kind regards Andreas.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. I cannot see any real advantage for that, but for avoiding a FTBFS reports proliferation. Also a. Packages could become FTBFS later, when their dependency pkgs change. b. They are already kept off testing (if there is a regression), so what's the problem? c. Very few packages are seriuosly broken on some archs. Their problems are generally due either to compiler/binutils problems or upstream coding. In both cases removing them on some archs could be a profitable solution for releasing. -- Francesco P. Lovergine
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Francesco P. Lovergine wrote: b. They are already kept off testing (if there is a regression), so what's the problem? The problem is that other packages which might depend from a package which is broken on one architecture will not move into testing. If you would keep those packages out of unstable you can be sure that you build your own package based on packages which have all the same version in unstable. This is the relevant bit of the suggestion. See the lot of packages which can not enter testing because a dependency is not fulfilled on a certain architecture. Kind regards Andreas.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:10:14AM +0100, Andreas Tille wrote: On Wed, 19 Nov 2003, Luca - De Whiskey's - De Vitis wrote: If we let it in and then we auto-build it, we get a new package with FTBFS (i.e RC) bugs and slow down release even more. If we auto-build it first and, if no upstream/package faults, we let it in, we get less RC bugs. Exactly this was the idea. I'm unsure whether experimental could serve as this kind of staging area. A FTBFS for a new package is not a RC error. Only regressions are RC. -- Francesco P. Lovergine
Re: First pass all buildds before entering unstable
Luca - De Whiskey's - De Vitis wrote: (...) Why developers should care more about packages not entering into unstable that packages not entering into testing? I worry about indirect delays. Scenario: developer A@ do good job with packages A, but A requires packages B. What should A do? Waiting and not lose the motivation? Help B@, maybe with a NMU, but still waiting the canonical time for NMU (on normal time)? Do A@ have knows enought about B to help? (Maybe B is in a other language, for glibc, XFree86,.. specific architectures knowelenge are maybe required,... If you want to implement such pre-autobuild I would like to see: - relaxed NMU time - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. - .. ciao giacomo
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:10:14AM +0100, Andreas Tille wrote: Exactly this was the idea. I'm unsure whether experimental could serve as this kind of staging area. I would keep experimental only for experiments (:P), while i see your proposal as a new step to be included in our packages workflow; thus i would use unstable. Moreover, experimental is not autobuilded because of high chances of broken packages in it. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote: I worry about indirect delays. Scenario: developer A@ do good job with packages A, but A requires packages B. What should A do? Waiting and not lose the motivation? Help B@, maybe with a NMU, but still waiting the canonical time for NMU (on normal time)? Do A@ have knows enought about B to help? (Maybe B is in a other language, for glibc, XFree86,.. specific architectures knowelenge are maybe required,... IMHO, We should not warry about indirect delay/problems. It's not A's fault, thus A should be warranted to be released (in a way or in another): A not being in testing because of B is part of the game. The problem which must be handled is B, and who or how to handle it is too case specific to be considered here. We have 'help' tag on BTS and specific mailing lists to ask for help on specific topic. BTW, when i did NMU i based the delay either on the best practice and on the need of the fix. I thought it to be reasonable. - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. I do not understand this: what do you mean? ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: First pass all buildds before entering unstable
Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] wrote: On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote: I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. Neither i. This is why i would like to receive baklogs mailed to maintainer if autobuild fails. But i would like to receive backlogs even for pre-autobuilds, so that i could fix the problem, contact the upstream etc. [...] backlog: Package is stuck in queue of autobuilder, no build failure. e.g. linuxtv-dvb_1.0.1-6 was uploaded on Oct 31 and Mips still has not _tried_ not build it. cu andreas
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Giacomo A. Catenazzi wrote: I worry about indirect delays. Scenario: developer A@ do good job with packages A, but A requires packages B. What should A do? Waiting and not lose the motivation? But the problem can be the other way around: A builds his package against package of B which has no chance to enter testing. This is frustrating. Or even A builds his package against a version of package B which is fine but will be overriden by a new version of B which has an FTBFS bug before the old version of package B had a chance to enter testing. Help B@, maybe with a NMU, but still waiting the canonical time for NMU (on normal time)? Perhaps. Or rather B might be try harder to get his package into unstable. If you want to implement such pre-autobuild I would like to see: - relaxed NMU time - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. - .. Hmmm, why not, but this is not necessaryly connected to my suggestion. Kind regards Andreas. -- Sie schaffen eine Wüste und nennen es Frieden. -- Publius Cornelius Tacitus (55-120)
Re: First pass all buildds before entering unstable
Andreas Tille [EMAIL PROTECTED] writes: Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. I guess this would be not really hard to implement. Just ignore me if this is a stupid idea You are ignoring all the packages that don't build and never have been build for some architecture. Mainly that happens if some build-depends, like the compiler needed, wasn't yet ported. All the packages that are excluded from an arch indirectly because some other package is not for that arch would need to be changed to specifically exclude that arch. And once the actualy faulty package gets ported the change has to be reversed. There is a reason testing script only require archs that did previously build. MfG Goswin
Re: First pass all buildds before entering unstable
Luca - De Whiskey's - De Vitis wrote: On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote: - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. I do not understand this: what do you mean? I don't like automatic system without possibility to have human overide. I want to be able to upload packages in unstable also if there are errors on some architectures, but only on very EXCEPTIONAL cases. OT: In testing happens that a packages will not uploaded in testing because package is buggier, but often the it is buggier because it is in unstable for a long time. You could not tell (AFAIK) that a bug was also present in the old testing version, but passed unnoticed. For this reason, I would like that smarted people (vs stupid script [Stupid from KISS definition]) can eventualy overide/upload packages in unstable. Surelly we need a strict policy about when and how it is allowed. ciao giacomo
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote: just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. This seems like a solution in search of a problem. What problem are you actually trying to solve? Start by describing it, then we can try dreaming up ways to solve it. [Given your vague description of what this would accomplish, I have a few guesses about what you might be trying to do, and I think there are probably less intrusive and more effective approaches]. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Goswin von Brederlow wrote: You are ignoring all the packages that don't build and never have been build for some architecture. Mainly that happens if some build-depends, like the compiler needed, wasn't yet ported. But this is no FTBFS bug than. I just want to keep packages which will have FTBFS bugs which can be automatically detected out of the door. Currently we have more than 100 FTBFS bugs. It is hard to say which of them could be detected at upload time. But if there is an automatic method to sort out packages even before they enter unstable we should do so to stop their influence to other dependant packages. There is a reason testing script only require archs that did previously build. Well, but this is done automatically. I do not want to change anything here. Kind regards Andreas. -- Sie schaffen eine Wüste und nennen es Frieden. -- Publius Cornelius Tacitus (55-120)
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Andrew Suffield wrote: This seems like a solution in search of a problem. What problem are you actually trying to solve? Start by describing it, then we can try dreaming up ways to solve it. [Given your vague description of what this would accomplish, I have a few guesses about what you might be trying to do, and I think there are probably less intrusive and more effective approaches]. Sorry if my English is not as brilliant to explain the problem clearly to everybody. So I try a simple example: http://qa.debian.org/developer.php?excuse=postgresql If there would be a recent perl for each architecture postgresql would have entered testing. I guess there was a working perl before there was trouble with MIPS buildd which wuold have enabled postgresql to enter testing. Feel free to search for other examples whose show stoppers are FTBFS bugs. Kind regards Andreas. -- Sie schaffen eine Wüste und nennen es Frieden. -- Publius Cornelius Tacitus (55-120)
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 03:12:42PM +0100, Andreas Tille wrote: On Wed, 19 Nov 2003, Andrew Suffield wrote: This seems like a solution in search of a problem. What problem are you actually trying to solve? Start by describing it, then we can try dreaming up ways to solve it. [Given your vague description of what this would accomplish, I have a few guesses about what you might be trying to do, and I think there are probably less intrusive and more effective approaches]. Sorry if my English is not as brilliant to explain the problem clearly to everybody. So I try a simple example: http://qa.debian.org/developer.php?excuse=postgresql If there would be a recent perl for each architecture postgresql would have entered testing. I guess there was a working perl before there was trouble with MIPS buildd which wuold have enabled postgresql to enter testing. And if we hadn't had perl 5.8.1 in unstable, then we would never have spotted its binary incompatibility with 5.8.0. Upstream released 5.8.2 precisely because the problem had been discovered in Debian unstable. Under your proposal, we would have remained unaware of the problem for much longer, which would have been a bad thing. This is in fact an excellent example of how fixing build problems isn't enough to ensure a quality distribution, and how it's often important to parallelize fixing build problems and other problems rather than serializing the two tasks. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: First pass all buildds before entering unstable
Andreas Tille [EMAIL PROTECTED] writes: On Wed, 19 Nov 2003, Goswin von Brederlow wrote: You are ignoring all the packages that don't build and never have been build for some architecture. Mainly that happens if some build-depends, like the compiler needed, wasn't yet ported. It gets fetches, unpaked and then checkbuilddepends find problems. and puts it in Dep_wait. But this is no FTBFS bug than. I just want to keep packages which will have FTBFS bugs which can be automatically detected out of the door. Currently we have more than 100 FTBFS bugs. It is hard to say which of them could be detected at upload time. But if there is an automatic method to sort out packages even before they enter unstable we should do so to stop their influence to other dependant packages. There is a reason testing script only require archs that did previously build. Well, but this is done automatically. I do not want to change anything here. You can only detect if the package is uploaded. Anything else would need intelligend parsing of buildd logs. Checking only archs with previously build depends screens out any of the above cases, you should do the same in yor proposal. MfG Goswin
Re: First pass all buildds before entering unstable
Giacomo A. Catenazzi [EMAIL PROTECTED] writes: Luca - De Whiskey's - De Vitis wrote: On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote: - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. I do not understand this: what do you mean? I don't like automatic system without possibility to have human overide. I want to be able to upload packages in unstable also if there are errors on some architectures, but only on very EXCEPTIONAL cases. OT: In testing happens that a packages will not uploaded in testing because package is buggier, but often the it is buggier because it is in unstable for a long time. You could not tell (AFAIK) that a bug was also present in the old testing version, but passed unnoticed. Test it and tag the bug sarge. MfG Goswin
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Andreas Tille wrote: just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. I guess this would be not really hard to implement. You just described one of the many features of testing.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 03:43:31AM -0600, Luca - De Whiskey's - De Vitis wrote: On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote: I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. Neither i. This is why i would like to receive baklogs mailed to maintainer if autobuild fails. But i would like to receive backlogs even for pre-autobuilds, so that i could fix the problem, contact the upstream etc. Uh, I think we're not speaking the same English here. When I say this architecture has a backlog, I mean this architecture can't keep up with building. You can get the logs, they're at http://buildd.debian.org/ -- mails to package maintainers are superfluous; non-buildd people shouldn't be bothered with such stuff, as it isn't their problem in 99% of the cases. BTW, i think that the correct workflow would be: Move package from incoming to autobuild. If all architectures build, continue (as before this change); else, if not builded but is not upstrea/maintainer fault, continue (as before this change). Else reject the package. Unstable is there for that kind of things. And to detect other kinds of bugs, too. If you're going to keep packages in incoming like this, people won't be able to test it until it's built on all architectures. If we stay as it is, we'll continue to get slowed by badly built packages/softwares. So we slow the system down even more by holding packages for no real reason? I fail to see how that would help. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 03:12:42PM +0100, Andreas Tille wrote: On Wed, 19 Nov 2003, Andrew Suffield wrote: This seems like a solution in search of a problem. What problem are you actually trying to solve? Start by describing it, then we can try dreaming up ways to solve it. [Given your vague description of what this would accomplish, I have a few guesses about what you might be trying to do, and I think there are probably less intrusive and more effective approaches]. Sorry if my English is not as brilliant to explain the problem clearly to everybody. So I try a simple example: http://qa.debian.org/developer.php?excuse=postgresql If there would be a recent perl for each architecture postgresql would have entered testing. I guess there was a working perl before there was trouble with MIPS buildd which wuold have enabled postgresql to enter testing. So your proposal is merely that we ignore non-FTBFS bugs until all the FTBFS bugs have been fixed? That doesn't sounds like a good idea to me. Certainly it won't speed up the process of fixing all the bugs. I suspect that you have fallen into the trap of seeing testing as an end in itself. It isn't; the objective is stable. Once we're in a fit state for that, testing will sort itself out. It doesn't really matter whether postgresql goes into testing today or in three months, it just has to do so before the next stable release. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
