[Freebsd-haskell] Things to do (re: Some Topics to Discuss...)

[Samy Al Bahra]

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]