[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


Just my 0.02 <currency>:

> This is a question which comes up fairly often I think.  There are a
> number of questions in response to that that I think are worth coming up
> with answers to:
> * Does it seem like some form of usable package can be formed when you
> end up throwing out all "old code" right now?
> * Are you looking at creating two sub projects (which might in the
> future be merged into a single project again)?
> * What are your main goals in throwing out all the "old code which we
> haven't been able to replace"?

I understand all the reservations. The world is full of dead and 
abandoned project rewrites. In this case though, I think there is more 
point in doing it than in most other cases.

The code is scattered over several modules, not from a design 
perspective, but for historical, or 'this is just the way it is' 
reasons. This kills maintainability. My own quest into 1.5 is a sign of 
this, I think. That the system works at all is down to the amazing work 
of the developers. But Chris put it something like this in a discussion: 
In most projects, you'll improve your efficiency by a factor with the 
knowledge you get from digging in the code. In LedgerSMB it's like 
starting all over again, every time.

The design is very much a product of ad hoc thinking in the original 
SQLedger, basically making extendability, or even natural development hard.

If ever there is a rewrite, I would expect that an upgrade path would be 
one of the design goals that can't be waived.

I understand the concern about the resources being spread too much. It's 
just my experience that a well-designed, well-maintained system is many 
times more responsive to developer effort. Or in other words, a poorly 
crafted system is a time sink. Building on quicksand is never a good idea.

I'm impressed that you've managed to go where you've gone from the 
original sources. I just think there's even more to do to get up to par 
with tomorrow's, or  even today's, standards. That's why I think it's 
the way to go.

Just my opinion, of course. Formed by testing, looking at code and 
database schema, and discussing things on and off list.


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