Re: [Openocd-development] 0.2.0 release... on hold?
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 8 juli 2009 0:35 To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] 0.2.0 release... on hold? On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote: We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. I definitely want to see a reset of the release timeout counter when we discover such problems as we have seen in the last week. The step bug alone would have made *all* the regression test scripts fail... I wouldn't even want to ask Michael Fischer to run the regression test suite without that one in place... Right, so I do want to make it clear that some of these are entirely legitimate bugs that you are fixing. No dispute about that. In that regard, I am happy to reset the release deadline while we consider the patches. However, there does need to be a limit to the number of resets that we allow for new issues. If I may be very blunt: I don't think we are very close to a 0.2.0 release. It seems (based on bug reports) the recent changes broke some of the existing functionality. That needs to be tested fixed first. IMHO release 0.2.0 should have at least the same functionality that 0.1.0 had. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
If I may be very blunt: I don't think we are very close to a 0.2.0 release. It seems (based on bug reports) the recent changes broke some of the existing functionality. That needs to be tested fixed first. IMHO release 0.2.0 should have at least the same functionality that 0.1.0 had. Regressions are at the very top of the list of reasons to postpone 0.2.0. Please report outstanding issues you find to the list. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
On Wed, 2009-07-08 at 12:06 +0200, Nico Coesel wrote: -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 8 juli 2009 0:35 To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] 0.2.0 release... on hold? On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote: We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. I definitely want to see a reset of the release timeout counter when we discover such problems as we have seen in the last week. The step bug alone would have made *all* the regression test scripts fail... I wouldn't even want to ask Michael Fischer to run the regression test suite without that one in place... Right, so I do want to make it clear that some of these are entirely legitimate bugs that you are fixing. No dispute about that. In that regard, I am happy to reset the release deadline while we consider the patches. However, there does need to be a limit to the number of resets that we allow for new issues. If I may be very blunt: I don't think we are very close to a 0.2.0 release. It seems (based on bug reports) the recent changes broke some of the existing functionality. That needs to be tested fixed first. I think that we need to fix the bugs that we have spotted, but each release window has its limits. The 7/1 deadline had been discussed in on the list more than once, and I am fairly certain that I gave ample warning to the community in the past week or so. The late rush and subsequent delays are simultaneously expected and disappointing. IMHO release 0.2.0 should have at least the same functionality that 0.1.0 had. This kind of expectation does not hold indefinitely, as not even the Linux kernel maintains support for all platforms indefinitely. I bet every minor release sees a regressions in a small part of the tree. Given that OpenOCD shares the same hardware testing requirements, I think it would be insane to expect that we never have regressions for some platforms. Moreover, some of the reset bugs being discussed appear to have been introduced before the 0.1.0 release. We can't wait for everyone that missed the release window, when others get their work in on time. That is simply not fair to the maintainers that are keeping up with the schedule. This is why the world has deadlines, and there will always be consequences for missing them. Fortunately, we can make new releases in due course, so any mistakes will be corrected with sufficient patience from the community. All of this is for the future. For now, we're playing things by ear, and it sounds like we need to give 0.2.0 a little more time to brew. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
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
Re: [Openocd-development] 0.2.0 release... on hold?
Hi Zach, thanks for a good post followup on this. I'll try to adjust to the new rules of engagement and stop committing willy nilly. W.r.t. when 0.2 should go out of the door, I'm thinking that we should have a few days without finding and fixing regressions before we say it's time to release. Here is a list of recent commits I've made where the impact is non-localized to obscure features and non-trivial. Some additional explanations too. 2464 - fixed regression since 0.1. No human readable error message were reported when feeding in an illegal number. 2469 - deleted unclear unused code. There was a complicated check on what the debug_reason was. The new check *only* checks against the only value/case that needs to be treated specially. This was a bug waiting to happen. If a new DBG_REASON was introduced, then this check would do the wrong thing. related to arm926ejs work. 2470 - added a timeout check on the polling loop for cp15 read/write. This was for arm926ejs work, but the timeout problem is no longer visible as the underlying interface problem was fixed. 2478 - fix post 0.1 regression in OpenOCD step command. This command is *crucial* for the trunk/testing scripts. 2479 - arm926ejs reports unknown MOE. Rather than just failing outright, allow step/halt to at least function while we look for this bug. My current feeling about 0.2 is that we should allow at least a week of work on the outstanding reset problems before we cut the release. Also I'm especially pleased that we caught 2478 before anything went out of the door, because *ALL* smoke tests would have failed without that fix in place... Based on the experience in the last couple of days w/the reset problems, I'm not quite ready to hand over svn head to Michael Fischer for running the smoketest suite. 0.2 is special. There has been LOTS of system wide changes this spring. Is there a downside to staying in near 0.2 release mode for a month or so? What type of changes would we have to postpone? Surely we could do more system wide cleanup work this fall? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
On Tuesday 07 July 2009, Øyvind Harboe wrote: My current feeling about 0.2 is that we should allow at least a week of work on the outstanding reset problems before we cut the release. That seems reasonable. Likewise some of the issues turning up with different JTAG adapters. It's funny how folk tend to really start testing heavily once it seems the release is likely to happen in the next day or two. ;) During that week ... should there be a policy on commits, with explicit ACKs/NAKs required? Commits can go in after the 0.2.0 tarball ships, of course; temporary delays only. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
On Tue, Jul 7, 2009 at 11:02 PM, David Brownelldavi...@pacbell.net wrote: On Tuesday 07 July 2009, Ųyvind Harboe wrote: My current feeling about 0.2 is that we should allow at least a week of work on the outstanding reset problems before we cut the release. That seems reasonable. Likewise some of the issues turning up with different JTAG adapters. It's funny how folk tend to really start testing heavily once it seems the release is likely to happen in the next day or two. ;) Very human behavior. We create a sense of urgency to get my problem fix before release... Perhaps we should capitalize on this and create a rule that exploits it? Create a release timeout counter which is reset upon acknowledged regressions reported? During that week ... should there be a policy on commits, with explicit ACKs/NAKs required? Commits can go in after the 0.2.0 tarball ships, of course; temporary delays only. What about cutting the release and waiting a week to see if anything of note appears? Upon resetting the release timeout counter, we cut a new release. The release will be of some well defined subversion # in the past. Cutting a release is *cheap* right? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
On Tue, 2009-07-07 at 14:02 -0700, David Brownell wrote: On Tuesday 07 July 2009, Øyvind Harboe wrote: My current feeling about 0.2 is that we should allow at least a week of work on the outstanding reset problems before we cut the release. That seems reasonable. Likewise some of the issues turning up with different JTAG adapters. This seems like a slippery slope to me. One week could easily turn into two, then another week after that, and so on. We said that we would release on 7/1, and we are now a week late. Another week makes us two weeks late. Speaking as release manager, I find this unacceptable from the perspective of users' expectations. We have talked about that deadline for a while, and we need to stick by it unless these problems are truly insurmountable. I believe there are workarounds for all bugs being discussed, so -- while it would be great to have fixes -- they do not seem like reasons to block the release for much longer. It's funny how folk tend to really start testing heavily once it seems the release is likely to happen in the next day or two. ;) Tell me about it. I am happy to see it happening, but seeing patches rejected should cause things to be different for the next release. During that week ... should there be a policy on commits, with explicit ACKs/NAKs required? Commits can go in after the 0.2.0 tarball ships, of course; temporary delays only. Right. I am happy with direct trunk commits during the normal development process -- just not during the release process. Explicit ACK/NACK is probably the best policy, particularly if everyone know that such will be required for progress. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
What about cutting the release and waiting a week to see if something worthwhile appears that makes you want to cut the release from a newer svn version? Allowing commits meanwhile, but encouraging postponements of more crazy stuff + commits for collaboration purposes. Cutting the release from an arbitrary svn # is cheap, right? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
On Tue, 2009-07-07 at 23:46 +0200, Øyvind Harboe wrote: On Tue, Jul 7, 2009 at 11:02 PM, David Brownelldavi...@pacbell.net wrote: On Tuesday 07 July 2009, Ųyvind Harboe wrote: [snip] Create a release timeout counter which is reset upon acknowledged regressions reported? We might not release until X-mas. During that week ... should there be a policy on commits, with explicit ACKs/NAKs required? Commits can go in after the 0.2.0 tarball ships, of course; temporary delays only. What about cutting the release and waiting a week to see if anything of note appears? There needs to be testing of all changes in trunk. That takes a week without significant changes, at our current level of activity. Upon resetting the release timeout counter, we cut a new release. The release will be of some well defined subversion # in the past. Cutting a release is *cheap* right? Yes, but there is some cost in having N versions in the field. Sure, we could release after each commit, and we would see few bug reports for any given release. Users have no idea which one is good. This be bad. In contrast, we have been working towards the 0.2.0 release for months. We need a release off which users can perform testing and spot regressions from 0.1.0 (or earlier). Right now, we still require bug reports from SVN, and that will end with 0.2.0 (and sooner is better). Once we fix enough bugs we can consider releasing 0.3.0, which will include some additional development. We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. I definitely want to see a reset of the release timeout counter when we discover such problems as we have seen in the last week. The step bug alone would have made *all* the regression test scripts fail... I wouldn't even want to ask Michael Fischer to run the regression test suite without that one in place... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
On Wed, 2009-07-08 at 00:14 +0200, Øyvind Harboe wrote: We need to find some balance. Right now, the presses are too heavily biased toward development to the extent that release suffers badly. I definitely want to see a reset of the release timeout counter when we discover such problems as we have seen in the last week. The step bug alone would have made *all* the regression test scripts fail... I wouldn't even want to ask Michael Fischer to run the regression test suite without that one in place... Right, so I do want to make it clear that some of these are entirely legitimate bugs that you are fixing. No dispute about that. In that regard, I am happy to reset the release deadline while we consider the patches. However, there does need to be a limit to the number of resets that we allow for new issues. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
However, there does need to be a limit to the number of resets that we allow for new issues. Agreed. Though I believe that it is a hypothetical situation where we discover major flaws every few days. *If* we did, then we *should* hold off the release. Have we discovered anything but the reset problems lately? (Dominic hasn't reported back on his next test run yet...) -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] 0.2.0 release... on hold?
Hi all, With my latest series of commits, I believe that the release process is finally ready to see action. That said, we have seen a bit of bug-fixing activity during the time that I have been preparing, and several new patches have hit the repository. The countdown is on hold. The new changes for arm7_9_common.c and arm926ejc.c need to be given time to ensure they work on all targets being tested for the release. Honestly, I am tempted to ask for them to reverted for the time being, as I cannot trivially determine their correctness after casual review. Of course, these were not given time for review in the first place; given the pending release, this was a major faux pas and cannot escape mention as such. :/ Since it appears that they do not help the ARM926EJS problems that were reported after the commits, perhaps reverting them may be the best path If not, I want to understand why we should keep them for 0.2.0. Again, such explanations should have been provided with the e-mail descriptions or commit message. I hate to make an example out of these changes, but I want the community to handle these issues better in the future. What do others think about these changes? Are they safe to keep, or should we revert them to make the release? If we keep them without confirmation, I want to wait until the community provides feedback confirming that nothing has broken. In this respect, I think the release process deserves to be put on hold, until the changes are reverted or have been explained fully and confirmed to be correct. Personally, I would prefer to hear confirmation that they are good. Other than those changes, fixes for MinGW32 cross-compiling are pending to be committed, but I cannot think of any other issues that have a solution waiting to be tested. Maintainers: please commit ONLY patches that have been reviewed by the mailing list for at least 12 hours. These should be confirmed by others that the changes fix problems (or have benefit) for the community. If feedback to this thread indicates that we are ready, I will produce the 0.2.0 release about 12 hours after the last patches are committed. Each new patch that is committed will reset the release clock. Does this sound reasonable to everyone? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 release... on hold?
I've determined that single stepping is busted for svn head arm926ejs using parport against wi-9c.cfg (bisecting this now). 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. It will take a *long* time get testing done for all types of targets. Testing really has to be done on svn head anyway... 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? Perhaps we can backport a few things from svn head? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
