>> I have never seen a project that needs to be forked as badly as this >> one. You sit around and nit pick about about which dinner glasses to >> pour the water into. Somebody shows up with a firetruck wanting to fill >> the swimming pool and you can't handle it. >> >> This firetruck ain't waiting. >> > > Okay, Mr. Firetruck. Put up or shut up. What is so wrong with this > community that it needs to be forked? Give us your manifesto. The > soapbox is ready for you to shout it out to the masses. > > I will then try to address each issue that you have in turn. I have > been where you are standing, and I am sure that I can withstand any > flame you bring at me or this community. > > That goes for anyone else that is thinking the same thoughts. Vent it. > It will feel good, and maybe we can move forward. Forks should be the > last resort of the exiled or oppressed. You are not the former, and you > need to make a solid case for the later. > > >> BTW, the reason this patch was submitted as one is that it cannot be >> separated. The system won't work with the reduced tms_seq clocks. When >> does trust enter into this? >> > > Yes, it could be separated. I could do it myself, but I have my own > list of tasks. My response was based on community standards with which > you apparently do not agree. 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. >
Zach, You are not, at least not yet, a poster boy for what is wrong with this project. So I apologize to you personally that I was not precisely clear that my anger and frustration is with the project and not with you. You were doing your job as you have seen it done before, and as you understand it. You asked to try and understand my point of view. I thank you for that. 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. More elaboration on my points of view: 1) Qualified development expertise is expensive. It is not free. 2) Not all development contribution sources, i.e. individuals, are equally qualified. 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. 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. *************************** Finally, back to the metaphor, because it will also help clarify: "You sit around and nit pick about about which dinner glasses to pour the water into. Somebody shows up with a firetruck wanting to fill the swimming pool and you can't handle it. This firetruck ain't waiting." A) The dinner guests are swaggering about the kitchen, arguing about what dinner glasses to use for the water. B) The firetruck pulls up to the street out front, hoping to fill the swimming pool. C) The guests all run out of the kitchen on to the street to look at the firetruck, in astonishment. D) They don't even know they have a swimming pool. This is the saddest part of the entire story. Their only understanding of water containers is the dinner glasses. E) They tell the firetruck operator that all water must pass through their precious chosen dinner glasses before entering that strange container in the back yard. F) The firetruck operator looks at his watch and says, geese, this going to take a long time. Why don't you just fill the pool and then turn on the filter afterwards? Wouldn't that be a better use of *my* time? G) No, no, say the guests, we have to view each and every drop of water as it passes into the, ah pool, as you say. H) Firetruck operator says, "sorry, this firetruck ain't waiting, it is too expensive. It costs money for me to even be here, whether I am pumping or not." *************************** 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. 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.) 1) Doxygen config file. 2) Doxygen comment style. 3) Uncrustify, C/C++ beautifier. uncrustify.cfg file. This was an opportunity lost to clean up the presentation of the code and to quit arguing about where braces should be. 4) Cable helper API, organization and documentation. tap_state_name() tap_set_state(), etc. 5) xsvf.c rewrite. 6) ft2232.c rewrite. 7) CMake build system. All in a several weeks, with my hands tied. 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. 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. Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
