On 25 November 2013 21:45, Chris Mason <chris.ma...@fusionio.com> wrote: > Hi everyone, > > I've tagged the current btrfs-progs repo as v3.12. The new idea is that > instead of making the poor distros pull from git, I'll be creating > tagged releases at roughly the same pace as Linus cuts kernels. > > Given the volume of btrfs-progs patches, we should have enough new code > and fixes to justify releases at least as often as the kernel. Of > course, if there are issues that need immediate attention, I'll tag a .y > release (v3.12.1 for example). > > If the progs changes slow down, we might skip a version. But tracking > kernel version numbers makes it easier for me to line up bug reports, > mostly because I already devote a fair number of brain cells to > remembering how old each kernel is. > > Just let me know if there are any questions. > > -chris
Hi Chris, I don't know if there wasn't enough commits to justify a 3.13 release (I noticed your integration branch stalled 7 weeks ago, so I assume this is the case), but can we expect a 3.14 release shortly after Linus tags the mainline kernel as such? If the integration branch stall was for another reason (e.g. testing to make sure it was stable enough for primetime), could I suggest pulling in David Sterba's current unstable integration branch, and essentially freezing it for testing now, so that people/distros can test it against the current/last couple of kernel -rcs, so that any obvious bugs are ironed out before 3.14 is tagged proper. Distros typically put packages like this through their own testing period anyway, so a prolonged testing period shouldn't be required upstream. Thanks for your continued hard work, WorMzy Tykashi (sorry if you receive this twice gmail went wrong) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
