Tags:
create new tag
, view all tags

Do we have to live with certain bugs and misfeatures forever?

In KeywordSearch, RafaelAlvarez comments:

BTW, the same argument in favour of not fixing keyword can be used against changing ANY part of the Core because some of the 100s plugins out there that work around the Func API (so working against the spec) won't break. And I mean both changes in behavior and structure.

This raises a fundamental philosophical point about future versions of TWiki. No one wants to break existing installations and plugins unnecessarily. But if there is a serious bug or misfeature in Cairo (and Dakar?) like KeywordSearch, we are between a rock and a hard place. We fix it and quite possibly break some existing sites. We don't fix it and things remain broken. And there's a similar problem if previous design decisions "break" installations in more subtle ways, like causing them to run slower and slower as the number of topics grow.

Personally, I don't believe in retaining bugs and misfeatures for "compatibility reasons". So how do we resolve this dilemma?

-- Contributors: RafaelAlvarez, MeredithLesly

Discussion

Yet another topic with a scope so broad that is can only lead to discussion and no decision.

The world is not black and white. There are not only good guys and bad guys except in Hollywood movies.

When to break compatibility and when not to do it needs to be discussed in each and every case.

-- KennethLavrsen - 23 May 2006

The scope is broad because this is a fundamental question. We need to decide which path are we going to follow:

  • If some change goes "by the spec" as documented, then it doesn't matter if it worked differently before and is considered a "fix"
OR
  • If some change goes "by the spec" but behaved diferently in the previous TWiki version, it can't be commited unless there is a consensus about it.

The later means that Dakar needs to remain bug-compatible with Cairo, and that Edin* needs to remain bug-compatible with Dakar.

And the big point is what I wrote in KeywordSearch: The same arguments used for the keyword option in SEARCH can be used against every change of semantic and structure from Cairo and Dakar, and would be very inconsistent (ie, losing any kind of validity) is approved for some and rejected for some.

Perhaps this is all academic, but it is a fundamental problem.

-- RafaelAlvarez - 23 May 2006

Yes. It is a fundamental philosophical question that can help guide what developers are willing to commit their time to. And it is a question that does in fact allow a philosphical decision.

If the decision is made that it is unacceptable to change behaviour that goes against spec but also runs a serious risk of breaking an unknown number of installations, that needs to be stated explicitly and the behaviour, even if against the spec, is not to be changed. The alternative decision is that if behaviour is different than what is in official documentation, that misbehaviour is a bug that should be fixed unless there is agreement that the spec should be modified.

So this discussion is "academic" in the sense that it is not intended to address specific instances, but it is nonetheless an important one. Without knowing what the guiding philosophy is, it's hard to know how or even whether to discuss what to do in cases like keyword search.

-- MeredithLesly - 23 May 2006

Examples are needed I can see.

Example 1.

Someone finds out that the formular for a matematical function in SpreadSheetPlugin returns the wrong value. The value is negative when it should be positive. And positive when it should be negative. Some people may have figured this our and put a - in front of the result. Should we fix such a bug when reported? YES. Any sucker that has worked around such a bug and not reported the error back to the TWikiCommunity is a fool and we cannot possibly let such a bug stay for backwards compatibility.

Example 2.

Someone thinks the syntax for AND in search sucks. (using ;). Someone suggests that we use the Danish word OG instead and drop any use of ; or AND or &. At a release meeting a whole delegation of Danes show up and vote out all the others and a majority decision is made to change the spec and not give a damm about backwards compatibility. Should we implement this. NO. Send the marines to Denmark and nuke them away.

Obvious bugs where something does not work or returns wrong results should always be fixed.

And changes to the specs of our end-user-features in a non-compatible way just for the fun of it should be avoided always.

But in between black and white there are always plenty of cases where there are pros and cons. Performance vs Compatibility is going to be a hot topic in the time to come.

But we have to take it case by case. You cannot decide a generic rule. If you do - it will be worthless because people will discuss each case anyway.

When in doubt - start a discussion - and be open minded to compromizes. And always consider the impact on the end-users first. And the admins second. Then you cannot go entirely wrong. No need to worry about the developers. Their viewpoints are always over-represented anyway.

-- KennethLavrsen - 23 May 2006

No one is asking for a generic rule. But if, for example, anything that breaks compatibility is not going to be allowed in Edin* (or 4.1, or whatever), it would be much better for developers to know that sooner rather than later so they can decide whether it's worth spending their time on something that may be vetoed on compatibility grounds.

Someone described TWiki to me as suffering from metaphorical progenesis. Some of us are trying to find out if that's true before throwing good time after bad.

Amusing, your saying "When in doubt - start a discussion". SP was complaining about that in another topic earlier today.

-- MeredithLesly - 23 May 2006

Example 3 The released docs says that type="keyword" looks for whole words. The code since Cairo say that it looks for substrings.

What should we do? (not that that's the case, is a fictional example based on a true story).

-- RafaelAlvarez - 23 May 2006

BasicForm
TopicClassification NextGeneration
TopicSummary Discussion of a guiding philophy regarding misbehaviour regarding specs
InterestedParties

RelatedTopics KeywordSearch
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2006-05-23 - RafaelAlvarez
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.