> Which was last updated when? I will make it a priority to grok this > document and regurgitate anything useful that I find to the list, but I > just want to point out that the lack of up-to-date backing > documentation raises questions about the objectivity of anyone's current opinions. > I believe internals should be fair game for being rewritten at any > time.
Usually, stuff like this is done in a branch -- internal changes that break things, no matter how well intentioned, suck. You don't go out, commit stuff into the head, break things and then say "Oh sorry, I'll hurry up and try to fix it." That usually just leads to making a bad situation worse. > At this point, I do not believe any of us knows with certainty. Exactly -- so why are these changes being forced into the head without first being tested in a branch? > Right: in_handler is/was a scan-specific "value fix-up" callback. > It does provide more context, but I do not think that it explains why > the implementation cannot be improved. The resistance to change in > this community worries me. The code is not in _any_ shape to be "preserved" > in its current state (unless we are talking about archiving backups). > OpenOCD needs to grow and evolve or it will not survive. Just my $.02, but what I saw here is: (1) Maintainers saying "I want to change this" (2) Two people say "Don't, you're going to make a mess" (3) Maintainers ignoring them and moving forward, and making a mess, then scrambling to fix it. The whole "you haven't presented any technical arguments why this shouldn't be done" holds little water since so far, all it's done is to cause problems. In the past few weeks, we've already had two people depart this project from being frustrated with the actions of maintainers. At the rate it's going, I wouldn't be surprised if more jump ship sooner than not. --Chris _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
