Date: Wed, 8 Feb 2012 23:09:20 -0800 From: mdf@FreeBSD.org To: John Kozubik <john@kozubik.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Moving on ... (was: Re: FreeBSD has serious problems with...) Message-ID: <CAMBSHm9tsHAy%2BWPCzTkhk_Z2h%2Bw83LvuOM%2BxPmu%2B%2B4_n--y-6w@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1202082202530.19710@kozubik.com> References: <20120119005658.218280@gmx.com> <alpine.BSF.2.00.1201191511470.19710@kozubik.com> <4F19188A.4090907@herveybayaustralia.com.au> <4F213CEB.4020207@herveybayaustralia.com.au> <alpine.BSF.2.00.1202082202530.19710@kozubik.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 8, 2012 at 10:33 PM, John Kozubik <john@kozubik.com> wrote: > If it were up to me, I think I would stake out a very loud and clear miss= ion > statement for FreeBSD that explicitly sacrifices new features for longer > lifecycles and deeper investment in particular releases. =A0I've thought > seriously about the points that were made in this thread supporting faste= r > releases, and I do appreciate what we would be giving up, but I continue = to > advocate for a new major release every 5 years. To summarize 7 years of working on AIX, where we upgrade the major version number every 5 years or so, in the interim we do deliver hundreds of other features. However, if we made a poor choice for interface, we're stuck with it. This leads to two things: (1) flexible interfaces, like leaving an unused flags field in a syscall so it can become variadic later, and (2) flexible structures, like leaving a few bytes in a struct that's part of the KBI so they can be filled in, and when that space is nearly out, malloc(9) more storage to hang off the struct. Sometimes this means a lot of extra testing effort to ensure the legacy interface works as well as any extensions that arise later. It's not ideal, it's more work when designing and testing, and when a major release does come around where we could break binary compatibility, we've often forgotten about a lot of these little bits and just leave things the way they are. With a more frequent release cycle FreeBSD can be more free about breaking KBI and ABI, and even the [AK]PI, which keeps the current code clean but makes upgrading more difficult. It's a hassle. It's doable, but it adds work, and that's a tough call to make for a volunteer effort. Increasing the barrier to entry, or reducing the "fun" part of working on FreeBSD doesn't serve the project either. Just my 2 cents, a month late. Cheers, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm9tsHAy%2BWPCzTkhk_Z2h%2Bw83LvuOM%2BxPmu%2B%2B4_n--y-6w>