On Mon, Feb 6, 2012 at 5:15 AM, Staffan Gimåker <[email protected]> wrote:
> We want to avoid relying on features that will never make it upstream as > much as possible, so a work flow as outlined below makes more sense to > me personally. > > * Propose a change upstream, either as an idea or a patch. > * Hopefully get it reviewed and accepted. > * Start using it internally, maintain it until it's available in an > upstream release. > > If there was a "staging" repo where things got discussed and reviewed > first, then accepted, and eventually merged to master, with any changes > in it having a higher chance of survival, it's a work flow I'd consider. Indeed. This makes much sense. I've previously argued for using multiple repos for such separation but consensus was to use branches in one repo. Thus, the master branch is a staging area, and we then merge surviving (tested, proven) changes onto version branches. The main problem with relying on a review process is that, by experience, it rarely happens. We've proof of that over the last years as Martin Sustrik has diligently sent patches to this list, yet they are rarely reviewed. At the same time, downstreaming such "trusted" patches to 2.1 stable has on more than one occasion created broken releases. And the notion that some team has the right to "accept" or "reject" patches is bogus in an open source community. Who elects these group? Why are they special? What if they never actually use 0MQ themselves, how then do they judge the economics of a change? In fact the only people who can judge the pros and cons of a feature are real users. And they can't do this by review, they have to be able to use the code. My conclusion, from observing our work over years, is that only real use can validate patches, and this will take time, often many iterations as patches zoom in on the right solution. One cannot demand every contributor to immediately produce perfect solutions. It creates an insurmountable barrier. Thus, the goal of getting changes into use rapidly, via a "this is experimental" area. And the least surprising place is libzmq master. I'm writing a detailed analysis and explanation of the history of our current processes, which should allow an empirical approach to our work. Opinions don't have much value, they are by definition biased. We need quantitative measures that can be tracked over time. This is what I'd like to capture. As for feature creep, we have the tools to manage that. They are the documented APIs and protocols. These are contracts that cannot be broken. They may be extended but anything that people do not use can be removed (and is, over time). _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
