[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for 1.6 and above: small new-code-only developer release


On 07/15/2016 02:16 AM, Erik Huelsmann wrote:
Hi Chris,

One of the difficulties we have had for a while is the ability for new developers to come in and contribute, in part because of the code quality of the older code layers (most particularly the SQL Ledger codebase but also our earlier work)  One possibility would be to establish a parallel release that would only be new code.  One reason we haven't done that is that right now, if we did this, we couldn't meet anyone's needs.

Thanks for bringing this up! It also very much relates (IMO) to the thread I started some time ago about a next-10-years vision (http://archive.ledgersmb.org/ledger-smb-devel/msg06409.html).

Not entirely opposed to the idea, but I think the focus should be on the overall system design -- don't want to get sucked into too much module-by-module rewriting.

I'm thinking we should be focused on three key design areas:

- What is the desired user experience we want to have? The BDD tests are crucial for this, and we should develop those before doing any forking into parallel branches.

- What sort of API can we put in place to act as a contract between the user experience, any external integrations, and the back end?

- Do we have the best underlying data schema in place going forward? (E.g. the multi-currency stuff that Erik has created -- are there any other ways our current schema limits what LSMB can do effectively?)

I think a strong focus on these 3 key areas will make our project progress based on a much more cohesive intention, rather than fighting fires/bugs/fixing things as they arise and doing battle with the old code...

I would like to see us develop these 3 things first, define what we want the system to do and how we want it to behave -- and try to wrap as much of the old code in as possible. I do expect we may hit some big roadblocks in some parts of the code that are just not possible to wrap or fix without rewriting -- but how many of these have you already blown through and rewritten? I suspect with proper design, it may be possible to rewrite the implementation much more quickly, making the new code work the way it should work, and not just a better version of a crap design.

There's a rather fundamental question to be asked here, if you bring  up the "on boarding of other developers", which might come down to a  "chicken and egg problem": should we expect more developers to be joining the team? I mean, is there a group of developers out there that we expect to be able and willing to contribute to our accounting application?
It just so might happen to be that (apart from the fact that we were lucky to have 2 in the first 6 months of the year), there are extremely few devs who would love to work on LedgerSMB (or any other web-erp) instead of some hyped app.

I don't think we need to focus on onboarding other developers. I do think we should start more marketing. I think the work Erik has been doing on BDD is fantastic, and if we start talking about it more, we're sure to attract other developers. And if we have a solid API and BDD framework, I think it will be easier to solicit contributions from new developers...

And if such a group of developers were to exist, what would stir their interest in LedgerSMB instead of in, say, Odoo? Wouldn't having something that *almost* works be a better choice for a business to run their operations on? And from there, contribute to the further development of the application.

Totally agree here -- having something that mostly works and a bunch of companies using it, and evolving that to better tested, more reliable code is a big win. While I do think it's a good idea to start a fresh branch with only working code, that also becomes a huge barrier to contribution if nobody is using that code in production. It becomes such a massive undertaking with really far-off payoff.

I mean, I would love if somebody would do this work -- AFTER we know what it should look like, with as much of the new design dropped into the currently working version as possible. As long as it got done at sometime useful, and didn't happen at the expense of having a working production version.

But I was thinking.  With the current work regarding GL, maybe in 1.6 we could start with a parallel release which would include only fully re-engineered code.

I can see how that would an absolute relief :-) However, do we think we can attract new developers with it? I mean, looking at yourself: would you join a team with the perfect code base, even though you can't really use the product yet? Or would you join a team where you can use the product, but simply want it improved, because the code base has real problems?

Maybe we can put new API/interfaces in as stubs, build out the whole design in the current release? Throw "unimplemented" exceptions where the new code isn't built yet, build the parallel functionality in the current release and migrate stuff over a chunk at a time?


Basically, from a development point of view, I've taken exactly this approach, btw: I've been working around the old code, putting a foundation in place which can replace the old code after we rip it out, without ever needing to touch the old code. In that sense, the existence of the old code in the code base hasn't bothered me much over the past year, other than that I have had to fix bugs in our old code, because people were running into problems.

Yes, exactly -- I think we should continue this approach.


As for removal of old code: I don't see that as a goal by itself. I see it simply as a means to move the LedgerSMB code base to a point where we can have a much better agility in bug-fixing, where we can be much more extensible and open to integration with surrounding systems.


Happy to add more later, but gotta run, camping weekend ahead!

John Locke
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
Ledger-smb-devel mailing list