On Apr 23, 4:06 pm, Eric Shulman <[email protected]> wrote:
> Paul wrote:
> > I do feel we may be being overly cautious, and if there is scope
> > leakage then it will help refactoring and plugin authors if we
> > understand the problem better and have regression tests to follow.
>
> Unfortunately, BT/Osmosoft's track record on testing is *abysmal*
This may be true, but in terms of visible test code (that I'm aware
of) it is currently better than anybody else's record in the
TiddlyWiki community (I'm not counting TiddlyWeb here, which has
awesome tests ;) ).
BT/Osmosoft is not TiddlyWiki development. TiddlyWiki development, out
here in the open, on this list, etc. That's TiddlyWiki development.
It's unfortunate that BT/Osmosoft is perceived and/or allowed to be
some locus of control, because it isn't, or shouldn't be. TiddlyWiki
is an open source project.
I fear as we trend further and further down this thread that we are
losing track of that. TiddlyWiki is a project, not a product. Products
have owners, and processes and formalisms. Projects have people that
get together and discuss and sometimes get things done.
There's no formal QA process for the core code, because the
development community hasn't gotten around to making one. Not because
Osmosoft doesn't have one.
I'm not trying to be an apologist for Osmosoft here. You're right,
there have been some abysses, mostly related to the flow and
distribution of information. The most unfortunate side effect of these
flows is that people start expecting Osmosoft to be responsible for
various things which the community at large could or should be doing.
Where the community happens to include several people who happen to
work at BT/Osmosoft.
> As a result, serious (but subtle) problems are sometimes not found
> until exposed to the varied use-cases 'in the wild', where they can
> have an immediate "show stopping" impact on unsuspecting members of
> the TiddlyWiki community that rely upon a reasonable expectation that
> new releases will always be as backward-compatible as they can
> possibly be.
Here I would reiterate the product/project distinction. When a user
community of a project discovers a bug, they've fulfilled one of their
most glorious purposes. Obviously it is good to minimize the number of
times someone has to suffer a show stopper, but when someone finds a
heretofore hidden bug they are making a huge contribution to the
community and to the project.
With a product, instead, when someone finds a bug, they've been put
out by some power structure off yonder in which they have little
investment or opportunity to be heard.
> In addition, the usual response from the core team to these show-
> stopping problems has been, to say the least, extremely
> disappointing. Even when a ticket has been created, very little if
> anything seems to get done in the short-term to address the problem.
> Typically, a ticket will sit for months and months while the folks at
> BT/Osmosoft are busy working on their own "cool stuff" and plans for
> where they want to take the 'future of TiddlyWiki'...
Yes, this is a problem, but also there's no reason someone else
couldn't take that ticket, fix it, make a patch or even make a
release. That might end up being a fork, but if the existing release
process is not satisfactory there are plenty of other ways to do
things.
> * for users who hang in there, finding the problems in numerous
> plugins often involves a tedious trial-and-error process to reduce
> complex use-cases and isolate the causes with simple, reproducible
> test cases that can then be reported the individual plugin developers
> in hopes that a fix will be forthcoming.
Much of this tediousness is the result of the existing code and
plugins being far too fragile. Sometimes you gotta let stuff break to
get to a better place. When I experience bugs when upgrading
TiddlyWiki I see it as a flaw in the API, and API which needs to
change. And some of that change will break backwards compatibility in
some cases. It's inevitable. But time carries on, and so does our
data.
I know: That's easy for me to say, I can fix the stuff. I appreciate
that other people sometimes won't and sometimes can't and we must be
considerate of these situations.
> Of course, some of these developer's are no longer actively involved
> with TiddlyWiki development ('orphaned code'), or are busy working on
> other things ('a real job'), or don't know how to fix the problem, or
> simply don't respond for other reasons. Even when a plugin developer
> does respond, the amount of time and effort it takes to analyze,
> diagnose, write and test the necessary changes to just one plugin can
> be extensive (depending upon the complexity, of course).
Indeed. In large part because the core code and the plugin code is
incredibly opaque and encourages a terribly difficult debug scenario.
[snip]
> -- is over 2Mb and contains nearly 200 separate plugins and scripts,
> all maintained by one developer (me). Even fixing just one plugin can
> take many hours/days... all just to keep existing functionality
> working.
You contributions via tiddlytools and in the google groups are
awesome. That's not entirely germane to this discussion, but I'd just
like to point that out.
[snip cdent talking about what constitutes a bug]
> While that may be so, I strongly believe that the future of TiddlyWiki
> will be determined not by some theoretical principles of software
> architecture discussed amongst a small group of core developers and
> then released upon the world as a "fait accompli". Rather, the
> success or failure of TiddlyWiki as whole is entirely dependent upon
> whether or not it fullfills the needs, interests and intentions of the
> people who are actually *using* it. Sure, making it easier for jQuery
> developers may help encourage more plugin authors, but not if it
> damages the end-user experience and introduces FUD into the mix.
Agreed, up until the last sentence. What you say may be possible, but
only if we (the tiddlywiki community) let it. There's no reason it
needs to be true.
So to summarize, as I think I've wandered a bit:
What's going on here, in these discussions, is exactly what is
supposed to be happening: People in the community are talking about
decisions the community is making, and will be making. There has been
no failure in process: the process is happening right in front of our
eyes. Our mutual participation is gold.
TiddlyWiki is an open project with many contributors in many forms.
Osmosoft is a contributor. Open projects have bugs and will always
have bugs. Finding bugs is good form and a good way to be a
contributor. Helping to minimize bugs by various forms of testing is
good form too. TiddlyWiki is not a product. It is not owned by
something such as Osmosoft, nor released by Osmosoft. There is no
product that has to be or should be validated before it is seen by its
community: the community validates releases which the project
produces.
What and how the community chooses to release and validate for
TiddlyWiki is up to the community. The community needs to speak its
voice.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/TiddlyWikiDev?hl=en
-~----------~----~----~----~------~----~------~--~---
