hacking cabal is too hard...

[Duncan Coutts]

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