On Saturday 13 June 2009, Zach Welch wrote: > > > Plus, you will motivate me to finish the "import series from e-mail" > > > portions of my patch handling scripts, if you start producing series of > > > patches with a dozen patches each. Or do you think my recent practices > > > have taken this idea too far? > > > > You mean, checking in lots of patches without posting them to the > > list even as an FYI? > > Ouch.
That wasn't meant as a ding; just a "WTF is he talking about?? I've seen no such patch series. Maybe it's <this> ..." > The openocd-svn list provides ongoing notification of the changes. > Posting direct commits here seems redundant to me. Heck, I think that > even the "committed" messages are pedantic for this same reason, but I > do that out of tradition. If you want to know that new patches have > been committed, you can use 'svn log' or subscribe to that mailing list. Hmm, we seem to have a style issue here. I'm one of the many folk who's not interested in getting extra email about commits, and so *never* subscribes to such mailing lists. And that's in part because I'm used to seeing patches circulated before they get committed. So the "committed..." messages are just closing the discuss/review/.../commit loop. They aren't the first public visibility that something's being considered, or done. I suspect that's going to keep tripping me (and others) up with the OpenOCD work, since the model seems to be that folk with commit access will just commit, sans discussion/notice. > I committed these changes directly because they have not included any > apparent functional changes. I'd agree. But: "apparent" is a key word. Most developers have seen many cases where changes crept in that were not-apparent... > There have been very few reports of regressions after two weeks of my > heavy patching, and I imagine that it has not been for lack of looking > on the part of other maintainers and contributors -- if only to call me > out in a similar fashion. The complete lack of community discouragement > has been interpreted as ongoing success and reason to continue unabated. > > Your sentiment is the first to indicate a clearly contrary opinion. No it isn't. It's the first recent remark that there's lots of source code updating that's not visible on the developer list, that's all. > I have a couple of dozen meta-patches prepared to clean up most of the > remaining whitespace and core type issues in the tree. I also would > like to create another series of patches to address the dozens of API > naming issues and other remaining mechanically resolvable problems. I like to see releases go out with cleanup fixes included, so long as it's known they're safe. If there's a release target of "end of this month", those are starting to cut things close... (Reason for *releases* in particular to get late-in-cycle mostly-cosmetic fixups, even if they're biggish changes, is that it's the best time to get them in. Folk who look at the release code, and patch it, have a lot better starting point than they would if such fixes went into the next release cycle. And developers should be chasing/fixing smaller and smaller bugs, so such changes are easier to cope with at that time than they would be later on. Assuming they *are* cosmetic...) > Another valgrind-exposed "fix" to clear all allocated register buffers > negatively affects performance, though I implemented it such that it can > be optimized away for release. I expect all such changes to be resisted > due to its impact on the tree or build, but -- let me be clear -- I > would never commit such patches without the community's consideration. > > Those things deserve review and comments -- not mundane clean-up. While > my recent efforts have started to take out some of the trash, the amount > of work that remains to be done daunts me, and I think literally > hundreds of patches will be required to address all of the issues in the > incremental fashion that I have been taking. I am not exaggerating. Yes, risky changes need more care and attention. Splitting them up into lots of "obviously correct" stages is part of reducing risk. But cleanup also deserves some notice (and for that matter, credit) too. > Altogether, your reply has drained my enthusiasm to continue with this > line of work; I must assume that others share your sentiment but have > not said anything. As you suspected, you're being hypersensitive. That's neither what I said nor what I meant. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
