On Wed, May 9, 2012 at 2:01 PM, Peter Stuge <[email protected]> wrote: > Xiaofan Chen wrote: >> Do not try to hold off OpenOCD release with your idea of a >> "perfect" release. > > There is very little perfect software in the world. I do however > think that it's reasonable to require every release be clearly > better than the previous one. Number of commits does not measure > quality. > > Releasing for the sake of releasing is at best silly waste of time > and at worst directly harmful for the project. Of course never > releasing at all is also harmful, but that's not really a risk for > OpenOCD since there was a release in August. > > I do not disagree that now is a good time for an OpenOCD release,
Great! > but I will fight hard for a reasonable possibility for all > contributors to actually spend some time on release engineering. Good. > Several extremely competent engineers for whom I have a lot of > respect have independently told me about the absolute debacle that > is the OpenOCD user experience. > > One person, with a very strong standing in the free and open source > software community, mentioned that he has a need for OpenOCD every > so often, and *every time* he comes back to use it something has > broken and something else works different from the way it did last > time, for no apparent reason. > > The only way this can really improve is if we actually attempt to > be perfect at *something*. Of course OpenOCD will never be perfect > everywhere, but maybe, just maybe, *some* part of the software > can become perfect. (Some are possibly perfect already.) > > And maybe, just maybe, there can be one more part like that in the > next release than there was in the previous one. Or at least a part > of a part, like what I want for SWD. I think SWD can wait since it is not ready. But if there are some parts can be integrated and the integration does not interfere with other part and not delay too much the delay, I think it is fine. > But when commits are merged after many hours of review while issues > remain unfixed, or when reviewers are simply scarce, then four days > of release engineering is a sure fire way to continue down the path > of less than perfect. I agree with you 4 days are too short. > Four days of getting new commits into gerrit and four weeks of > reviewing and reworking them is not a balance and it does nothing > but encourage MORE crappy commits in gerrit which waste MORE time > for reviewers - the exact opposite of why gerrit is helpful! > I do agree with you here that four days are too short for getting new commits into gerrit. I think maybe two weeks time are good. If part of SWD needs to be in, maybe one month? If you can clean up the libusb-1.0 codes within one month, that would be wonderful. What is your opinion in terms of the time frame now that you agree it is a good time to release? -- Xiaofan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
