Weissmann Markus wrote:
It's much easier to do packaging and testing, when the rate of change slows down. The automated build and packaging process is being revised now (using it to build RPMS), and that is very useful to have either way.
This is great. I think we can talk about splitting the tree as soon as this features is finished and we have a build-server that reports about build errors.
Having a build server is more of an infrastructure/resource question, but there is a lot of work being done with tracing and logging - I'm more doing the oldfashioned approach with a chroot and scripting... But the Koji* build system is kinda nice looking, otherwise... :-)
Impatient or out-of-date users will occur either way, the easiest path to help them is probably have an updated ports list for easy viewing - such as a web page with versions and recent updates.
The out-of-date users will be far less if we provide RPMs. The impatient ones are often also those who find the bugs in the first place.
It's also possible to provides archives (tgz) for impatient developer users, within the port system itself. But both are being built anyway, it's the same destroot contents in both - no matter the wrapping. Having portable MacPorts also helps, easier to build/test on BSD/GNU. --anders * see http://koji.fedoraproject.org/koji/