Cabal Ports Reworked & Committed
Dear all, As you might have seen, yesterday I finally committed my changes regarding the Cabal-based Haskell ports [1]. Hopefully both QAT and pointyhat will like it, and we can start to catching up with updating and adding new ports in the haskell category. You can submit updates in any form you like, for instance via: - GNATS PR [2] (preferred). - Direct email to FreeBSD committers [3]. - This list. Please, try to use hsporter [4] and send patches or tell me about your experiences! :) I also would like to call everybody for discussion on how to proceed. I have made some preliminary experiments with gitting and package building on our own, so I think it slowly becomes possible to implement a more open and fast-paced development for FreeBSD Haskell ports and packages with occasionally merging back to the FreeBSD Ports Collection as Samy Al Bahra has already imagined it about a year ago [5]. In my opinion, we should still stick to the original idea, and host a public git repository somewhere where we provide access to all interested contributors. But I propose to start small: use only two branches in the beginning. - The "master" branch would be the place for the daily-updated vanilla FreeBSD ports tree, used for periodic (perhaps weekly) internal merging. - The "ports" branch would be where you can add and update your ports. It would serve two purposes: * Doing "crawling" package building which means this branch will be checked out on my box on a regular basis, and used for building more or less up-to-date packages for all supported versions (7.2, 7.3, 8.0, 6-stable, 7-stable, 8-stable, 9-current) on all supported platforms (i386, amd64). Proper distribution of these packages is not solved yet, but it can be solved I think. * A reference point where FreeBSD committers can merge to the FreeBSD ports tree. You may view it as a form of batch submissions. Notes: - For the best results (and sparing some wasted cycles and space when building packages) we should really focus only on hackages which are valuable, i.e. you use it or want to use it. Check out Don Stewart's nice statistics if you are in doubt [6] (especially the fields "Votes" and "Downloads"). - Cabal and cabal-install should not be ported in this style as they are interfering with native FreeBSD Haskell ports. I am working on a separate port for Haskell Platform which includes them (and GHC 6.12.1), hopefully it will be available soon. - We should always stick to a reliable version of GHC (which is 6.10.4 at the moment), if you need the latest stable one you can download it as a vanilla binary distribution right from the GHC home page because FreeBSD is a Tier-1 platform now [7]. For the really impatient, there will be daily current and stable snapshots of GHC published soon. - For QAing I can offer Tinderbox support for a limited number of contributors. Please comment on it. Cheers, :g [1] http://lists.freebsd.org/pipermail/cvs-ports/2010-May/194540.html [2] http://www.freebsd.org/send-pr.html [3] mailto:haskell@freebsd.org [4] http://code.haskell.org/~pgj/projects/hsporter/ [5] http://www.haskell.org/pipermail/freebsd-haskell/2009-January/000016.html [6] http://www.galois.com/~dons/arch-haskell-status.html [7] http://www.haskell.org/ghc/download_ghc_6_12_2.html#freebsd
Gabor PALI writes:
Dear all,
Hi Gabor,
As you might have seen, yesterday I finally committed my changes regarding the Cabal-based Haskell ports [1]. Hopefully both QAT and pointyhat will like it, and we can start to catching up with updating and adding new ports in the haskell category.
I didn't noticed that, but thanks for bringing that to my notice. I looked at couple of ports they look really beautiful and slim now. Though, I've not tried them yet, but will try them tomorrow. Thanks for your efforts. :)
You can submit updates in any form you like, for instance via:
- GNATS PR [2] (preferred). - Direct email to FreeBSD committers [3]. - This list.
Please, try to use hsporter [4] and send patches or tell me about your experiences! :)
And also aren't you going to put hsporter on hackage ? And then have it as a port. IIRC, hsporter worked fine with no issues.
I also would like to call everybody for discussion on how to proceed. I have made some preliminary experiments with gitting and package building on our own, so I think it slowly becomes possible to implement a more open and fast-paced development for FreeBSD Haskell ports and packages with occasionally merging back to the FreeBSD Ports Collection as Samy Al Bahra has already imagined it about a year ago [5].
In my opinion, we should still stick to the original idea, and host a public git repository somewhere where we provide access to all interested contributors. But I propose to start small: use only two branches in the beginning.
- The "master" branch would be the place for the daily-updated vanilla FreeBSD ports tree, used for periodic (perhaps weekly) internal merging.
- The "ports" branch would be where you can add and update your ports. It would serve two purposes:
You mean per-user "ports" branch, or just single "ports" branch ? Ashish -- Sent via Gnus from GNU Emacs They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. -- Benjamin Franklin, Memoirs of the life and writings of Benjamin Franklin
Hello, On 05/13/10 18:07, Ashish SHUKLA wrote:
And also aren't you going to put hsporter on hackage ? And then have it as a port. IIRC, hsporter worked fine with no issues.
Yes, I am planning to publish it as a hackage. But it still has problems with proper Makefile generation (and lacks documentation, there is no error handling), I want to fix them up first.
You mean per-user "ports" branch, or just single "ports" branch ?
I thought of a single "ports" branch, but I think git does not restrict you, so you can have more (even personal) branches :) In my proposed system, the "ports" branch would serve as a basis for building packages and committing to the FreeBSD ports tree. Cheers, :g
Gabor PALI writes:
Hello,
On 05/13/10 18:07, Ashish SHUKLA wrote:
And also aren't you going to put hsporter on hackage ? And then have it as a port. IIRC, hsporter worked fine with no issues.
Yes, I am planning to publish it as a hackage. But it still has problems with proper Makefile generation (and lacks documentation, there is no error handling), I want to fix them up first.
Okay, fine.
You mean per-user "ports" branch, or just single "ports" branch ?
I thought of a single "ports" branch, but I think git does not restrict you, so you can have more (even personal) branches :) In my proposed system, the "ports" branch would serve as a basis for building packages and committing to the FreeBSD ports tree.
Do you see this *single "ports" branch* really working in practise ? I mean, what if you and me tried to push commits affecting common files ? With any effort trying to resolve that conflict, would be waste of time, esp. if both commits are just about updating ports. We will need good communication to avoid such issues. And since we're not able to even successfully arrange an IRC meeting, I don't think this approach will be feasible. On the other hand, with per user branches, it is your area, do what you wanted to do, without effecting anyone else. And merging from the master and other users branches, whenever you need it. To keep others informed about one's progress, we can create a post-update (or whatever the correct name would be) hook in the repository, which mails your pushes to the list. And also a public mirror of the repository kept in-sync (via post-update hooks) would be nice for casual contributors who can do anonymous clones, and it also provides functionality to view other branches without checking out them. And also when filing PRs, making sure to keep list in the loop would be nice idea to inform about the updates. And also it would be nice if we can discuss all of these issues over IRC sometime. Ashish -- Sent via Gnus from GNU Emacs They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. -- Benjamin Franklin, Memoirs of the life and writings of Benjamin Franklin
Hello, On 05/14/10 07:04, Ashish SHUKLA wrote:
Do you see this *single "ports" branch* really working in practise ?
I do not know... until I try to implement it :P I proposed things and put them on discussion, they are not statements. You may interpret it as "hey, somebody help me with this, damn it".
I mean, what if you and me tried to push commits affecting common files ?
Well, then we need to resolve the conflicts. I think nothing saves us from conflicts anyway.
We will need good communication to avoid such issues.
Right, since we would been collaborating or what...
And since we're not able to even successfully arrange an IRC meeting, I don't think this approach will be feasible.
I do not feel it a big problem. You must take into account that IRC is not suitable for everybody. Based on the mail (and IRC) traffic so far, I do not expect a tons of commits in the beginning, and since we would hand out the access to the repository one by one, we can oversee who will commit at all. - Regarding updates, I think maintainership would still count as a reference, i.e. maintainers are free to update their own ports and other maintainers should be respected (notified before any changes). - Regarding new ports, perhaps we should create and maintain a public list of "ports in preparation" (in the repository or somewhere else) where everybody could publish his or her intentions on porting, so they can be even pinged when there is not too much activity but you have a complete solution already. I am also working on a gitit-based site for freebsd.haskell.org where things can be coordinated via a wiki. Until it is not ready, Jacula and I can do this on the FreeBSD wiki.
On the other hand, with per user branches, it is your area, do what you wanted to do, without effecting anyone else. And merging from the master and other users branches, whenever you need it.
Yeah. Most of my previous suggestions can be automatized this way :)
To keep others informed about one's progress, we can create a post-update (or whatever the correct name would be) hook in the repository, which mails your pushes to the list. And also a public mirror of the repository kept in-sync (via post-update hooks) would be nice for casual contributors who can do anonymous clones, and it also provides functionality to view other branches without checking out them.
I do not have any objections, but I do not have too much time for this :) I would be happy if you could build this (or a proof-of-concept). Only thing I need is a reliable place where I can pull changes from to build packages.
And also when filing PRs, making sure to keep list in the loop would be nice idea to inform about the updates.
A solution would be to link this list to the haskell@freebsd.org alias.
And also it would be nice if we can discuss all of these issues over IRC sometime.
I am there on Saturdays as always. Cheers, :g
Hi, Gabor PALI writes:
Hello,
[...]
And since we're not able to even successfully arrange an IRC meeting, I don't think this approach will be feasible.
I do not feel it a big problem. You must take into account that IRC is not suitable for everybody. Based on the mail (and IRC) traffic so far, I do not expect a tons of commits in the beginning, and since we would hand out the access to the repository one by one, we can oversee who will commit at all.
- Regarding updates, I think maintainership would still count as a reference, i.e. maintainers are free to update their own ports and other maintainers should be respected (notified before any changes).
- Regarding new ports, perhaps we should create and maintain a public list of "ports in preparation" (in the repository or somewhere else) where everybody could publish his or her intentions on porting, so they can be even pinged when there is not too much activity but you have a complete solution already.
I am also working on a gitit-based site for freebsd.haskell.org where things can be coordinated via a wiki. Until it is not ready, Jacula and I can do this on the FreeBSD wiki.
Okay, fine with me.
On the other hand, with per user branches, it is your area, do what you wanted to do, without effecting anyone else. And merging from the master and other users branches, whenever you need it.
Yeah. Most of my previous suggestions can be automatized this way :)
To keep others informed about one's progress, we can create a post-update (or whatever the correct name would be) hook in the repository, which mails your pushes to the list. And also a public mirror of the repository kept in-sync (via post-update hooks) would be nice for casual contributors who can do anonymous clones, and it also provides functionality to view other branches without checking out them.
I do not have any objections, but I do not have too much time for this :) I would be happy if you could build this (or a proof-of-concept).
I can setup a proof-of-concept and my end and mail you the final details.
Only thing I need is a reliable place where I can pull changes from to build packages.
Okay, how about you or someone from us becoming the *incharge* of the main-tree, and everyone send merge requests to the *incharge* whenever they believe state of their local branch is sane enough to be tested. In this case, the *incharge* will be responsible for merging all the changes. And any external person, looking forward to check the state of the work, can see that branch. Branches can be substituted with repositories and merge request can be substituted with pull request.
And also when filing PRs, making sure to keep list in the loop would be nice idea to inform about the updates.
A solution would be to link this list to the haskell@freebsd.org alias.
Yes, seems fine to me.
And also it would be nice if we can discuss all of these issues over IRC sometime.
I am there on Saturdays as always.
Looking forward to see you at the usual time of the meeting. -- Ashish SHUKLA Sent via Gnus from GNU Emacs
participants (2)
-
Gabor PALI -
wahjava.ml＠gmail.com