This is a nice reason to stick with a well-defined and relatively short release cycle. Code cleanups should not at all be forbidden, but they should happen with other potentially destabilizing changes (like branch merges) early in the cycle. The remainder of the release cycle should then be focused solely on bug fixes.
Keeping to a consistent and short release schedule helps with this. Devs get frustrated if they have to maintain code outside of trunk for too long and start pushing to commit it (just one more change, just add one more week to the schedule...), but this doesn't happen so much if they know for sure that the next merge window will open up in e.g. four weeks. -Nicholas On Sat, Jan 26, 2013 at 5:00 PM, Stephen Swaney <[email protected]> wrote: > On Sat, Jan 26, 2013 at 03:02:17PM -0600, Jason Wilkins wrote: > >> I think this would not have broken if MEM_reallocN was exactly like >> the standard library realloc. The slight differences probably mislead >> whoever was making this change. > > Pretty much the point Ton and Joel were making as to why you don't do > stuff like this on an ad hoc basis. > > S. > -- > Stephen Swaney > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
