[Freebsd-haskell] Development Plans
Samy Al Bahra
sbahra at applicative.org
Mon Jan 19 19:14:29 EST 2009
A majority of our infrastructure is now ready to begin collaborating our
FreeBSD Haskell efforts. I present here a proposal for collaborating our
work in the git repository.
The following branches seem to be necessary,
This will be a ``read-only'' branch consisting of daily merges of the
FreeBSD ports repository. It will never be committed to otherwise.
This will consist of updates and minor changes to the ports we each
maintain. This branch can be seen as being in a constant state of ``slush''.
Ports committers may use this branch to commit our ``minor'' work with much
ease. Commits will be made on a port-by-port basis and must be ordered based
For example, if I wish to commit a port A which depends on port B then I
would first commit port B and then port A. This will make it easy for ports
committers to generate diffs for their local repositories.
With no doubt, GHC maintenance is central to our project. I would be
creating a ghc meta-port in this branch and move current ghc to ghc-6-8.
After this, I will be porting over ghc-6-10. The ``ghc'' port will always be
pointing to the latest stable ghc release in ports. Every GHC update might
involve changing/modifying legacy ports to point to the older versions of
GHC they depend on (if necessary).
This branch would contain our experimental work with bsd.haskell.mk.
It would involve mainly bsd.haskell.mk changes for now. Once it is committed
to the FreeBSD ports project, its changes will bubble back here (master ->
ports -> ghc -> infrastructure) from FreeBSD itself. At this point, we would
be ready to do the massive sweeping changes to the FreeBSD ports in the
ports branch in a small step-wise manner (which should mean a non-disruptive
experience for FreeBSD Haskell users).
I propose that the ports branch merge in changes on a regular basis from the
master branch, the ghc branch merge changes from the ports branch and the
infrastructure branch merge in changes from the ghc branch. This is based on
multiple factors including relative ease of merging a branch's work
upstream. The infrastructure branch will also always depend on GHC which
will always serve the needs of the ports branch which will always be similar
to the master branch (as it involves no sweeping changes). The following
simple diagram might help describe this,
FreeBSD Project -> Master -> Ports -> GHC -> Infrastructure
^ | | | |
| | | | |
The following issues need to be addressed,
github mirror: Ashish, could you give us the URL to the github mirror?
Should this be a weekly mirror? Daily?
Mailing list usage: This is really just a note to certain people (cough,
cough, pgj@) that you should generally have the "To" line set to the mailing
list and CC: individuals involved. If the "To" line is not set properly some
mail clients will not be able to respond properly. This has already resulted
in several lost messages.
Let's get the ball rolling! What do you guys think of the above proposal? If
we are in agreement, I can go ahead and work on the proper commit scripts
for the master branch and create the following branches. I plan to begin the
GHC work immediately. We should be able to work mostly in parallel this way.
Samy Al Bahra <sbahra at applicative.org>
More information about the FreeBSD-haskell