On Jan 27, 2012, at 7:58 PM, Martin Lucina wrote: > Hi all, > > as you may have noticed, a new contribution policy for libzmq has been put > in place: http://www.zeromq.org/docs:contributing > > I would like to draw your attention to the following points: > >> The team that manages patches back to libzmq are the "maintainers". >> Maintainers are not developers and they have no opinion on patches; their >> job is to enforce process. > > and > >> The maintainers will aggressively and optimistically merge pull requests >> back to libzmq master, with minimal opinion on quality and relevance. The >> only hard requirement is that the patch can be automatically merged. > > and > >> Anyone who is discontent with a patch will make their own patch to fix >> or reverse the previous patch. Again, maintainers have no opinion on >> this. > > and finally, > >> If you want an analogy for the Maintainer role, think of Wikipedia's >> "Edit this page" function. > > Reading the points above it seems to me that the maintainers have absconded > themselves of any QA role, based on a view of patches to code being > equivalent to literary prose. > > Based on the process above, the role of a maintainer equates to a robot > clicking on "apply this pull request". > > If you look at the quality of commits to libzmq since this policy has been > put in place, from a software engineering point of view the quality of > commits is suboptimal. > > While it is a laudable goal, if you are Wikipedia, to enable anyone to > contribute and rewrite anyone elses prose, libzmq is primarily a *software > engineering* project. The cost of rewriting prose is low compared to the > cost of rewriting code. > > Thoughts? Most of us here are software engineers by trade, surely you can > see where this is leading.
What about the bullet points regarding tests and making sure the existing "make check" passes? There is certainly *some* check to make sure the code doesn't regress. The existing tests won't catch everything, however. There are other threads on the list where we have brought up the issue of unit tests and integration tests, but those conversations generally peter out because the problem is too hard and takes too much time (and time is a precious commodity). What specific suggestions do you have for improving the process? (Demanding that all patches be rigorously inspected and tested by the maintainers is not a reasonable, though specific, suggestion.) cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
