Merry X-Mas and 3.0 release after the holidays - date not yet decided

[B. Estrade]

Long time lurker and fan here, but it's been my impression that from
the start, DragonFlyBSD has been the "scalable" BSD.  Today's climate
of "more cores" rather than "more GHz" makes DragonFlyBSD's SMP
capabilities exceptionally relevant. If Matt didn't start this project
when he did, BSD would have literally be found with it's pants down
during the current many-core era. And there's no end in sight. So I
reject the notion that this isn't "significant".

I have no opinion on "3.0" vs "2.x" because it doesn't make the
progress any less significant.  You could version it "Fred", and it'd
be OKAY with me.

Thank you,
Brett

On Sun, Dec 25, 2011 at 8:13 PM, Samuel J. Greear <sjg at evilcode.net> wrote:
>
>
> On Sun, Dec 25, 2011 at 4:01 PM, Matthew Dillon
> <dillon at apollo.backplane.com> wrote:
>>
>>    (2) I would like to call the release 3.0.  Why?  Because while
>>        spending the last ~1-2 months tracking down the cpu bug a whole lot
>>        of other work has gone into the kernel including major network
>>        protocol stack work and major SMP work.  My contribution to the SMP
>>        work was to completely rewrite the 64-bit pmap, VM object handling
>>        code, and VM fault handling code, as well as some other stuff.
>>
>>        This has resulted in a phenominal improvement in concurrency and
>>        in particular concurrent compilations or anything that takes a lot
>>        of page faults.  SMP contention was completely removed from the
>>        page fault path and for most VM related operations, and almost
>>        completely removed from the exec*() path.
>>
>>        Other related work has continued to improve mysql and postgresql
>>        numbers as well.
>
>
> I am opposed to calling the next release 3.0. We have limited precedent to
> go by, having only really rolled over to one real .0 during DragonFly's
> life, but I think making the next release 3.0 would violate the precedent
> already established and begin a downhill trend going forward. 2.0 was
> released to coincide with HAMMER, which is the single de-facto
> most recognizable and largest user-facing feature and draw of DragonFly. We
> may not be able to drop a HAMMER-sized feature with every .0 release, but I
> think the precedent that 2.0 set was that .0 releases are reserved for major
> user-facing feature enhancements. While SMP performance has been improved
> dramatically recently I do not see that as a user-facing feature, in fact I
> would argue that a lack of proper MP support and performance should nowadays
> be considered a bug or serious design flaw. FreeBSD's reputation seems to
> have shifted from being the "performance" BSD to the "corporate-friendly"
> BSD. NetBSD is still the "portable" BSD and OpenBSD is still the "secure"
> BSD. It is my distinct impression that DragonFly is emerging as the
> "innovative" BSD, which I believe fits the spirit of the community and the
> release process to date. I believe reserving 3.0 for a feature-filled
> release would continue to foster this image and making the next release be
> 3.0 would run the distinct risk of our release numbers being seen as
> arbitrary rather than meaningful. I also think that this is a very slippery
> slope, unless there are well-defined criteria for a major version bump many
> will argue for a major version bump because of perceived (real or not)
> marketing benefits. I believe that making the next release of DragonFly BSD
> be 3.0 will result in these people arguing for 4.0 earlier in the next cycle
> and then 5.0 even earlier in the following cycle. A couple of cycles later
> we will find ourselves in FreeBSD's position of bumping the major version
> every year. The legacy of the project and how this will impact the next ten
> years of releases should be considered before arbitrarily calling the next
> release 3.0.
>
> Sam