[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

confusion



I'm confused, because in part I don't seem to get responses when I ask
questions.  I think this is because the people who could respond think
they have already answered, even though they really haven't.

So guile-1.8 does not have to build from source on 64 bit archs, because
one only has to do best effort, apparently, according to the BTS log.

But, lilypond must build from source on 64 bit archs, because it's RC.

I still haven't gotten a reply from my request to hint lilypond 2.8 into
testing, or any explanation of exactly what the deal is.  It sounded
last time I heard like there was a rule, which was being applied whether
it made sense or not, because "that's the rule".  Can we put aside the
rule, and think about the actual situation for a moment?

I have requested lilypond 2.8 to be hinted into testing, and received
neither a "yes" or a "no" in response to that request.  The only
previous mail I received from Steve was under the mistaken thought that
the failing guile-1.8 archs were unreleased archs, but this isn't true
as it turns out.

Why is it OK for guile-1.8 to support 32-bit archs and not 64-bit archs,
but lilypond is required to support all of them?  It would be better to
have a halfway modern lilypond on 32-bit archs and nothing at all on
64-bit archs, than to have a medieval lilypond on all of them.

Moreover, the stable update policy allows adding new archs for packages
that were not originally in the release for all of them, so if
lilypond-2.8 is hinted into testing, with the 64-bit archs holding an
old version or no version, this situation can be repaired through the
normal stable update process.

By contrast, if lilypond-2.8 is not allowed into the release, and we are
forced to put up with 2.6 for another release cycle, the stable release
policy does not permit the situation to be repaired.

Given that we may NECESSARILY do something broken, why not do the broken
thing that is the best for the most people, and also repairable?

Thomas

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: