[Bf-committers] Code cleanup woes

[Nicholas Bishop]

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 <sswaney at centurytel.net> 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers