IDE oddities (was Re: Error Messages Are Evil)

Mike Kerner MikeKerner at roadrunner.com
Thu May 15 17:33:02 EDT 2014


This is similar to a discussion I had earlier this week about fixing the
issues I found in DataGrid.

However, what do we do about OnRev, especially if we are going to work on
it as a group of sorts?


On Thu, May 15, 2014 at 4:29 PM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

> Charles wrote:
> > OK, so what do we have to do, as a community of users, to get
> > RevOnline working again?
>
> Fix it.  :)
>
> My Community meeting this morning with Ben focused almost exclusively on
> RevOnline.
>
> It's true that LiveCode is inherently problematic to attempt to integrate
> into tools like GitHub, not merely because it's a binary file format and
> GitHub is designed for plain text, but more because of the nature of the
> workflow in which UI and code are intermingled.  Monte's spent considerable
> time explaining the Why of that, and if needed I could try again, but for
> now the bottom line on GitHub integration is that it may require engine
> enhancements to support, and given current priorities not likely to happen
> for at least a few more months at best.
>
> So in the absence of a GitHub workflow, clearly we need at least some
> alternative to move forward with community contributions on IDE components.
>
> We explored a few options, but one stood out as a *possible* solution for
> modest fixes in the short term.  I'm stressing "possible" here because he
> needs to review the workflow with the team to make sure it's going to work,
> but here's the outline:
>
>
> If a member of the community has time and interest to fix a bug in the
> IDE, the revised handler(s) can be added to the bug report, and the title
> of the report prepended with "FIX:" to flag it for the team as a report
> that also includes the fix.  And of course the post with the fixed
> handler(s) should note the object and line numbers where the original
> handler(s) can be found.
>
> For any issue whose recipe requires more than running a single line of
> code in the Message Box, a unit test stack should be provided illustrating
> the issue so that it can be run before the fix is applied, then again after
> copying-and-pasting the fix to verify that it works.
>
> Well-crafted unit tests may even be included in RunRev's internal
> collection for future regression tests, providing long-term benefit in
> addition to helping to ensure quick action on a bug.
>
>
> As an example of this workflow in action, we have a simple fix here:
> <http://quality.runrev.com/show_bug.cgi?id=11493>
>
> Since the code change is comprised of adding only five characters to a
> comparison string and can be easily seen in the Message Box, no unit test
> is required for that one.
>
> There may be reasons why they're not able to guarantee super-quick
> responses on reports using this protocol, but even before he runs it by the
> team I see no harm and potentially much good in encouraging interested
> folks to dive into fixing any issues you find particularly annoying, and
> including the fixed code in the report.
>
>
> True, this protocol can only address issues of limited scope, and at the
> moment is still being reviewed for feasibility.
>
> But the benefit of having fixed code posted to the report is undeniably
> valuable in guiding the team to the solution - all we need now is people in
> a position to supply the fixes.
>
> That last step has been the hardest.
>
> For example, after all the discussion of documentation issues over the
> years, once I got forum permissions to modify things there for community
> initiatives I took the time to set up a new forum section for that:
> <http://forums.runrev.com/viewforum.php?f=83>
>
> Thus far there's been some good ideas discussed, but no one in a position
> to actually act on any of them.
>
> Many of us juggle multiple priorities, much like RunRev themselves, so I
> can understand that it's far easier to imagine fixed code than it is to
> write it. :)
>
> It may be that we won't really see serious traction on community
> participation for quite some months yet, until the community grows large
> enough to include a greater number of people in a position to contribute.
>
> We'll see.  But in the meantime the core dev team at RunRev is actively
> exploring many ways to incorporate community contributions for IDE
> components, and if we start seeing fixes submitted to the bug reports we'll
> be able to refine and enhance the workflow to make sure it's working well
> for all of us.
>
> --
>  Richard Gaskin
>  LiveCode Community Manager
>  richard at livecode.org
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."



More information about the Use-livecode mailing list