I find Fred Jan's maintenance reasonable because sticking with current behavior
means 0% of patches in
the wild will be negatively affected. There's the possibility that his
maintenance hinders Max compatibility for future
patches, but this isn't something we can quantify.
We can _estimate_ the impact of changing Cyclone behavior by taking a large
sample of patches and mining them to see what percentage would be impacting by
such a change. (We can also look specifically at how
the behavior changes, how easy it is to undo, etc.) But obviously a change
affects 1/10000 patches is different than
a change that affects 5000/10000 patches.
But doing that would take a lot of time and energy. I'm not willing to do it,
and I'm not about to tell Fred Jan to
do that after he's taken on the task of maintaining an abandoned library. I'm
also not willing to do it because I
don't think it will result in any significant improvement for porting patches
between Pd and Max. But again, that's
just a hunch about future development.
If you have the opposite hunch then do some data mining so that we can have a
more meaningful discussion.
Otherwise we're just draining Fred Jan's maintenance energies-- overestimating
the potential damage of him
leaving some code untouched, and understimating all the other improvements he's
doing.
-Jonathan
On Tuesday, December 22, 2015 12:56 PM, Alexandre Torres Porres
<[email protected]> wrote:
2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list <[email protected]>:
Hi anyone encouraging backward breakage,
Please make a collection of as many patches as possible, from as many public
sources as possible.
Then mine this data to get a sense of what percentage of patches would be
affected
by changing a Cyclone class' behavior.
Then let's continue with conversation.
If no one is willing to do this, it's a tacit acknowledgement that Fred Jan is
taking
the only sensible approach to maintaining Cyclone.
I don't think I get this, or agree. Are you saying that people who wish to
break backwards compatibility should check if there's any patch out there which
could be affected, and then if no patch is affected we could change it? That
might be logical but not very reasonable.
But anyway, I don't think we should narrow the discussion to this!
I guess I might be "one" encouraging backward breakage, although I made
suggestions to not break it and said that the issue in discussion (the average~
object) did not really pose this dilema - let me stress and emphasize that I
don't believe this is a "A" or "B" choice, and I hope we do not really have to
discuss this like that.
Katja made other suggestions on how to "meet in the middle", it is perfectly
possible to change the behaviour with an argument or a message, I agree. No one
here is just up for backwards compatibility breakage so let's not, please, make
this such a discussion...
What really concerns me is anyone encouraging the breakage of the purpose of
cyclone (compatibility to MaxMSP). I don't think this is sensible at all, it is
a major change of course in the project.
Again, we're not really facing a dilema between backwards compatibility versus
Max/MSP compatibility, but considering Max/MSP compatibility not a priority
(even acknowledging there's a mistake that shouldn't be there in the first
place) kills the main purpose of cyclone and that'ss serious. I'd say it even
points to a fork in the project. If such a detour in purpose emerges from the
maintenance, maybe we shouldn't call it "cyclone" anymore.
On te other hand, if one is encouraging Max/Msp compatibility breakage, maybe
this person could check first if any user will be affected by that change.
There's me right here, by the way :)
cheers
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
