On Tue, 2009-05-12 at 23:24 +0200, Freddie Chopin wrote: > Sorry to interrupt (; I thought that I'd share my "outsider's opinion" > with all.
Not at all. I hope more folks are willing to step up and share their opinions; without feedback, the maintainers cannot know what you think. Thank you for helping to demonstrate how that can be done. > Just a while ago someone (Zach?) was talking about a need for a stable > "production cycle" with frequent release branches. A 0.2.0 release was > mentioned to happen after the recent perforance issues would got fixed > (in fact 0.2.0 was mentioned ~3 times since 0.1.0). The performance is > back (I've checked and it's even a tiny bit faster than 0.1.0 release on > STM32), and the "need for 0.2.0" is gone - there are at least 100 new > ideas instead. This idea that OpenOCD needs regular releases is not "gone", though I do not endorse the idea of forcing them out on a rigid schedule. While Øyvind indicated he thinks it might take a month, I can see a release happening much sooner, if everyone decides that will be our top priority. However, I would rather the community focus on the release process than a single goal like 0.2.0, because I think we need to be producing bi-weekly stable releases. We just need to get our act together, and planning for a single release will not do that. > For an average user - like myself - it is very good to know that "this > version is fine, use it with no fear", but the SVN in the recent weeks > is bathed in chaos (; There is always something going on, so picking up > a right version is pretty much a lottery. Let's say that I have a [...] Average users should not be using SVN trunk. The fact that you are using it shows us that the release process needs to be improved. For developers, the trunk should not be a lottery, but users are playing with different odds. [...] > comfortable situation, because I know how to compile the package, but - > believe me - there are hundreds of "domestic ARM developers" who know > nothing about MinGW, MSYS, autotools and stuff - configuring Eclipse to > handle ARM gcc is pretty much a great achievement for them (I know, 'coz > I've been there just a while ago). Actually there is NO good description > of how to compile OpenOCD for Windows, so it's quite exclusive knowledge. If I have time, I will rectify this by providing some automated scripts to provide a mingw32 build. Mostly, I am tired of breaking that build. > Any chance for a release branch - say - once every 2 months (0.1.0 was > put up around the end of January)? A regular release schedule should be a priority for the community, and the exact details should be determine soon by a consensus process. Stay tuned. > BTW 1 - the SVN revision guessing stuff really doesn't work for me... > BTW 2 - now the compilation process gives TWO openocd.exe files and the > more obvious one (src/openocd.exe) is the wrong one... The right one is > placed in src/.libs/openocd.exe (or sth) - that's pretty confusing. This is a result of libtool support. You should be ignoring everything in the .libs directories and using libtool (e.g. libtool gdb openocd.exe). The sr/openocd.exe is a script that magically makes the rest of the in-tree libraries available to the uninstalled versions. > And to make my mail a bit more positive - OpenOCD is moving (running?) > in a good direction! It's very good that it's moving (running?) forward > with great power. Thanks for the positive feedback! It is good to know that OpenOCD users appreciate all the hard work being done to move things forward. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
