on Tue Oct 04 2011, Gennadiy Rozental <rogeeff-AT-gmail.com> wrote:
Dave Abrahams <dave <at> boostpro.com> writes:
It is. But as you've seen over the years, it causes an unworkable amount of upset and alarm when large numbers of failures appear on the trunk all at once, and people who would otherwise be dealing with release issues now have trunk issues to worry about.
That's why I always advocated independent library development.
We all (well, many of us) want that. We're not there yet.
Sometimes I do break trunk due to missed commit or compiler differences, but these quickly resolved. I need some way to make sure my changes are working.
But that can't have been the case here, can it? Surely if you'd run the whole boost regression suite on your local machine before and after your changes, you'd have seen the differences, no?
No, I can't. I have limited time I can spend working on boost development. I cannot wait hours for full regression test to finish even once, not mention twice. I expect regression test system to deal with this. I resolving issues once I observe them online.
So you do have a philosophical disagreement with the expectations of the group. You think you ought to be able to use that development model, but everyone else expects library authors with boost dependents to test the dependents before they commit changes. So every time you do this and things break on trunk, it causes a big kerfuffle. At this point, the magnitude of the actual inconvenience to others is irrelevant; they're going to be upset because they've been through this with you over and over. Do you really think that after 5 years of waiting to remove this facility, kicking off a boost-wide test and looking for problems would have cost you more time than it's costing you to deal with all this fallout from the problems you've caused?
I do run my own regression tests and they pass.
The fact is that your (Boost) customers aren't happy when you develop this way. If you won't change your development model and your customers won't change their expectations, the only solution for them is to stop using Boost.Test... which I did long ago, for this very reason. -- Dave Abrahams BoostPro Computing http://www.boostpro.com