Hi, Neil Williams <codeh...@debian.org> writes: > Ted Dunning <ted.dunn...@gmail.com> wrote: >> In any case, it is a bit strong language to blame code quality for a >> build system configuration error. > > Quality code should detect that the build configuration is wrong > before the build itself actually fails. If the code requires a version > higher than one which is likely to already exist, quality code would > check that the old version is handled with a useful message. It > shouldn't require detailed knowledge of that package.
And to check against too new versions as well. And not suddenly fail to build when the compiler becomes a bit stricter. Which leaves us with not too much quality code in Debian ;) >> Also, nobody seems to have contacted the actual project maintainers >> about this problem. Your comments about lack of motivation are also >> somewhat ad hominem (and incorrect). > > It's simply that if the bug isn't fixed, the package will be removed. > I've said before, I don't care about the detail of this package. It's > up to those who do care to see about getting upstream involved, > whether that's the current maintainer or someone else if he doesn't > respond. > >> > Irrespective of disagreements with the current maintainer, zookeeper is >> > not good enough for Debian stable simply because it has a separate >> > release-critical bug. #626020 - FTBFS on mips. There is no argument >> > about this - failing to build from source on a supported architecture >> > means, by definition, that the software is not of sufficient quality for >> > Debian. End of. >> > >> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626020 > > That summary is still accurate. No. The package could as well just drop support for architectures that do not have Java 1.6 (mips switched from openjdk-6 back to gcj according to default-jdk-common's changelog). kfreebsd-* also only has Java 1.5. >> > As such, I would disagree strongly with the statement that ZK is not >> > of sufficient quality to be included in Debian. >> >> > The RC bug argues differently and, in Debian, the RC bug is always more >> > persuasive than protests from interested parties who lack the time or >> > motivation to actually fix the problem. > > This is a general point about other arguments where "interested > parties" are vocal but not able to actually change the issue itself. > Someone needs to actually fix the package, not just complain at those > who simply state the reality of how an RC bug will be handled if not > fixed. If no-one steps up, for reasons of motivation or whatever else, > then the package will be removed. It's quite simple really, the > package isn't good enough to be in Debian if this bug is left unfixed. > Someone fixes it, I'll be happy. Until then, protests without action > will make absolutely no difference. The "interested party" might also not know how packages are maintained in Debian. And I don't think it is helpful to "threaten" upstream with removal of his software from Debian, certainly not in the first answer. Please be a bit less aggressive. But you are right that there are already too many packages in unstable that could not migrate to testing for ages as they have RC bugs open[1] and nobody seems to care... Regards, Ansgar [1] <http://release.debian.org/migration/oldest.html> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h8q4xw3....@marvin.43-1.org
