Date: Sun, 19 Dec 2010 07:57:36 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Doug Barton <dougb@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Following vendor release cycle (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x) Message-ID: <20101219055736.GI33073@deviant.kiev.zoral.com.ua> In-Reply-To: <4D0D3E9F.4010100@FreeBSD.org> References: <4D0C49A2.4000203@FreeBSD.org> <20101218111538.GZ33073@deviant.kiev.zoral.com.ua> <4D0D3E9F.4010100@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sat, Dec 18, 2010 at 03:07:11PM -0800, Doug Barton wrote: > On 12/18/2010 03:15, Kostik Belousov wrote: > >On Fri, Dec 17, 2010 at 09:41:54PM -0800, Doug Barton wrote: > >>Howdy, > >> > >>Traditionally for contributed software generally, and BIND in particular > >>we have tried to keep the major version of the contributed software > >>consistent throughout a given RELENG_$N branch of FreeBSD. Hopefully the > >>reasoning for this is obvious, we want to avoid POLA violations. > >Actually not. My own POV is that we should follow the vendor release > >cycle, and not the FreeBSD release cycle, for the contributed software. > > > >I do not advocate immediate upgrade of the third-party software that > >reached its EOL, but I think that we should do this without pushback > >if maintainer consider the neccessity of upgrade. > > Just to be clear, there were considerable discussions, over a long > period of time; between myself, the release engineers, and the > security-officer team regarding the subject of BIND 9.3 in RELENG_6. I > was given the green light to upgrade if I felt it was necessary (as > you're suggesting here) but the final decision to live with the status > quo was mine, and I accept responsibility for it. > > My reasoning was as follows: > > 1. All the latest versions of BIND are available in ports, and I made > sure that they worked in RELENG_6 so that users who wanted to stay at > that OS level but had more serious DNS needs had an easy path. > > 2. Because BIND 9.3 lacked the ability to do modern DNSSEC anyone who > wanted that feature would have to upgrade anyway. > > 3. BIND 9.3 was still suitable for the (primary) stated purpose of BIND > in the base, a basic local resolving name server. > > 4. BIND 9.3 was different enough that users migrating from it to more > modern versions were experiencing problems. > > 5. Users were naturally migrating to RELENG_[78] at a pace which > minimized the impact of the issue. > > If any of those things had stopped being true my decision would have > been different, but as it was I chose to "grin and bear it" in order to > avoid the POLA violation for any users who were actually using BIND 9.3 > in RELENG_6. However, the circumstances for BIND 9.4 and RELENG_7 are > different, and much more amenable to the upgrade, which is why I'm > proposing it. I do not question your decision of upgrading or leaving the legacy version of BIND in the legacy branch of FreeBSD src. I only noted that my personal POV is that we develop the OS, and not are the vendor of the third-party software, in this case the BIND. As such, I think that following the vendor life-cycle for contrib is less resource-intensive for the project, and should be the default. If anybody who does the real work feels that it is interesting/nice to the users/generally better to spend the time neccessary to keep the upgrade path on the branch smoother, I am fine with this. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0NntAACgkQC3+MBN1Mb4jZtgCdHRVnerwmoio52JpoaDbl5p0d BBUAnRoIEEQGuMwBfeCfKcmA+nbAMQ6l =1Hx/ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101219055736.GI33073>