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
