On Thu, 2009-07-09 at 09:56 +0800, Xiaofan Chen wrote: > On Thu, Jul 9, 2009 at 1:24 AM, David Brownell<davi...@pacbell.net> wrote: > > On Wednesday 08 July 2009, Zach Welch wrote: > >> The files in this series are meant for review, so feedback may be > >> incorporated in them before I commit them. > >> > >> 1/5 Add comments to top-level files to "excuse" their Doxygen markup. > >> 2/5 Add microscopic style guide at the end of the PATCH primer. > >> 3/5 Add section to provide some documentation for cross-compiling. > >> 4/5 Add style rule to avoid combining assignment and logical tests. > >> 5/5 Document Maintainers and Testing. > > > > I'll ACK #s 1-4. > > > > #5 seems like two significant patches combined into one, > > and they seem like they each need more review ... > > If I were a maintainer (luckily or unluckily I am not), I would be a bit > scared by the harsh/strict words in the Maintainers document considering > the fact that all the maintainers and active contributors spend their > free time to do free development...
Volunteers in most communities are expected to behave professionally, as evidenced by medical or early educational volunteer positions. If you do not perform according to expectations, you do not get to retain the privilege of even a volunteer position. That may sound harsh, but it derives from high standards. In this way, we need these guidelines to define the roles of key contributors, as performance standards can only be enforced from the top down. The reality about the harsh language is this: I hope it never needs to be used. However, you should read this as a social contract: governance of the project is in the maintainers hands, and this document spells out their responsibilities -- which allows users to hold us accountable. Without such language, there will be only continued chaos, which has led to valued contributors leaving the project and threats to fork the code. If the rules seem too harsh, then you are not ready to be a maintainer. This may itself sound harsh, but I hear the world is unfair too. These are drafts documents, however; I want to incorporate feedback like yours until the community agrees that the guidelines seem fair. The language may need to be revised for any number of reasons; however, these kinds of guidelines exist in any project that reaches a certain critical mass. With these guidelines in place and agreed upon, the community should be able resolve disputes regarding maintainer authority, responsibility, and accountability in the project. Personally, I have no problem being held accountable for the responsibilities that I have been doing here, so long as I had the required authority to complete the work. Speaking in the capacity of an unpaid volunteer, I will not continue to volunteer my time on a project that has been filled with volatility, most of which appear to be caused by power struggles over issues that could have been resolved if proper management had been in place. Wither paid or not, these are signs of a poorly governed project. These guidelines seek to put an end to such shenanigans, before the constant turmoil drives all of the quality contributors to create a fork where this chaos will never be allowed to blossom in the first place. > As for the test document part, I feel this sentence is a bit strange. > "Users should never be asked to test the SVN.". Maybe this sentence > itself is correct. But users will have to test the SVN after all since > OpenOCD has not reached 1.0 stage and many bug fixes will have to > be tested in SVN. There is an important point to make to start: the labels "user" and "developer" are disgustingly black-and-white for open source software. Our reality tends to be full of gray; however, I think it is clearly a bad policy to ask "users" -- those who are not developers -- to use the "developer" SVN repository. We should be producing releases frequently enough that "users" can wait for the next release. If you _can_ build the repository, then you are not really a "user" in this scenario. I do _not_ want "users" trying to _build_ the SVN repository. Asking the users to test the SVN is asking them to do everything that a developer must do. That is an unacceptable process for users, as it will result in more false reports from failed (re)building than it will help test the bug. Instead, they should wait for a source archive release, which will not require them to use the autotools bootstrap. If we need "users" to test more often than releases, we can produce nightly tarballs. They should _not_ use SVN. Our processes have failed if we must ask them to do so. In other words, the costs of "users" trying to use SVN will far outweigh the benefits , when nightly tarballs would solve the problem. Further, most "users" will probably be running binaries provided by others, and those individuals should be reporting bugs to their distributor -- not the open source community. Those individuals _can_ test SVN. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
