3.0 release planning
dragonflybsd at marino.st
Sat Jan 21 10:34:03 PST 2012
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
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.
More information about the Kernel