Craig, John, your messages had me looking at the code base out of interest. What a beautiful work indeed. If you don't mind I'll try to tackle a few bugs as I work through it. I especially like John's suggestion of writing tests and then trying to make them work. I think that's the way to go for new contributors. When running the tests however I noticed several tests are failing. Maybe there should be a list of tests known to fail so as to not confuse someone who isn't familiar with the code. Maybe this list could link to the corresponding bugs? On Oct 12, 2012 7:40 PM, "John Wiegley" <[email protected]> wrote:
> >>>>> Michal Wallace <[email protected]> writes: > > > Do you have some bugs or wishlist items that relatively junior > > developers could take on? > > Hi Michal! > > Yes, there are a few areas that could use help right away. So, there are > several major sections within Ledger: > > The math code. This is pretty bullet-proof by now, and bugs here are > rare. Some of this code reaches all the way back to 1.x. > > Commodity handling. A lot of the code here is brand new (since the > switch > to Boost.Graph), and there are many bugs associated with it in the > tracker. I would love for newcomers to help here most. Also, this > code > isn't _terribly_ complex. > > Report filtering (filters.cc). Many user's bugs end up being incorrect > interactions between report filters. This is tough code to learn, but > having someone learn it would not only fix a lot of bugs, but open up > the > possibility of new kinds of reports. > > Output formatters: balance reports, register reports, CSV, Emacs, XML, > etc. There are always little bugs here and there. > > Value/query/format expressions. Pretty stable stuff here. Everything > relies on value expressions so heavily, that bugs here have a way of > breaking everything. > > Infrastructure. Still a few bugs in these areas, although not too bad. > I'd recommend focusing on a major feature area, and then fixing things > in > infrastructure as-needed. > > Commodity handling and report filters: that's where I think the best > efforts > could be made right now. > > As for how to proceed, I'd recommend this: Pick an area of the code, and > start > writing tests to exercise that area. For example, forecasting. While > writing > tests to prove forecasting, I'm certain you will turn up several issues in > the > time intervals calculator, and the report logic. Then learn as much as you > need to know to fix that test. Repeat. > > I'm happy to answer any questions about how the code is designed, and also > tricks to make it easier to track down problems. There are lots of > facilities > in Ledger (like --debug), which ordinary users never need to use, but > developers would find themselves using regularly. > > John >
