[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
- Subject: Re: Proposal for 1.6 and above: small new-code-only developer release
- From: Kaare Rasmussen <..hidden..>
- Date: Wed, 20 Jul 2016 09:13:20 +0200
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