On 08/06/05 15:53 Johannes Winkelmann wrote: Hi,
As a consequence of the experience gained from using mppm and xsvn, I've tried to come up with an improved concept for multi-architecutre support. The result is a rather long document, and can be found at http://jw.tks6.net/files/crux/multi-arch-proposal
We briefly discussed abou multi-arch support and I confirm my latest reflections on the topic: - Good to have separate branches for different archs - A dedicated client to help maintainers would be very handy and will certainly cause less headaches than traditional merging techniques (btw, the stm name is nice!) The only think that scares me a bit is not to have a arch-based "main" source but rather a maintainer-based one: (quoting from the link above)
1. within the pool of official ports, there exists only one "primary maintainer" (PM). He/She maintains this port on his/her preferred architecture.
3. If there's a maintainer for port X (which is already maintained by a PM), he/she becomes the "arch maintainer" (AM) for this port.
In the past I suggested of having an "official" main repository (today x86, tomorrow could be x86_64) because: - there are higher chances of ports playing well together. With the per-maintainer base pool you propose there could be a set of related ports not fully tested on the same arch. - extension of the previous point to user feedback: the current mainstream arch would almost certainly get more user feedback and test cases (I'd call it more tested), so to me it's a natural step to base other archs on that. On the other side I understand that this puts some maintainer in a bad position when he wants to maintain a port for $hippie_arch that it's not in the main pool. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com