#Loosen Bug Fix restrictions.

1 messages · Page 1 of 1 (latest)

hexed swan
#

I think MT should take a more nuanced approach to fixing bugs while attempting to maintain complete backward compatibility. I feel like there is an inflexibility there that is not conducive to the evolution of the existing product.

When making a fix that breaks established behaviour, perhaps we could allow for some wiggle-room?

For consideration:

  1. So long as it does not remove some feature or capability that currently exists without adding an equal or superior option requiring a similar level of technical proficiency to implement.
  2. So long as it won't require "significant" refactoring of existing frameworks to maintain current behaviour.
  3. So long as it doesn't create an incompatibility of campaigns in newer versions of MT (i.e. the campaign file can still be opened and modified in the newer version.)

Yes, allowing devs to decide what is "significant refactoring" could be a slippery slope. But hamstringing them into not being able to address bugs is also. If devs can't agree, engage the community for an open period of comment on an issue and go with a majority "vote". Then, if the community facilitates "breaking" something, no single dev (or handful of devs) need feel responsible... said community often deals with the fallout from fixes that "break" frameworks anyway.

And, again, continued emphasis should be that nothing is lost or extraordinarily difficult to adapt to.

#

(continued)

Sometimes (probably most of the time) if a bug has been around a long time, it is because it's a low-use function or feature. Worse, it could be something people have just lived with or worked around rather than put in an actual bug report (which is an entirely separate issue... I mean, why put in a bug report for something that's existed a long time when you're going to be told it's not going to be fixed because it's existed a long time? It's such a weird outcome once you've found something that you've taken the time to debug, verify, and document only to be told, "Too bad you didn't find it years ago.")

I often wonder how many bugs/features Jams "fixed" with nerps (which was his personal build of MT) that would have been vetoed had he tried to submit every PR, one at a time, through more traditional means. And, yet, MT is better for the "leap" in features and development that adopting it as Core spurred.

Standard disclaimer: I appreciate the time and effort that all the MT devs have put into the development of this program. As a framework dev and forever GM, I understand the thankless role facilitating games for people can be. I want MT to evolve and thrive. I want to see greater community engagement and adoption. And I want to keep using MT to play these silly games we all love. I have no greater entertainment interest worthy of wasting this much time on.

fossil nova
#

Couldn't agree more. 💯

mortal storm
#

Well, sort of “typical” development process is to have a stable release that only gets bug fixes and no new features, then a second development release that is often bleeding edge in terms of features and options. However, MT has never had enough people to wear the needed hats to make such a process practical.

winter yarrow
#

This goes back to the comment I made a while ago, if we can't get help testing, then we are going to run into a lot of these scenarios. If something that people could use as functionality survives a couple of versions its likely to stay unless its really a breaking bug. Just because person X sees something as a bug doesn't mean other people have been using that thinking its the functionality they want

#

The alternative is potentially breaking everyones framework/campaigns/etc

#

Also, fixing a lot of these things requires making large changes behind the scenes which cause new bugs that are difficult to fix (I think 80% of my time spent on add-ons was spent on making sure lib:tokens still function correctly, and even then, there were bugs that had to be squashed multiple versions later). This is why I am not entertaining adding new functionality to lib:tokens anymore

hexed swan
#

We get the testing we get though. There is no magic wand for that. Bugs get found when they get found. Get reported when they get reported. Low use features and functions will take longer. (e.g. the only reason the bugs in the shape functions are being found now is because a translator is trying to build the wiki pages for them... who knows how many years they would have hung around without that!)

And this suggestion acknowledges that some fixes will "break" some usecases... the idea is that it's not black and white. All breaks are not equal. And neither are all fixes. If a fix requires large changes behind the scenes then it probably becomes self-deselecting because no one wants to put in the effort to fix it. But that's a different reason to not fix a bug than what I'm suggesting here.

And, finally, how some people are using a BUG might be a kind of feature... thus the concept of allowing a fix so long as existing functionality can be maintained (even if it requires some modifications) could be a guiding principle rather than just vetoing the fix altogether.

@drowsy tree made a good point in his git post where a project like FoundryVTT doesn't allow the idea of "forever compatibility" to get in the way of progress. Updates break mods/frameworks. I don't know if they are too "uncaring" about the consequences of their updates or not (they probably have some guiding principles and aren't out to destroy their entire ecosystem with a simple fix) ... but I do know that MT seems to be too inflexible... which discourages testing, bug-reporting, and new developer contributions.

The suggestion is to loosen restrictions, not throw all caution to the wind until there is a complete melt-down.

drowsy tree
#

Also, I feel that if a bug fix breaks things -too- badly, just pull back the fix/feature (ala the GDX renderer).

fossil nova
#

I do see Craig 's point, but personally I completely agree with FB and Tucker.

winter yarrow
winter yarrow
fossil nova
# winter yarrow Which wheel do you think is squeakier, the one where all their stuff breaks, or ...

I think it is the nature of all software, that over time there will be breaking changes and require significant work to incorporate. Software that does not "clean up" from time to time will stagnate eventually, simply because it becomes to diificult to add new features or improve existing ones. I completely understand the desire to stay as compatible as possible, but not at the cost of serious impovements, like a new rendering engine to pick one random thing out of the blue.
Of course, I cannot speak for everybody else. But I won't mind having to rework my framework on occasion. But I seriously doubt it would be necessary to rework everything or even most. After all, it wouldn't be something I had to do every month, but rather once or twice over a presumably long period of time.

winter yarrow
#

I will quite happily make said changes if someone (or some people) volunteers to maintain the older frameworks people still use, but are no longer developed. hows that for a compromise 🙂

fossil nova
#

That is not really a compromise, but rather an ultimatum.

hexed swan
#

There are plenty of popular frameworks and tools that are currently "broken", regardless (BoT and Takehara's 5e come to mind). I know I've had to "fix" Token Manager about 4 times in the last decade. And if a dev of a particular shared tool is still supporting their work, just about everyone I've had to deal with steps up when confronted with an issue (whether it is new or old).

I think users around here are happy to help people fix stuff. Collectively, I think the community does a pretty good job addressing people's issues given the relatively low level of engagement that we have. But, if anything, the breakage caused by the latest parser change proves that a lot of the old tools just aren't being used... or the break fits the criteria I posted above: The user fix isn't that difficult and we all just took the lick and kept on truckin'.

drowsy tree
# winter yarrow I will quite happily make said changes if someone (or some people) volunteers to...

I've found that even if something is broken with updates (ala the Weather Channel drop-in), it can be fixed by people still using it, or they can ask for help and the community generally steps up and helps them get it working again.

Almost all of the old frameworks and drop-ins were broken by the parser update, but with some support from this server I was able to get them working again, and I'm not a dev/coder (learned pretty much all my coding from MapTool).

I think most of us are willing to help others get old frameworks/drop-ins working again if a patch trips something up for someone.

So, even though it's not necessarily a guarantee, I feel it is -very- likely anyone wanting to use a previous framework/drop-in will get help keeping it operational, even if that help doesn't come from the original author.

winter yarrow
#

The parser change was not really equivalent though as that was just a simple bracket mismatch, no need for any one to dive into the details of how anyone's code/framework worked. That is a big difference from debugging and fixing logic errors

drowsy tree
winter yarrow
hexed swan
#

The problem is that the "weigh against possible breakage" seems too tight. In many cases, improbable, very low impact, and easy for anyone using it to just fix (like the parser error). And certainly not taking into consideration the explicit "loosening conditions" I put in the OP (which was just a first draft of the idea in an attempt to establish some actual parameters for reducing vetoes).

How many frameworks, for example, are out there using overlays with explicitly set pointerblock elements that the framework actually wants MT to ignore so that notes pop-up though those elements? It's a bug. And it feels like if it was fixed people could properly block clicks and people who were "exploiting" the bug could just alter their CSS to not block clicks if that's what they wanted. I've never run into this issue because I'm not building complicated overlays, but I could immediately see how annoying it would be if the token notes did that through an element I explicitly wanted to block clicks. So much so that I'd probably have to sacrifice token notes all-together to use the overlay. But, no, "old bug won't fix".

Same with JMR's onChangeSelection fix... the idea that there are a lot of users out there exploiting the double fire bug (only ever heard complaints about it) that couldn't just adjust their event to double fire more easily than it is to try and work around the bug seems to be a much tighter adherence to the "old bug, might break something, won't fix" mantra.

#

Keep in mind that I didn't want to bring up specific cases because I didn't want to turn the thread into a litigation of each issue... that could be done at the point of the bug report or discussion of the issue. e.g. Will fixing the issue break some frameworks? Maybe. Will they be able to fix/adjust to them easily if it does? If the answer is yes, at least exercise a willingness to break them if there is a tangible benefit to "fixing" the issue, etc.

hexed swan
#

Also, please don't take my verbosity as an indication of super strong feelings on this. I just think that MT could afford to take a few more chances in this arena to improve the software.

fossil nova
#

Completely agreed. MapTool risks stagnation if every "old" bug has to be weighed against every old unsupported framework. It may be hyperbole, but that is really what it sounds like.

winter yarrow
# hexed swan The problem is that the "weigh against possible breakage" seems too tight. In m...

Jmr's onChangeSelection fix had multiple more than that one problem. And even for that one problem, it is completely possible that someone would trigger a selection in a macro and expect it to do something, even if it was selecting the same thing that was just selected. For an issue that was documented as something that the macro writer has to take into account since the event was created removing the inconvenience is not worth adding a partial fix that doesn't solve the problem in all cases which means you potentially break peoples workflow but still require people to account for multiple selections

#

So there is no tangible benefit to that fix, only downsides

maiden lantern
#

I would ask if there are problems with any feature, patch, update, bug-fix, etc, the focus should be why that code is broken and not why that code can't work due to a,b,c use case. I got bent due to what I'm calling a disagreement in what or how it's broken, however if code is bad code, that is a legit reason to reject.

winter yarrow
#

Since you want to bring this up, I never said no to your change

  • I asked you to test a scenario, which still needs to work.
  • Then you made some changes and said, it still fails for that scenario but "I've changed the time check to 300ms and it's working as I'm expecting"
  • Then you closed the change
maiden lantern
#

I don't want to bring it up :). I'm ok with the decision you made. I didn't like the reasoning you shared, that is all.

winter yarrow
#

So should I be expected to accept a change when I say it needs to be tested for X and a change made to make sure X works and the person making the change says no

#

Then that person runs to discord and says his change was rejected when in reality he decided not to consider the scenario required and abandoned the change themselves?

maiden lantern
#

I did the testing you request in my "bubble" but lets not go there.
I think the point of the thread is how can we make this more progressive, with limited increase in risk.

Maybe demand a new gate (your compiled code must be tested on 2 OS and 2 "testers"), if the code is questionable or unclear (or just because it was done by a novice vs a developer), or create RC's of code that run for X weeks before final release is done.

Regardless of what you think, I have a huge amount of respect for you, I'm not blind to your conundrum, I do not envy your position, it is not easy (specially when you've got idiots like me 😉 ).

#

I'd like to avoid specific PR, FR, etc. I think it's attempting to find a process where more progress is made with limited risk. For short term gains, this probably fits ok, but for long term objectives, vision, etc. I can see where the conflict can come from . . .

winter yarrow
#

I never called or implied you are an idiot. I am happy to support/help anyone make the changes required to make their contributions work as they should. But by the same token, I don't say X still needs to work after the change just to make people's lives hard or because I am a bastard (I am not denying being a bastard but I have much more creative ways to express that than the need to do this 🙂 )

#

back to the pointermap thing, if someone wants to make it an option (show notes through overlays, but please think of a better name) then that is a possibility

maiden lantern
#

I know you didn't, I called myself that 🙂 /hug

#

I may poke you again on that oCS change but only if there is "hope". If it's dead, I'm ok leaving it dead 🙂

winter yarrow
# maiden lantern *I may poke you again on that oCS change* but only if there is "hope". If it's ...

As I said you just need to make sure intentional macro calls still trigger the event. Either creating 2 methods for selection, or add a parameter to the existing function (if you do the second please don't make it a boolean true/false as that is never clear what is true or false unless its from the method name e.g. setVisible(true), add an enum with 2 values that make it clear the event should or shouldn't be retriggerd on no change)

drowsy tree
# winter yarrow As I said you just need to make sure intentional macro calls still trigger the e...

Again, this is coming from a non-coder, but I'm wondering if comparing the onChangeSelection code from when it fires when -not- holding shift to the code that runs when holding shift might give some insight as to what is happening in the former case?

Since the onChangeSelection fires in both scenarios, but frequently fires twice/multiple times -only- when not holding down shift, would comparing the code that fires during those two processes potentially identify the variation?

Just hopeful, not implying it should be obvious, since I have no idea how complex these processes are.

mortal storm
#

@hexed swan I’m afraid your attempt to stay on topic has failed. 🙂

Code changes can break the usage patterns for MT in a variety of ways. IMO, loading old campaigns/maps/tokens should never break, if at all possible. There are mechanisms in the existing code to help support that.

Changes that affect the UI, I’m fine with. I understand that others may not be. I put theme support into this category, along with iconography updates, layout updates, and restrictions to layout that the GM might impose (like players not being able to use the Select Map button). Applications change their UI all the time and people will bitch and moan about it when it happens, but they get over it.

Changes that break automations are the most difficult to judge. If a change breaks how a MTscript function works in a way that will cause existing usage to fail, that change needs to be discussed in the open. Earlier is better in this regard. I believe this is the one that @hexed swan is most interested in addressing. In addition to having code reviews, perhaps this type of change should have a “focus group” review. For example, one or more of the old timers here check that a breaking change is reasonable given the situation. GH could have a “focus group” role and folks could ask to be assigned to that role. When a breaking change is expected in an issue (or is included in a PR), that role would be mentioned to get their input. Some deference would need to be given to that group in terms of how and/or when the change is actually made.

winter yarrow
#

Ok I need to say something before this gets out of hand,.

#

Please to not engage @mortal storm on this topic, ignore his above comment, or if replying please do not tag him

#

He has made a commitment to stay out of feature requests and development discussions, and he is constantly breaking it.

#

So it needs to be pointed out

fossil nova
#

IMO, loading old campaigns/maps/tokens should never break, if at all possible.
And this is where I am in complete disagreement. At some point it is necessary to break with old stuff in order to move forward. If this breaks an old campaign or an old token, or whatever, then one can still use a previous version of MT. They may even be able to upgrade the campaign or token etc. by using intermediate versions. If not, so be it.
I read lots of threads on this forum where people are using older versions still, so it is not a foreign concept to many.

I'll make a suggestion then. How about beginning to seriously plan for a MT version 2.0. This is the version where things break in order to clear up old code and old mistakes. This would preclude 1.* from getting bug fixes, or even new features, if the feature developer is willing to support both version, I'll wager some are, at least for a while.

winter yarrow
# fossil nova > IMO, loading old campaigns/maps/tokens should never break, if at all possibl...

Generally, loading old campaigns is not a big issue; there have been many changes that silently convert to a newer representation/format or ignore no longer used fields. The only time a format change resulted in the inability to read older campaign files (that wasn't an accident and quickly fixed) was a couple of years ago I removed code to read version 1.2 campaigns (that had stopped functioning correctly some time in 1.3).
If it ever gets to the point where we need to make a change that is so large as to not be able to read the file there will be either an import old or a conversion utility made available

hexed swan
#

MT has been great about backward compatibility when it comes to load-in and I don't want to lose that... I tested some early versions of my framework last night (from 2010 and 2011) and I couldn't open them in 1.12 (the oldest version I have installed right now)... but my 2013 backups of the "same" framework opens in 1.18 which is pretty cool. I might even be able to walk those early ones up to the point I could open them now... but my curiosity isn't worth the trouble.

thorn mountain
#

To give my two cents - from discussions I've seen of other VTTs online, a major complaint is having updates break things, particularly just prior to a session without time to fix them. This is a definite advantage that the philosophy of not breaking stuff gives MT over other VTTs.

That being said, another advantage of MT in this respect is the ability to ignore updates. Unlike the web based VTTs, the timing of updates is entirely on the user. They should always be able to time updates to give themselves time to make sure everything works, or even in the case of users running games daily install multiple versions for testing.

In my (admittedly inexperienced/uneducated) opinion, it seems like we could take advantage of users not being forced to update the program to loosen our current bug fixing restrictions. We would still be able to avoid the day of session update problems this way, and if most people are used having to update in a panic then just having to update eventually should be much more manageable.

Since maintaining frameworks was mentioned, I think there's also probably a bit of chicken and egg problem with that. As is, if these frameworks will never break (which is not entirely the case, see parser issues mentioned earlier) then there's no impetus for someone to maintain them. If frameworks are still being used, then someone else will step up to maintain them as was done with Rod's.

jovial cradle
#

@fossil nova has a valid point about MT version 2.0. If MapTool development adhered to Semantic Versioning (SemVer) (which it purportedly does), then that already makes the provision for bug fixes which break backward compatibility, they just require a MAJOR version change. Bug fixes which do not break backward compatibility would just require a PATCH version change.

We are forever burdened with backwards compatibility for as long as were are stuck on version 1.Y

But what is a bug fix? Again SemVer helps defines these as:
"A bug fix is defined as an internal change that fixes incorrect behavior."

But what is "incorrect behaviour"?
This seems to me to be the bit which can be subjective, and perhaps needs a clear and documented definition for what MapTool considers this to be.

But what is the dev/user community appetite for MAJOR versions? It seems to address various concerns raised here (and more), but I am not privvy to the effort or impact though I anticipate it would be a significant change to how things are done.

winter yarrow
#

If we are going to break backwards compatability I would like to rip out lib:tokens and all the current events 🙂 Those would be my first choice , keeping those working when adding new functionaliy/making changes is a royal pain and requires a lot of work

#

Also the ability to execute macros on mouse over from evaluated properties

#

Just not having those would mean many nice feature changed would be much easier, take less time to implement, and be less prone to bugs

maiden lantern
#

I'm all for a fresh starts. I just don't know what that would look like and how far out it would be.

I'd be good with say, if you came up with an update, some kind of major refactor, that stated, lib tokens are being phased out, this is phase 1 of several, Lib:tokens events are no longer supported, phase 2, lib:tokens can't be used for X, etc.

Or even, lib tokens are "gone" as of version X.

I don't know what is better, constant large refactors of the current base vs a nearly clean build fresh start with 2.0?

I don't want to turn this into an add-on discussion but they're just not as easy to deal with so it has created a hurdle for many that doesn't net a "value add" enough to make the commitment to fully embrace add-ons.

#

I'd also want to make sure MapTool retains "local play". So whatever is done with add-ons, lib:tokens etc, retaining the option to play, disconnected should be a continued future requirement.

hexed swan
#

Until add-ons are as easy to use, edit, and update in-app they're not likely to replace lib:tokens. That said, everything @winter yarrow mentions for excision could be the basis for a v2 as far as I'm concerned. But, after ripping everything out, until v2 reached feature parity, it won't be heavily adopted. Like libgdx, having more potential isn't enough.

#

Presumably, even if v2 required add-ons, MT has (in theory) an add-on export... so it seems like there might be a path from v1 to v2 migration for many libs. That said, being a little more aggressive in fixing bugs in v1 that would require some framework updates isn't anywhere close to what moving to a v2 would be like.

thorn mountain
#

I'm personally alright with moving to a v2 and breaking compatibility if you think it'll be that big of a benefit for making it easier to add feature, but I would hope that feature parity is kept. Like FB says I think the original topic is a different conversation than moving to a full v2 - the bugs that I would have in mind fixing with a loosening of restrictions would fit into either the category:

  • Things that aren't established/purposeful features of MT (e.g. events/lib: tokens mentioned)
  • Bugs that have been known for a long period of time and a statement has been made that it will not be fixed, so there is an expectation that they can be used (e.g. nesting 2+ code blocks exploit)

Newly discovered bugs would not fall under the above categories even if they have not been discovered for multiple versions.

drowsy tree
#

I'm all for moving forward and breaking compatibility so long as there are still ways to achieve current (or improved) functionality. One thing I love about MT is that it feels like with enough creative thought and effort, it can do just about anything I can imagine.

I'm wondering what that might look like without lib tokens and the event system, as I definitely feel there would need to be ways to achieve what those enable via some other functionality. But I'm sure there is already a framework for that if the goal is to move beyond those limitations.

fossil nova
thorn mountain
#

Well, to clarify I think we already have the event system he wants? The ones linked to addons. But remove the legacy events. Correct me if I'm wrong