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
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
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
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
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
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