On Wed, May 21, 2014 at 02:07:14PM -0400 I heard the voice of Stefan Monnier, and lo! it spake thus: > > That's what the Bzr trunk is for: when code has no obvious problems > any more. Once it's tested by enough people to be confident that it > works reliably, then it can be moved to a release!
Oh, sure. It's all shades of grey. I know projects that have a firm rule that trunk always be releasable at any moment, with nothing being permitted to land until it's crossed every i and dotted every t. I sure don't think THAT'S a model we want to run with. And there are others where trunk falls to pieces after a release, spends the first half of the release cycle getting worse and worse, and the second half getting hammered back into workable shape; we sure don't want that either. I recall things got messy (and pretty acrimonious on the list) in the runup to 3.7 a decade back; nobody wants to revisit that. I'm totally on board with landing things in the "we think it's solid" state. And certainly we want to hold back on "it works some of the time, but breaks with X and Y" (at least unless we're prepared to accept and document that). My read of this case (which again, could be totally wrong, in which case this whole thing is ignorable) is that it's in the middle, in the "this seems OK, but also could have broader interactions we haven't fully explored" region. Which on the one hand makes one wish for a little broader exposure before committing to it. On the other, of course, we don't want it to stall out there. That's the sort of reason behind pushing for narrowed platform view and streamlined development, after all. I have no desire to play Gatekeeper Of Trunk; if you and Olaf are confident that whatever surprises it turns up will be easy to handle, gopher it. -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
