On Mon, 2009-07-06 at 15:16 +0200, Øyvind Harboe wrote: > I've determined that single stepping is busted for > svn head arm926ejs using parport against wi-9c.cfg > (bisecting this now).
This does not meet my standard for "explaining" the changes that went into the OpenOCD tree, in so far as I still need additional confidence that your changes were correct. The above only clarifies that they were well intentioned. Your commit messages and posts need significantly more details. I am not expressing this sentiment for my own sake. Your lack of explanation translates directly in to development opacity for the users, as your commit messages will appear in the published ChangeLog files. Brevity is not user-friendly in these areas. It is not even good to assume that other developers will grok your changes, or that your changes will be correct on all host platforms or targets. > One concern that I have with 0.2 is that it contains a lot > of *great* refactoring work, but this is unobservable to > the casual user. This is one price of progress, but releases will help with this. > It will take a *long* time get testing done for all types > of targets. Testing really has to be done on svn head anyway... *sigh* These comments have caused me to write up testing processes that are not entirely unlike the release processes in the scope. I am providing the same sort of analysis (why, who, what, how, when), in order to set down some understanding about what "testing" should mean. In the face of those broader definitions, I disagree with your claims. Your definition of that word seems far too narrow, but we can settle this debate in a separate when I post that new file. :) > >From this point of view 0.1 is much better because there > was a lot less development going on prior to 0.1 release... > > What about cutting a 0.2 branch now(going back a few svn > versions if necessary) and leaving arm926ejs for 0.3? No. That creates more work for the release manager (me), because there are other fixes that have gone in on top of your changes. I will not be doing extra make-work like this in an unpaid capacity, and I would rather see others spend their time improving the trunk and producing more releases. Until your recent patches, the trunk was ready to be branched and tagged without such extra labor, and I am somewhat unhappy that the release needs to been postponed for more testing. I am more disappointed that you avoided explaining the patches directly, which takes more individual responsibility for the situation than your present suggestions and continued actions seem to demonstrate to me personally. Rather, than waiting for clarification from the Release Manager, you plunged ahead. It's great that you found these bugs and want to fix them, but your patches should not be committed without sufficient explanation and community review. You have been committing directly during the preparations for the 0.2.0 release, which I see as a serious failure in our process. However, this characterization as "failure" reflects my hope for the future, rather than expectations from my experiences here. Since things have been more flexible in the past, these events should more fairly be called a "learning experience" for all involved. ;) So, we need to move forward. After we are done with testing, I think we should release 0.2.0 and plan to release 0.3.0 in the middle of August. This will allow for a few weeks of development and a week of testing, more or less. That may seem like a fast cycle, but it seems like a good compromise in the face of skipping bug-fix releases for 0.2.0. I would see us schedule 0.4.0 in the same fashion, but I may want to change things for 0.5.0 or beyond. Two or three more releases should allow enough time for many major clean-ups and improvements that have planned to be implemented (e.g. libopenocd, modules, etc.). After 0.5.0, the pace of change may slow unless more innovation makes its way onto the list. Hopefully, we will be coping with a large influx of developers writing support for new targets, and we will have the resources to be producing both -rc and bug-fix releases. > Perhaps we can backport a few things from svn head? Again, I do not think we should spend any of our time doing release branch maintenance at this point. There is too much work remaining in the code for the project's resources to be diluted in that way, when we should simply be releasing more often and getting more testing feedback. I think we need more active contributors and users to be able to sustain release branches. Until then, the community should focus on each release in unison. We should all stop development and work to test the pending release, post patches to fix bugs, review those fixes, and apply only changes that work everywhere for everyone -- without regressions or other new bugs to clean up (functional, stylistic, or otherwise). Right now, we are seeing that this process needs work in the trunk, as these steps are not being used in critical cases. The idea of trying to manage multiple branches in these conditions frightens and confuses me. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
