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