2009/11/12 Branko Čibej <brane_at_xbc.nu>:
> Mike Samuel wrote:
>> And I would prefer to avoid adding a new property like svn:text just
>> to work around tricky but ultimately fixable UTF-16/32 issues.
> The key phrase you're missing is "maintainable for the long term," see
> my other post. Remember that this project is mostly run by volunteers;
> any solution to tricky issues must be such that expected maintenance
> costs vs. perceived gains are low enough that it stays maintained even
> if the original implementer goes away. There's nothing inherently wrong
> with your proposal, but its implementation would have to take that into
> account; and that's also an incentive to keep things simple.
I absolutely agree with everything you said, except your implication
that a new property is inherently simpler than fixing a bug in the
interpretation of an existing one.
>> What are next steps? Do we put things to a vote, duel, appeal to a
>> higher power?
> We keep discussing and addressing each others' concernes, until we reach
> some kind of agreement. The "higher power" you refer to is the project's
> developers, i.e., a vote; but the choices have to be a lot more
> clear-cut before that makes sense. We don't usually vote on abstract
> design concepts, and certainly not after only a few hours of discussion.
> You could /also/ try the proof-by-code method; provide a patch for
> review, or ask for a branch to implement your proposal on. It makes
> sense to convince others that your design is practical first, though;
> otherwise you could end up writing a lot of code that never gets
> integrated into the mainline.
That's exactly what I'm trying to do :) Instead of dumping a patch on
the list and pressuring people to accept my design because otherwise
my coding would be wasted, I'm trying to be a good citizen and hash
out the disagreements first. But I am leery of scope-creep -- I don't
want fixing a bug to turn into a discussion about a new context
sensitive merging system.
> -- Brane
Received on 2009-11-13 03:43:39 CET