Xiaofan Chen wrote: > >> Don't let the revert and/or fix hold off an unrelated patchset. > > > > Stop repeating this. > > Actually it is very important to repeat this, especially to you.
The reason it should not be repeated is because it is based on a false assumption, a misunderstanding: I tried to be clear that I do not consider the mpsse driver to be locked to the USB abstraction mess, but maybe you agree with me that the two are not completely unrelated either. That is what I initially wrote, Andreas misunderstood it and suggested that I was locking the issues together, and because I never did that I think it is only fair that I can clarify that the misunderstanding really must not be sustained. > The libusbx fork is exactly because you want something perfect > so that we got no libusb release for two years. I feel that this is quite exaggerated, but I understand that it is convenient to say. Let's focus on going forward in libusb. I'd appreciate if we stay on topic for this list. > 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, but I will fight hard for a reasonable possibility for all contributors to actually spend some time on release engineering. 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. 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. 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! //Peter ------------------------------------------------------------------------------ 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
