On Fri, 2009-05-08 at 10:34 -0400, Chris Zimman wrote: > > 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?
No arguments here. You cut out the part of my reply where I agreed with you on this exact point. The execution was far from ideal. > > 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" I am not advocating either way; however, you failed to address my point about this community's resistance to change. If anything, you make it by presuming that I am in favor of these particular changes. > (2) Two people say "Don't, you're going to make a mess" I also said that Øyvind would have been wise to stop after the initial fuss was raised. You cut that part of my reply too. > (3) Maintainers ignoring them and moving forward, and making a mess, then > scrambling to fix it. We have not ignored them, but the rest is our SNAFU. > 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. How do you do development? Do you say: "I am not sure how I am going to fix this problem, so I should not even start." I hope not. > 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. I continue to be happy to receive complaints about the project, on or off the list. Funny though, no one seems complain except a few vocal folks that only post to this list. I am not interested in placating cowards that are unable to directly address their issues with us. Both of the individuals that chose to leave the community were given ample opportunities to try and resolve their issues. They chose not to work out their differences; I personally bent over backwards in both cases to appease them, but I failed in both cases. I am not happy about that outcome either, so I rather resent the implications you make here. To the community: If you have a beef, you need to air it and get it settled -- or leave. I will take an intolerant view to people that present a consistently negative attitude and disrupt this community. Such people are trolls and should be banished from any community. It's happened to me, and the shame of those incidents taught me how to be more civil. I will not hesitate to shame those who I see behaving badly, as I have come to expect to be shamed myself. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
