Sure, but this means we need a “test if I broke everything” infrastructure in addition to next. Either running nightly or “continuous integration”
Maybe we should start designing a “continuous integration” capability right now. Barry On Oct 2, 2014, at 10:58 AM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> writes: > >> On Oct 2, 2014, at 9:44 AM, Jed Brown <[email protected]> wrote: >> >>> Barry Smith <[email protected]> writes: >>>> Yup. Jed is saying our histories should be terrible. >>> >>> ;-) >>> >>> There is a balancing act between "quality" of long-term history, utility >>> of near-term history, and development effort/opportunity for mistakes. >>> I personally think the sweet spot is to prefer not to rebase that which >>> has been merged to 'next’. >> >> But this is just a fluke of our testing approach. If I had 15 >> machines I could test all myself and not put major broken things >> into next. > > The unique thing that 'next' enables, but continuous integration cannot, > is having external users actually use the features. > > If your view is that the test suite is a complete and unambiguous > specification for correct execution, then passing the test suite by > definition means that a feature is bug-free. But if you view the test > suite as a proxy for "does consistent and useful things in user > applications", the test suite will never be perfect. Merging to 'next' > allows "eager" users (including developers working with applications) to > experiment and give feedback.
