Hi all, Here is my summary of what I think needs to be done to prepare for a "source-only" 0.2.0 release, which will help promote OpenOCD and maybe attract new developers that can help fix the binary distribution issue. Solutions for that problem can manifest themselves and be used with this release, or another in the near future; in fact, they will be better if they work with such a release archive, rather than a SVN snapshot.
With that, we can turn to the means of ensuring OpenOCD is adopted by the most common Linux distribution mechanisms: package managers. For each of the various Linux distributions, we need one or more "Packagers" to maintain the required scripts or meta-data to produce compatible binary packages. Several are already known on this list, and they should chime into this thread too. The community needs a fair-sized herd of such individuals to support all common distributions and release variants, but several of the big ones have been covered by individuals here. For derivative distributions, most of the work can be shared and re-used, and the devil will be in the details. As the recent Ubuntu build threads have demonstrated, not even successive releases of the same distribution may build the same way. Thus, users on Linux must be treated just as on windows: they cannot be expected to compile the code themselves. However, Linux distributions usually make packaging and distributing GPL-compliant binaries easier, and most distributions provide source-only packages for situations such as the ftd2xx driver (and some even have build kit tools). If your distribution lacks a native package (and you cannot create one yourself), please contact their mailing lists to try to recruit someone to help you create one. I think we could produce the 0.2.0 release within a week -- and the 0.2.1 the week after, if something turns out to have gone horribly wrong. Anyone that wants to help us prepare packages for the 0.2.0 release should get involved as soon as possible. I would like to see broader adoption by distributions, but I know that also means we need to be producing releases regularly. By doing so, those packagers stay interested in participating with the process and ensuring the releases deliver value for their users (without patches). This should help to create healthy positive feedback cycles with those communities, as we should help make them and their users happy by fixing bugs that affect their platforms. The point is that only _developers_ that want to contribute (or users running a fringe distribution) should need to compile the code for themselves. If you have building problems that the community cannot resolve for you, then you may need to take the time (outside of this community) to improve your development skills to fix it on your own, pay someone to fix it, or perhaps try alternate commerce (e.g. barter). Volunteer maintainers should not be expected to teach users how to fix every bug they encounter, much less do the work themselves to resolve the problems. They have their own issues. Users should not even _expect_ answers to any support question here, though you will usually find someone will answer, teach, of fix most of them for free. Nothing is 100% though. Such is the life of users that can get this program for free and use it with substantial freedom.** To be fair, there is the other side to this story. Without regular releases, users will probably never see "stable" packages distributed for their OS in the manner that I have described. Today, such users are virtually forced into building from SVN (which is not attractive to packagers or to distributions), so the maintainers are ultimately responsible for resolving the same build problems over and over again. When we improve the release process, these problems should disappear. At that point, more build questions may be ignored for the reasons given above. However, these questions should begin to be directed away from this community and toward the bug tracking software of the distribution on which the user installed the package. After all, building is highly distribution-dependent; you should be asking their experts, not ours, when trying to resolve these sorts of problems. So again, we need to forget about the binary distribution problems in the OpenOCD development community for the time being. These issues will all be resolved externally or in future releases. This reason alone justifies lowering their priority to allow the release to go forward, because it does not change the impact for users. In fact, it will only aid in the process of finding resources to fix our outstanding problems. Cheers, Zach Welch Corvallis, OR ** - If you received OpenOCD with hardware and you do not get support here, then e-mail your hardware vendors! They cannot say we are required to support you here, and they should not be allowed to claim that we should be your only OpenOCD support resource if you bought their products. However, they are not responsible for teaching anyone how to build or package the code either; they have limited resources as well. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
