On Mon, 2007-08-06 at 10:16 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
so what can we do about it?
BTW, thanks for all the cleanup you did over the weekend, looks great.
Some barriers to entry:
1. reporting bugs requires logging in, many people still miss this. 2. bug reports get ignored (which is disheartening to users) because... 3. bug reports do not get reported to this list (like ghc ones get reported to the ghc-bugs list). This also means we get no public discussion going on most bugs, and the people who finally close bugs get no public recognition.
The Trac configuration is set to auto CC this list with bug updates, but the mailing list config needs to be updated to allow them through. Isaac is the only one with admin permissions on the list at the moment, should we add more people? Volunteers?
I'm a moderator too at the moment, however the list is subscriber only so I only get notified about over-long posts etc. It was previously open but moderated and we got a huge amount of spam.
4. there is no cabal hacking guide, a short guide to the source code and style would help (eg explaining the main environments functions operate in, ie BuildInfo, LocalBuildInfo). Simple things like adding fields, commands or new flags.
Thomas has offered to write a HACKING file.
5. it's not clear if it's possible to set up a local hackage servers to help test & hack on the hackage web code. 6. darcs sending patches get rejected by default since the cabal-devel list is subscriber only.
Again, this is a mailing-list setup issue. cabal-devel should do the same as cvs-ghc, and moderate by default (but someone needs to do the moderation).
How does cvs-ghc deal with this? Does it go via a spam filter first before the moderator? And can the mailman white-list people so on their first post they can be cleared by the moderator to post from then on (without the person having to subscribe)?
Probably more things.
People often complain that the internal Cabal code is hard to understand, which is partly true though it's also related to point 4.
...and I think a lot can be done to improve things incrementally.
Yes.
There are abstractions that are not consistently used (eg. Program, but it sounds like you've improved things here), and missing abstractions (compiler-specific stuff is not sufficiently abstracted). There are over-complex abstractions: e.g. hooks. There are not-very abstractions: the "simple" build system is wired-in when it was originally intended to be layered on top of the basic infrastructure. I'm not sure whether we should abandon this layering or try to do it properly.
Yes, there's more work to do in improving the Program, PreProcessor and Compiler abstractions.
All this has arisen because Cabal has been hacked on by a wide range of people, few of whom really took an interest in the design of the system as a whole. Mostly we were trying to get the job done and make Cabal do what we needed, which to a large extent it does.
Aye. Cabal/Hackage is fantastically successful, despite the amount we grumble about it's shortcomings.
But this is fertile ground for hackers who enjoy cleaning things up and refactoring...
Certainly. How to recruit such people... I might try and do a 5-min status report at AngloHaskell. "Cabal needs you" or something :-) Duncan