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.
pgp0tpCxLrKHK.pgp
Description: PGP signature
