Following vendor release cycle (Was: Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x)

[Kostik Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20101219/40df1e32/attachment.pgp