[Bf-committers] Code cleanup woes

[Thomas Dinges]

Hi,
Although the release cycle is more of a guide and not a strict rule, 
following it more closely would help.

Talking about this, I'd like to see branch merges happen in early BCon2 too.
BCon1 is meant to define targets and that should simply be about 
finished projects, ready to review or already reviewed. In a release 
cycle which is only 8 weeks, branches should not be merged 3 weeks 
before release.  The whole reason for a short release cycle is to get 
branches in asap at the beginning of a cycle, and then have about 5 
weeks time for fixes / user feedback and polishing.

I am also no fan of release postponing due to "my branch is not ready 
yet". If it's not ready, it gets moved to the next cycle.
I'd like to avoid the "Can we still include it" question for the next 
few times please. :)

Regarding the code cleanup:
I agree here that it should also be restricted to the beginning of the 
release cycle only (unless some re-factoring or clean up is explicitly 
planned or needed).

Best regards,
Thomas

Am 26.01.2013 23:16, schrieb 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org