Re: more about Zookeeper
Neil Williams <email@example.com> writes:
> Ted Dunning <firstname.lastname@example.org> 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
>> > 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
and nobody seems to care...