duration of the ports freeze

[Mark Linimon]

On Sat, Dec 01, 2007 at 06:51:58AM -0800, David Southwell wrote:
> Before I do so let me  step outsiide the freebsd environment and ask what our 
> comments would be if MS$ were to announce that they were about to release an 
> upgrade to their operating system and until the new upgrade had been released 
> upgrades to existing applications would be barred. I am sure we would all 
> agree that that was ridiculous.

I would certainly not agree that that's ridiculous; I'll call it an
essential part of a QA process to hold changes to a minimum.

> What proportion of freebsd users will immediately upgrade to the new 
> releases?? Maybe 5% or 10% at the most.

I think a larger number than that will do so -- for the usual reason that
they want the bugfixes that come with that release (especially if those
bugs are ones affecting their installation).  The answer to most problem
reports for bugs fixed in later versions is "upgrade" -- not just FreeBSD,
but any software product.

Another factor to consider is that during the period between releases,
most people will start with FreeBSD by installing the release CD.  To
the extent that the ports and packages on that CD don't work, we tend to
lose new users right there.

> How about maintaining the port tree as usual during the pre release period. By 
> default all releases in the tree prior to a selected date should incorporate 
> a release dependency in their makefile that would NOT include the pending 
> future release.
> 
> As each port is tested against the new release its release depency would be 
> changed and upgrades could continue to be added to the tree as normal.

I think you seriously underestimate: the complexity of the dependency trees,
the amount of horsepower it takes to build packages (even given that the
build cluster "understands" to only build packages for which their port, or
a dependent port, has changed in the meantime); how many person-hours it
takes to analyze the results of package runs; and the subtle nature of
how "innocent" dependency changes can break things.  I'll freely admit
to not fully understanding #1 and #4, and I think I understand more about
them than all but a few people in the project.  (I've spent a fair amount
of time researching the package status over time to learn more about them.)

I know all of this stuff happens in the background and isn't visible to
most of the users, but the effort is large nonetheless.

mcl