Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)

On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote:
> > No, you're missing the point.  More core OS upgrades means less
> > incremental patches (which are easier to apply than a full update).
> 
> Right.  I don't understand how B follows A here.
> 
> These patches come from where?  Security advisories, mailing list
> discussions, and eating too much beef right before bed and waking up
> at 2am with brilliant ideas?  Why would there be less of them, just
> because RELENG_X_Y_RELEASE tags are laid down more often?

I think the real concern here is: for how long after RELEASE_X_Y are binary
patches for it made available?

If the policy is "every RELEASE_X_Y has binary patches available for Z
months after its release", then clearly it doesn't matter how many
RELEASE_X_Y's are made in this period.

If the policy is "binary patches are made available for the last N
releases", then the availability lifetime of binary patches is
(N * release interval).

As long as N is made sufficiently large, then it's not a problem. There is a
risk that reducing the interval between releases does not cause a
corresponding increase in N, thus forcing people to perform full updates to
a new release more often.

> > Huh?  That's backwards.  If we can't schedule the downtime for a
> > full operating system upgrade (which takes far longer than it
> > should) then the system won't get upgraded.
> 
> Having done full OS upgrades a number of times, I can't remember the
> last time it took more than 5 or 10 minutes
...
> For small groups of servers, I NFS mount
> installworlds, and for larger groups, I rdist out binaries.  But it
> always comes from source.

That's good for you and a certain clan of highly experienced FreeBSD system
administrators. However I believe that there's a far larger pool of people
for whom binary installs and upgrades makes much more sense. At one end of
the spectrum are those bailing out from Linux, and the other end are people
who want an audit trail for every binary back to a 3rd-party release medium.
(I started off in the first group, but now fall into the second)

Regards,

Brian.