Zach, You are a quality guy and I want to go on record, with you being the recipient, of why I am leaving the project.
>>>> >>>> >>> Yes, it could be separated. I could do it myself, but I have my own >>> list of tasks. If the patch was separated and only portions of it were applied, it breaks the system. I was avoiding that possibility. This is a significant patch, because it actually gets the reduced clock support into ft2232.c, adds rigorous state tracking, and adds improved error recovery. By having the tms_seq[] in jtag.c, this requires it to be part of the patch payload, even though ft2232.c is where most of the work is. Some of the work in there is from Jeff William. Some of the concepts are from Duane Ellis. The whole reduced clock effort was my favor to Duane. I did not need it. >>> My response was based on community standards with which >>> you apparently do not agree. Correct. This is the proverbial dinner glass with which I strongly disagree and is why I am leaving. As a volunteer giving away my valuable time, it is unfathomable that a recipient of the value given away would be so picky about the gift. My perspective: it would be like you volunteering to mow the grass of a local old folks home. And then the home management comes out and says that you have to use a push/hand mower (remember those), rather than your riding mower. When you accept and commit a patch, the value is flowing 90% unidirectionally from provider to recipient. The provider already has his/her patch. Using non-commit as a disciplinary weapon is childish and illustrates that need for power and control, as a higher priority than the advancement of the project. It turns people off. >>> That is fine. I was not imposing them, >>> rather providing my opinion. A strong opinion to be sure, so what? >>> >>> Again, I did not deny the patch; I deferring it to others guidance, >>> because it touches key elements of the system. I am trusting other >>> maintainers that have more experience to judge its correctness, because >>> it is bigger than I can get my head around. They can chose to ignore or >>> accept my opinion about it. >>> It would have been appropriate for you to say, "Thank you. We will let it roost on the list awhile and let folks give it a look see. I have some concerns about the size. Why do you think it needs to be so big?" > But before I start, I do want to stop and pointedly thank you for the > contributions that you have made to OpenOCD. I appreciate the donation > of time and effort by skilled developers like yourself, and I am > motivated in these matters because I see only mutual loss if you chose > to leave the OpenOCD community. > This one remark distinguishes you among the crowd. Stand up and accept my award to you for a quality guy. When I recited my contributions the other day. I did not list the xsvf_tools. So add another 1200 lines of code to that list, if you will. I believe this probably does put me at or near most productive developer in the last 5 or 6 months. But it has been clear to me for some time now that those in charge of this group are more about power and control than they are about advancing the project. If this were not so, CMake would have been in there already. The mere fact that NOBODY offered any effort to try and meet my needs, confirms this. "You do it our way or not at all", even if this means losing one of our most productive developers. In a similar situation, this is the moment Linus says to Russel King "OK, you keep your separate GIT tree for ARM kernel development. We have an impedance mismatch. The source impedance is less than the transmission line impedance, and there would be too many reflections if we tie them together. We'll merge up once a month or so, but I trust you to handle the ARM stuff." I think I saw 60 email messages cross this list yesterday. Many had patches. Many patches look like they are not "age tagged" or have any voting mechanism to track their status in reaching an acceptance threshold. So I am completely non-empathic to the "small patches" nonsense. How do you advance the project if not by changing the lines of code that the compiler sees? Make the developer mow the grass with a push mower? GIT was invented for this reason. I am not recognizing a new idea here. In the end please remember this. You can set project policy. But you cannot determine how a developer spends his or her time. And my favorite saying about open source comes out now, "he who does the (volunteer) work (or pays for it), gets to decide how it will be done". And a special mention goes to the hospitality of Rick Altherr. It was noteworthy. Rick, if you ever get near Texas, give me a call, I would like to show you a contrast in style. I try and do what I say I will do. I have 3 outstanding, personal commitments to this project. You will see two more patches coming from me soon, as they are 2 of the outstanding personal commitments. And Rick, the cost to me is "lost opportunity cost" if that is a familiar term. We were up in April nearly 50%, thank God. Warmest Regards, Dick P.S. I don't think our differences are reconcilable, so I think this is probably the last time we need to discuss this. I know what my time is worth. The project seems to know what it wants. We are done. > >> In a nutshell, the project policies make it too expensive for me to >> continue to contribute. It is about money, which comes from the >> expenditure of wasted time. >> >> It is that simple. >> > > I understand that, and I can tell you that forking is more expensive. > Despite their costs, collaboration and consensus are better. With this > in mind, are you willing to work with the community to develop policies > that would be satisfactory? This will require give and take; you cannot > expect that all of your expectations will be satisfied. > > >> More elaboration on my points of view: >> >> >> 1) Qualified development expertise is expensive. It is not free. >> > > Yes. As a professional software developer, I expect to be paid for most > of my time, and I value the time that I donate to open source projects > equally. Something to take from this: you are not the only qualified > developer in this community. > > >> 2) Not all development contribution sources, i.e. individuals, are >> equally qualified. >> > > No qualifications are truly unique or irreplaceable. That said, I value > your contributions and character; every person brings something unique > to a project, and it is always a loss to see those skills depart. > > >> 3) Any use of the linux kernel project as a role model for this project >> is frought with self peril because the linux kernel project is a funded >> project where developers get salaries and can afford to erect safety >> barriers to progress. It is about money. They can afford procedures >> and policies, which if adopted by this project, would needlessly impede >> progress. You may want to impede progress, I do not. Perhaps someday >> there will be an openocd foundation with a corporate financial payroll, >> and this may be the only part of the linux kernel project that should be >> aspired to until there is funding. Until then it is prudent to realize >> that beggars cannot be so choosy. >> > > The first problem that I see with this argument is that it fails to see > the benefits of the processes. It is not about money. It is about > managing the complexity of a large user base and high rate of change. > > The second problem relates to your conclusions about cause and effect. > I believe Linux attracted money because it is a high quality kernel. > Period. Money did not build the kernel; passionate hackers did. If > anything, the cost of participating in the development of the Linux > kernel has remained a constant over the years, thanks to improved > processes and tools that I have been described. Of course, the costs > will be exorbitant unless you have learned to abide by the practices, > but that can hardly be claimed to the fault of the processes. > > The final problem goes back to your first point; you are not the only > qualified developer, so I do not see why you deserve exceptions when > others can follow these practices without requiring enforcement. > > >> 4) The software being developed by this project is no where near >> satisfactory. The stuff barely works. It is no where near what it >> could and might be someday. The driver I spent a week on was basically >> garbage before I started. If this project was where it could be, there >> would literally be NO commercial alternatives. e.g. Samba basically >> put Novell out of the networking business. Openocd is not putting folks >> out of business. >> > > To be perfectly blunt, I believe the present quality of the code is a > direct reflection of the architectural-level management in the project, > or, rather, the apparent lack thereof. In other words, I agree with you > completely on this point; worse, I know it is an endemic problem caused > by the shortage of strong leaders that are also serious developers, as > these are the only people that can rise to management in open source. > > There is a load of room for progress for improving OpenOCD policies, but > I do not expect the policies that I described to be implemented > immediately. Still, some policies do need to be put into place, as this > type of conflict will arise on a periodic basis. Presently, I see this > as a lack of social contract, contributor and maintainer policies, and > disciplined architectural oversight. Without such processes, there will > be ongoing SNAFUs, not unlike those I have already experienced here. > > I would love to help lead this project to exact the goal you describe: > being the #1 OCD software package. With proper oversight, I do not > think it would take more than a year to get from here to there; however, > I also believe such would only be possible with the development of clear > management and community policies that prevent these kinds of flame wars > from being a distraction. We simply refer to our policy and repeat the > standard phrase, "RTFM and STFU." Talk about saving costs! > > >> *************************** >> >> Finally, back to the metaphor, because it will also help clarify: >> > > I think it actually muddied the water, but it was entertaining. :) > > If I understand correctly, your main point was that you see the > processes that I suggested as being too costly. > > Unfortunately, I have repeatedly try to point out that those processes > should be something to strive toward; they are not a barrier today, just > my personal recommendations. Second, splitting patches provides > high-quality review by others, and this will be required to scale up. > It will reduce the cost for everyone, at a slight personal expense of > learning a different process and new tools. > > [snip] > >> *************************** >> >> >> In the next few weeks I would like to prepare a roadmap document for >> where I think a project like this one should go. I will make that >> available to this group. That will basically be done to determine who >> and how many other folks would see my vision as an attractive >> destination. From that reaction I will then decide whether to make my >> fork public or not. But the idea that any such development could be >> done by pouring it through some tiny dinner glasses is silly, and >> economic suicide. >> > > Here are the questions that come to mind after reading this paragraph: > > 1) Will you take the community's input into consideration as you > formulate this plan, or do you expect us to accept or reject it like > your last patch (i.e. "take it or leave it")? > > 2) Why should the community trust your vision, when you are threatening > to fork us if you do not like its reaction? Personally, that option > needs to be put away and locked up again for me to take you seriously. > As it is, I think that you are too obsessed with your own vision to see > the needs of the community and come to a reasonable consensus. Sorry. > > I think your language here is threatening, though I hope that I have > misinterpreted that sentiment. > > >> So I do not see any way for me to continue contributing to this >> project, financially. Let me just summarize what I have brought to >> the project. Because the patches are not earmarked, there is often a >> short memory on who contributed what. (There's probably lingering >> doubt about the firetruck claim.) >> > [snip] > >> All in a several weeks, with my hands tied. >> > > Again, thank you for your contributions; however, I must remind you that > yours are not the only contributions. Moreover, your past merits can > only get you so far. At the moment, your threat to fork somewhat trumps > anything that you may want to contribute, since it will slow us down if > we have to understand the changes you made after you leave. > > >> The only other open source project that I contribute to might have >> tainted my understanding of what can be done. It is not uncommon for >> me to contribute 4000 line patches at a time. >> > > For the second time, I want to remind you that my original reply was not > a reject of your patch. I deferred it to others. At this stage in the > game, there is nothing wrong with big patches that will move us forward, > but I repeat: I do not presently feel qualified to judge your patch. > This still does not invalidate my point: you used an inferior process. > You could have split it up; I simply see this as a common courtesy. > > If you have only ever contributed to two open source projects (and > considering all of the other facts that you have given us), you are > probably not qualified to lead this project -- but I could be wrong. > Open source management requires a completely different approach than > proprietary products. Heck, I have contributed to dozens over a decade > (and led more than a few), and I still barely feel qualified to be in > this kind of position. [[I mean, just look at what it entails. ;)]] > > You can never stand to have enough humility in these circles. I assure > you there is a better developer than either of one us lurking here. > > >> They actually thank me over there. Because they understand that if I >> am doing it, it represents an improvement, and improvements are what >> they want. >> > > This again demonstrates a need for more humility: just because you think > something is an improvement does not mean that everyone else in the > OpenOCD community will share your opinion. There appear to be at least > a half-dozen different FTDI devices; are you really so sure that all of > them think your changes are unequivocal improvements? I am not so sure, > so I passed on the patch. Simple as that. > > We want improvements too, just not from cantankerous forkers. That is > not consensus building talk; it is mutinous. Some projects simply ban > individuals that make hostile threats like this. I do not believe in > such practices as I have come to believe there are ways to reconcile, if > only to come to terms for a peaceful fork. > > Keep this last point in mind. If you find forking to be necessary, you > will find yourself with many more followers and general open source > community support if you show a good faith effort to reconcile your > differences with the original project. In fact, I myself support the > idea of a C++ "fork", though I maintain "rewrite" would be more apropos. > However, I am not interested in dividing the community to do it. > > Cheers, > > Zach > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
