Participation in Cabal / Hackage development

[Duncan Coutts]

On Sat, 2009-01-17 at 18:40 +0000, Duncan Coutts wrote:
> All,
> 
> I just mentioned ideas for Cabal 2 but I should also like to talk about
> how we can go about increasing participation in the development effort.
> We currently have nearly 200 open tickets which include many important
> bugs and no shortage of good ideas for useful new features.
> 
>         Our limiting factor is developer time.


A secondary issue is design. We get lots of feature requests "there
should be a way do to X". But there's quite a bit of work to get from
there to a point where we can start coding. It's not even the design of
the code that's the issue, but how the feature really should work. What
the user interaction should be and how it should interact with other
features.

We've got dozens of tickets in our tracker in this state where they're
not yet ready for someone to pick them up and implement it in an
evening. This is certainly a barrier for anyone interested in Hacking on
Cabal, they're not going to pick these tickets where it's not at all
clear what they would have to implement.

This is particularly noticeable if you look at the tickets not assigned
to any milestone. See the last section in this report:
http://hackage.haskell.org/trac/hackage/report/12

A few random examples:
#214 Package security
#293 allow installation of non-haskell or haskell script executables
#330 Support general documentation, not just haddock
#364 cabal should allow source to be installed with/added to binary packages
#457 cabal list: filter by pattern
#237 Support addition of links to Cabal project pages
#313 line counting

Perhaps we need to make this more explicit in our bug tracker, have a
milestone for tickets in limbo that need more design work. It might help
to draw attention to them from people who want to see the feature
implemented if we make it clear we cannot start work on them until
various design issues are clarified.

Duncan