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[1]. The following branches seem to be necessary, master branch) This will be a ``read-only'' branch consisting of daily merges of the FreeBSD ports repository. It will never be committed to otherwise. ports branch) 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 on dependency. 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. ghc branch) 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). infrastructure branch) 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 ^ | | | | | | | | | '-<-----<-----V----<---V---<----V-----<-----V 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. 1: git://git.applicative.org/haskell/ports Regards. -- Samy Al Bahra <sbahra@applicative.org>
Samy Al Bahra writes: [snipped the plan since I'm okay with it]
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?
The way I thought github mirroring will work is different from the reality. They aren't going to pull from us. We've to push to them. I'll work out a script (after testing) about this by tomorrow and will post to this list. But it should be something similar to the following lines in ${REPO}/.git/hooks/post-update: ,---- | #!/bin/sh | git push ssh://git@github.com/user/repo `---- So someone has to create a github account and a repository. Another thing I would like to recommend is generation of a weekly, daily tarball which one can use instead of initial clone. Extract the tarball and 'git pull' and you're updated. -- Ashish SHUKLA
Ashish SHUKLA writes:
Samy Al Bahra writes:
[snipped the plan since I'm okay with it]
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?
The way I thought github mirroring will work is different from the reality. They aren't going to pull from us. We've to push to them. I'll work out a script (after testing) about this by tomorrow and will post to this list. But it should be something similar to the following lines in ${REPO}/.git/hooks/post-update:
,---- | #!/bin/sh | git push ssh://git@github.com/user/repo `----
The tested ${REPO}/.git/hooks/post-update should look like: ,---- ${REPO}/.git/hooks/post-update | #!/bin/sh | | # On update to a branch, push to the corresponding | # remote branch at "github" remote repository. | git push github $1 | | # Also update auxiliary info files to help update dumb servers. | # if there is some daemon running. | git update-server-info | | exit 0 `----
So someone has to create a github account and a repository.
Another thing I would like to recommend is generation of a weekly, daily tarball which one can use instead of initial clone. Extract the tarball and 'git pull' and you're updated.
And there is another question, whether we can create extra branches (for personal use, e.g. the stuff which we want to commit (because we prefer redundant backup) but is not suitable for merging with "ports" branch) other than the four important branches. Hmm..? I don't think this will be any issue but just wanted to be sure. Thanks -- Ashish SHUKLA
On Wed, Jan 21, 2009 at 06:30:59AM +0530, Ashish SHUKLA wrote:
And there is another question, whether we can create extra branches (for personal use, e.g. the stuff which we want to commit (because we prefer redundant backup) but is not suitable for merging with "ports" branch) other than the four important branches. Hmm..? I don't think this will be any issue but just wanted to be sure.
Of course, this should be fine. However, there is no reason to create remote branches for these kinds of experimental branches unless there will be collaboration. Creating a patch set is a trivial process with git, anyways. Regards. -- Samy Al Bahra <sbahra@applicative.org>
Hi Samy, Here I have to repeat myself, sorry: my first question is how I could become a named developer in this team like the current developers: Ashish Shukla, Gabor Pali, Samy Al Bahra. On Mon, Jan 19, 2009 at 11:30:53PM +0100, Gabor Pali <pgj@FreeBSD.org> wrote:
I do not know who is maintaining the effort's web page, but I would point to Samy. He is the administrator here. I do not have any objection to include you. The more developer we have, the more we can progress.
http://www.haskell.org/pipermail/freebsd-haskell/2009-January/000015.html then I ask you if this is possible in some way. On Mon, Jan 19, 2009 at 07:14:29PM -0500, Samy Al Bahra <sbahra@applicative.org> wrote:
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[1].
Great! :-)
The following branches seem to be necessary,
master branch)
ports branch)
ghc branch)
infrastructure branch) This branch would contain our experimental work with bsd.haskell.mk.
This sequence and the corresponding functions are OK for me, the idea is very good and manageable. About the bsd.haskell.mk (also here I have to repeat myself) I'd like you could take in consideration my old propose and my new one: old: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/124047 new: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/126012 The new propose is working and you can install, with it, also the WxHaskell libraries. On Wed, Jan 21, 2009 at 06:30:59AM +0530, Ashish SHUKLA <wahjava.ml@gmail.com> wrote:
And there is another question, whether we can create extra branches (for personal use, e.g. the stuff which we want to commit (because we prefer redundant backup) but is not suitable for merging with "ports" branch) other than the four important branches. Hmm..? I don't think this will be any issue but just wanted to be sure.
http://www.haskell.org/pipermail/freebsd-haskell/2009-January/000018.html I am in agreement with this proposal. Thanks! Giuseppe
Samy Al Bahra wrote:
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.
Oh, I thought you were referring to the script's mailing behavior :)
Let's get the ball rolling! What do you guys think of the above proposal?
Sounds good. No objections.
I plan to begin the GHC work immediately.
What are your plans with GHC? :g
participants (4)
-
Gabor PALI -
Jacula Modyun -
Samy Al Bahra -
wahjava.ml＠gmail.com