On May 3, 2009, at 9:39 AM, Dick Hollenbeck wrote:
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'm sorry that you find the time necessary to allow for collaboration to be too expensive for you. I know that for me, while my time is quite expensive, the cost to the project by not enforcing rules and procedures will ultimately kill it.
More elaboration on my points of view: 1) Qualified development expertise is expensive. It is not free.
Agreed.
2) Not all development contribution sources, i.e. individuals, are equally qualified.
Also agreed.
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 fundedproject where developers get salaries and can afford to erect safety barriers to progress. It is about money. They can afford proceduresand policies, which if adopted by this project, would needlessly impedeprogress. You may want to impede progress, I do not. Perhaps somedaythere 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 realizethat beggars cannot be so choosy.
Don't be so quick to judge. There certainly are paid individuals who work on the linux kernel, but not all of them. In fact, quite a number do it as a hobby or when they have time. They are able to conform to the standards for patches and allow for community feedback.
4) The software being developed by this project is no where near satisfactory. The stuff barely works. It is no where near what itcould 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, therewould literally be NO commercial alternatives. e.g. Samba basicallyput Novell out of the networking business. Openocd is not putting folksout of business.
Agreed. There is a lot of work necessary to make OpenOCD reliable let alone the preferred tool. Things have been progressing towards a better code base that allows for component testing, better understanding of code flow, etc. Much of the improvement hasn't been individuals throwing mega-patches to the list and demanding it be committed. Nearly all of the improvements have been discussed, feedback incorporated, and then introduced in small chunks. This serves multiple purposes. First, the person making the changes may not understand the needs of all the users of a given piece of code. By allowing feedback from the community, those users can state their requirements. Further, other experienced developers can point out simple errors, difficult to read sections, missing comments, etc. In the end, the code is better even if it takes a little more time. Second, introducing changes in small chunks helps keep the trunk in a reasonably decent state. It generally configures, compiles, and runs. Taking large changes increases the risk to the project and makes it considerably more difficult for others to review, not to mention the amount of work to bring a large patch up to date if other changes have been made in the meantime. Less review means more risk to the project. Now, some changes are inherently large and indivisible (naming changes or API changes). Everything else should be broken into small, isolated changes.
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 you appear to be settled on forking. Good luck. I wish you well. Please do not use this list to discuss anything related to your fork.
So I do not see any way for me to continue contributing to this project, financially.
Then you must be doing _much_ worse in this economy than every other developer on the project. Further, I cannot see how forking will cost you any less, but that is up to you.
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.)
Actually, every commit includes who originated it. While I acknowledge that you have improved the overall project, the amount of chaos surrounding the patches for each of these fixes was enormous. Process for process sake is stupid, but contending that all process should be ignored so you can develop faster is also stupid.
All in a several weeks, with my hands tied.
Your hands weren't tied, but instead of using the bucket brigade to fill the swimming pool, you wanted to demolish the house to run your firehose through it. The changes requested from you have all been small and require little time to change them. I'm sorry that you find that offensive and expensive, but no one's first pass at something is perfect.
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.
Thank god I'm not being asked to review those. To be fair, I _have_ reviewed 1.8MB patches, but they were naming changes, not functional changes.
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.
Perhaps they haven't realized yet that after taking all those improvements, no one can read/understand the code base. The whole reason process exists for OpenOCD is to ensure that everyone working on the project can understand the changes. Otherwise, they are at risk for being accidentally broken or replaced with something cleaner.
Dick _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
