hacking cabal is too hard...
Isaac Potoczny-Jones
ijones at syntaxpolice.org
Mon Aug 6 13:00:43 EDT 2007
Duncan Coutts wrote:
> 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:
Out of the 6 (very insightful) barriers to entry you mention, I note
that items 1, 2, 3, and 6 all have their root cause in spam problems.
Trac got overwhelmed by spam when it was more open, as did the
moderation section of the mailing list, as you noted. It's really
depressing. Maybe there are some tools out there that could help?
>>> 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 believe Duncan has all the rights on the list that I have, as he
mentions and I'd be happy to add more 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.
That's really great, thanks, Thomas! I'd be glad to proof it and help.
>>> 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.
(Snip. This is interesting when compared to this point:)
>> 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.
Although I hear that people do complain, I think it's very telling that
Cabal has had so many contributers. Very few Haskell libraries that I
can think of have had as many contributers as Cabal has. And please
remember that to some extent, there's always going to be complaining
when reading someone else's code.
I'm not saying that there isn't room for improvement, there is
definitely room for improvement.
> 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 :-)
That would be great.
peace,
isaac
More information about the cabal-devel
mailing list