Re: 3.0 release planning

[John Marino <dragonflybsd@xxxxxxxxx>]

On 1/21/2012 7:05 PM, Justin Sherrill wrote:
> Is it really so much trouble to have a tag, then test against that
> tagged version, that it is better to tag and release all at once
> instead?  I like having something specific to test against, that we
> know is the target, especially after being almost nearly about to
> release for the last 6 months.
>

> I can appreciate a code review and that there could be a whole new
> slew of bugs, but tagging something shouldn't interfere with any of
> that.  I tagged 2.12 and it would have been releasable as 2.12.1 very
> quickly if that wierd probably-an-AMD-CPU-bug hadn't been so
> intractable.
>

Yes, it's double-work if you branch (I assume this is what you mean by 
tag) and there's several must-fix bugs in there that now have to be 
fixed in the trunk and the branch.  There is a "plus" to tagging and 
fixing later though: The trunk isn't locked into a freeze while the bugs 
are being fixed.

Honestly the "must-fix" list/review probably needs to come at least 3 
weeks before the desired branch point.  There is also a class of bugs 
that are "nice to fix" that had a spotlight been shown on it before the 
branch, it would be probably be fixed for the release but its not so 
critical that it would hold up a release.  That's where the "3 weeks" 
number comes in.

My own inference by reading IRC is that a release will occur pretty 
quickly after a branch so I'm asking the question: Have we really 
adequate reviewed the bug list?  I'm getting the feeling we're suffering 
from releasitis due to skipping the last one.  At the very least we 
should be reviewing all the reports that have come in since the 2_12 branch.

John