Hello, For some reason, I did not receive Gabor's e-mail. This has made it hard for me to respond properly to his e-mail. As such, I have copy pasted portions of his e-mail for convenience.

- MAINTAINER field of the ports we maintain: To uniformize the effort, I suggest to set the maintainer all of the maintained ports to "freebsd-haskell at haskell.org" (address of this list), so any of the members could easily fix and add new ports, etc. If somebody new wants to tackle these ports, he or she should contact us first and then delegate his or her patches though this list, and so on.

This is a bad idea. Certain individuals are *responsible* for certain ports. Since FreeBSD-haskell is a public list, this means that anyone may respond and accept incoming patches of ports. I suggest that we stick to having individual maintainers for now and switch maintainers once bsd.haskell.mk is ready to a private mailing list consisting of us initial porters.

- Composition of a "bsd.haskell.mk": It is a must, nobody can deny. In the first round, I do not think it should be placed right in the "ports/Mk" directory, because people at the BSD# Project [2] (I think I am going to refer them many times) store their own ".mk" file at the heart of their ports, lang/mono [3]. In my opinion, following this behavior would save the initial efforts from the burden of several port management tests and tasks ("experimental ports build" -- Mark Linimon mentioned these in the PR where a bsd.haskell.mk was offered [4]). So, I suggest to add this file to the lang/ghc port first.

This sounds good.

I think this approach could even make us re-think whether a cabal2port converter is really needed.

No, it doesn't. Unless we have implemented a query-complete *.cabal parser in bsd.haskell.mk, there will remain to be massive productivity boosts with such a thing (ones much greater than having a bsd.haskell.mk when it comes to Cabal).

- Merging our ports with the official FreeBSD ports tree: port trees out of the official FreeBSD port tree (like KDE, GNOME, BSD# etc.) use different techniques to merge ("engraft") their trees. Ashish mentioned that FreeBSD does not have a standard method for implemeting this when I mentioned the famous marcusmerge(8) [7] earlier. He was not happy with this approach, but I found another meanwhile, called portshaker [8] (from BSD#). I have not tried it yet, but it is a yet another way to solve this problem.

We discussed this, and we have agreed to use a git respository. We will need to discuss these initial issues and a separate collection of e-mails will be sent out in order to tackle these issues in detail. We will make it easy for you to generate patches on a per-port basis and per-branch based on dependency. Since none of us are committers, how exactly you decide to merge is irrelevant to us as long as it doesn't involve breaking things. :-P We will need to discuss some details in a separate thread in order to keep requirements/methods crystal clear.

Quarterly Status Report: A short note on that we could advertise ourselves in the recent FreeBSD Quarterly Status Report. However the submission date past (Jan 14, 2009) for the latest one, but as I taught, I think there might be a chance to push one more simple report to Brad :) If I got some nods, I post a draft here and then to monthly at . Of course, it is not a tragedy if we miss this, we can supply it later on.

I think this is a bad idea. Let us get some serious work under our belt before advertising our efforts.

- GHC 6.8.10: What is up with GHC? What are the exact obstacles to get the latest version ported? Has anybody tried it? (I am just curious.)

This is a non-trivial issue. This will be discussed in a separate thread as to keep requirements/directions crystal clear. I suggest an overhaul of how these ports are structured to begin with in order to save ports which do not build or function properly with GHC 6.10. Regards. -- Samy Al Bahra [http://repnop.org]