duration of the ports freeze

[Peter Jeremy]

On Sat, Dec 01, 2007 at 09:33:30AM -0800, David Southwell wrote:
>current. The idea I proposed is that ports have release dependencies and as 
>new releases are being prepared maintainers change the dependencies when the 
>port has been tested and ready for the new release. In other words the 
>process becomes one of independent migration of capability over time rather 
>than a mad rush within a freeze.

It's not clear to me how this differs from having a branched ports
tree.  Say X.org 7.4 is released tomorrow with a new set of libraries.
What you seem to be suggesting is that it would be committed to the
ports tree now but marked "untested".  What happens to all the X
client ports?  Do they get built against the "working" X.org 7.3 or
the "untested" X.org 7.4?  What if my whizz-bang port has an upgraded
version that uses new features in X.org 7.4 - do I commit it or not?

>IMHO we need to switch priorities. It does not matter if it takes 3 months to 
>have the ports migrated for the new release.

I think you have this totally backwards.  The underlying OS is a
platform upon which users run the applications they need.  I doubt
that the base OS includes all the required applications in very many
(if any) situations.  For most users the applications they want to
run are ports.  Releasing 7.0 with the caveat that (say) the X11
ports do not work with it but we hope to have them available in a
couple of months means that no-one will bother installing 7.0 for
a couple of months.

>It 
>matters when you cannot test projects using the same version of software that 
>someone else is using.

No-one is stopping you from using whatever version of software you
want to use.  The FreeBSD project performs QA and integration testing
on particular versions of software and makes available package sets
that it believes will work together.  IMHO, this is more important
than having the latest and greatest version for most users.

> The current OS capability is less significant to end 
>users than port capabilities.

And for this reason, it's important that OS upgrades come complete
with a consistent and reasonably complete set of ports.  Given the
resources available to build and manage the ports tree, the only
realistic approach is to minimise the changes within the ports tree by
freezing it.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20071201/7a506d74/attachment.pgp