3.0 release planning

Justin Sherrill 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
intractable.





More information about the Kernel mailing list