3.0 release planning
justin at shiningsilence.com
Sat Jan 21 10:05:48 PST 2012
On Sat, Jan 21, 2012 at 3:44 AM, John Marino <dragonflybsd at marino.st> wrote:
> A lot of new material was committed since the 2.12 branch. It's not like we
> were in a freeze. So 3.0 is not a relabeled 2.12, and a new set of bugs
> could have been created.
> Plus I think a formal review of the buglist for each release should be part
> of release planning. It forces us at least once every 6 months to really
> review it, and give the users/developers a platform to opine on what really
> needs to be fixed and what can wait.
> Applying back to the releas branch is kind of a pain, and at least two of us
> have made "git" mistakes doing it. Our goal (and I think it's Matt goal
> too) is that the actual release is pretty similar to what's tagged.
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
More information about the Kernel