duration of the ports freeze

[Aryeh M. Friedman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Linimon wrote:
> 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.

Most of the problems you cite are due to an attempt to roughly
duplicate the make(1) model of building systems which has been shown
to be ill adviced at best for large systems (not to mention
multi-project ones).... See http://aegis.sourceforge.net/auug97.pdf

Unlike when make(1) was first made there is enough horse power and
understanding of graph problems that is possible to consider the
entire ports graph at once and do some global decisions based on it
(even for indivual ports)

- --
Aryeh M. Friedman
FloSoft Systems
Developer, not business, friendly
http://www.flosoft-systems.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHUbsQ358R5LPuPvsRAulxAJ96JRZOiVJcvr+C4IdZxrSIbv96NwCeJ13i
LQ3izjR9Hbv+zkKDb23wsDs=
=c+jE
-----END PGP SIGNATURE-----