[Ledger-smb-users] Future of LedgerSMB: Ideas and RFC

[Chris Travers]

Hi all;

Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released. Development may
appear to have slowed. Public discussions become less frequent...

For the last few years, LedgerSMB has achieved significant growth.
Some of that growth has come at an organizational cost and for that I
apologize to the community. Now I have to try to help put the
organizational stuff back together.

In reality, far from being quiet, LedgerSMB 1.3 has had a huge amount
of commissioned work done on it, not only for the core system (where
the customer/vendor management, reconciliation, and payment interfaces
have been completely rewritten) but also in areas of addons for fixed
asset handling, template transactions, so forth. We have eliminated a
lot of performance bottlenecks for larger databases, and provided a
much higher level of security than previous versions. This has been a
very ambitious project and we are much better off for it.

I would like to propose a few specific directional approaches and get
feedback from the community before proceeding.

I think the major priorities at this point need to be:
1) Getting 1.3 out the door.
2) Focusing heavily on community building
3) Trying to build partnerships with other open source business
projects (perhaps GNU Med and others?)


To this end I would like to tentatively suggest the following:
The first is a regular beta release schedule for 1.3... Maybe every
other Tuesday?

There are some committed fixes for 1.2 which have not made it into a
release. I would like to release this as soon as possible. However,
given the fact that bug reports have slowed, I think it is likely that
it is not likely that 1.2 will see another release absent developing
problems like issues caused by new versions of Perl.

I'd also like to encourage anyone who is interested in contributing to
start looking heavily at 1.3. This is a place where you can earn a
name in the CONTRIBUTORS file, or possibly even commit privileges.

But in addition I would like to see what the community thinks. What
do you think we need to do to pull things back together and bring the
project to the next level?

Best Wishes,
Chris Travers

[Lyle]

Post by Chris Travers
I'd also like to encourage anyone who is interested in contributing to
start looking heavily at 1.3. This is a place where you can earn a
name in the CONTRIBUTORS file, or possibly even commit privileges.

I started with the subversion copy, but reverted to the current stable
as time was running out and I really just needed to get something
working. This is helping me get familiar with the software so probably
works better for me now, rather than having to hack away to get the
bleeding edge version working.
I'm very proficient with Perl, have a web designer that works for me,
and a girl that is doing the LedgerSMB data input (novice user). This
puts me in a good position to fix bugs/add features myself, get UI
improvements done and understand the needs of novice users who are
currently finding the software really quite confusing.

Post by Chris Travers
But in addition I would like to see what the community thinks. What
do you think we need to do to pull things back together and bring the
project to the next level?

Regular releases are a good thing, otherwise you quickly get into a
position where a release gets delayed again and again for changes.

I'm working on a new extensible framework in Perl which would be well
suited to this project. Unfortunately I'm limited in how much I can
release atm as I plan for it to be the basis of my Phd when I complete
my current MSc. Hopefully in the next year or so I'll be in a position
where I can put more out.


Lyle

[ario]

I'm very happily using LSMB in its current version and state and will be
grateful with any improvement or future version.

Thanks for the great work!
It is a really useful engine, as 'the fat controller' would say :)

Post by Chris Travers
Hi all;
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released. Development may
appear to have slowed. Public discussions become less frequent...
For the last few years, LedgerSMB has achieved significant growth.
Some of that growth has come at an organizational cost and for that I
apologize to the community. Now I have to try to help put the
organizational stuff back together.
In reality, far from being quiet, LedgerSMB 1.3 has had a huge amount
of commissioned work done on it, not only for the core system (where
the customer/vendor management, reconciliation, and payment interfaces
have been completely rewritten) but also in areas of addons for fixed
asset handling, template transactions, so forth. We have eliminated a
lot of performance bottlenecks for larger databases, and provided a
much higher level of security than previous versions. This has been a
very ambitious project and we are much better off for it.
I would like to propose a few specific directional approaches and get
feedback from the community before proceeding.
1) Getting 1.3 out the door.
2) Focusing heavily on community building
3) Trying to build partnerships with other open source business
projects (perhaps GNU Med and others?)
The first is a regular beta release schedule for 1.3... Maybe every
other Tuesday?
There are some committed fixes for 1.2 which have not made it into a
release. I would like to release this as soon as possible. However,
given the fact that bug reports have slowed, I think it is likely that
it is not likely that 1.2 will see another release absent developing
problems like issues caused by new versions of Perl.
I'd also like to encourage anyone who is interested in contributing to
start looking heavily at 1.3. This is a place where you can earn a
name in the CONTRIBUTORS file, or possibly even commit privileges.
But in addition I would like to see what the community thinks. What
do you think we need to do to pull things back together and bring the
project to the next level?
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Ledger-smb-users mailing list
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users

[Adrian Levi]

Post by Chris Travers
Hi all;
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released.  Development may
appear to have slowed. Public discussions become less frequent...

I installed and tinkered with LSMB 2 years ago but was coerced
(forced) into using a proprietory accounting solution MYOB.
Over the last 2 years we have paid for support to the tune of
$750/year + the cost of purchasing the software (approx $3000).
I realise that no software is 'free', you still have to maintain and
upgrade, but the biggest hurdle I have to switching from our MYOB to
LSMB is a payrole function.

Is there a payrole function in the works, what would it cost me to
have one written?

Watching progress in LSMB with interest.

Adrian

[Chris Travers]

Post by Adrian Levi
Is there a payrole function in the works, what would it cost me to
have one written?
Watching progress in LSMB with interest.

Well, payroll is a nightmare because of so many national and local
requirements. I have the basics of a database structure written but
would really need specific requirements for a specific location before
I could contemplate putting something into place.

Where are you located? What payroll taxes etc, do you have? Where
can I find info on local deductions and requirements?

Best Wishes,
Chris Travers

[Adrian Levi]

Post by Chris Travers

Post by Adrian Levi
Is there a payrole function in the works, what would it cost me to
have one written?
Watching progress in LSMB with interest.

Well, payroll is a nightmare because of so many national and local
requirements.  I have the basics of a database structure written but
would really need specific requirements for a specific location before
I could contemplate putting something into place.

I could well imagine, I had already started thinking about the
differences between different national codes...
I am in Australia, Queensland specifically, here is a link to the tax tables.
http://www.ato.gov.au/businesses/content.aspx?doc=/content/33283.htm
*We also pay Superannuation at a minimum 9% on ordinary hours only
(not including overtime), if you earn $400 or more per week.
*Holiday accrual is calculated at approx 2 hours per week calcuated
pro rata on what is actually worked (ordinary hours).
Most other things are specified in Federal or State awards for
specific job types.

I'll ask our accountant if there is a specific place that all this
information can be gleaned.

Adrian

[mail]

We were looking to develop a payroll module for Washington State a few
years back. But we were waiting for the improved 1.3 architecture before
starting, and it took too long -- now our shop is pretty firmly focused
on Drupal development.

Post by Adrian Levi

Post by Chris Travers

Post by Adrian Levi
Is there a payrole function in the works, what would it cost me to
have one written?
Watching progress in LSMB with interest.

Well, payroll is a nightmare because of so many national and local
requirements. I have the basics of a database structure written but
would really need specific requirements for a specific location before
I could contemplate putting something into place.

I could well imagine, I had already started thinking about the
differences between different national codes...
I am in Australia, Queensland specifically, here is a link to the tax tables.
http://www.ato.gov.au/businesses/content.aspx?doc=/content/33283.htm
*We also pay Superannuation at a minimum 9% on ordinary hours only
(not including overtime), if you earn $400 or more per week.
*Holiday accrual is calculated at approx 2 hours per week calcuated
pro rata on what is actually worked (ordinary hours).
Most other things are specified in Federal or State awards for
specific job types.
I'll ask our accountant if there is a specific place that all this
information can be gleaned.
Adrian

[Joshua Berkus]

Chris,

Post by Chris Travers
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released. Development may
appear to have slowed. Public discussions become less frequent...

FWIW, this is normal for projects approaching their first Big Release. The answer is in the future to figure out how to break stuff up into more frequent, smaller releases. But I've seen this on a dozen projects I'm on.

[John Locke]

Hi, Chris,

Thank you for all your hard work on LedgerSMB, I really appreciate the
time and effort you continue to put into it.

I'm very glad to hear this call for help, and for community involvement.
I've been having a growing frustration myself at the slow pace of
development, how far 1.3 still has to go before it's really ready for
production use, and how there have been a series of several developers
who get active in LSMB, contribute some good stuff, and then seem to
disappear, leaving only you still active. What happened to the rest of
the core team?

I volunteered to take over the web site several months ago, bring it up
to date, do some things that would be quite easy for us as a Drupal shop
to make it not look like a dead project. While the spam comments are now
gone, so are all comments, making the site look particularly stale with
the last post over a year ago. Others have also stepped up to volunteer
time/effort in helping that grow. And nothing's happened.

It would be great if the other core team members were busily working
away on the project behind the scenes. But... they're not. In the past
year I see 5 commits by "aurynn_cmd" and the rest are all Chris. Time
for a new core team?

I hate to be a whiner here, but trying to work with LSMB 1.3 has been
frustrating. Stupid bugs on just about every action you try to do. Chris
does a great job of responding to them when you report them, and
accepting patches -- I see credits to half a dozen non-core contributors
in the commit log. But if Chris is doing all the work, it's hard to see
how this project is any more viable than SQL-Ledger, which I abandoned
years ago. If I could find another solid open source web-based
accounting system, I would've jumped ship a while back.

What needs to happen to LSMB is for it to open up more widely to
contributors. I would suggest moving the code development to github --
allowing for much easier contributions from non-core team members, as
well as allowing the community to vet patches instead of it all landing
on Chris's overloaded shoulders.

I think Chris's priorities are right on -- but the biggest problem with
#1 is that it's very painful to actually use 1.3 right now. It's a major
step back in functionality, with a few nice exceptions. If you don't
have some good developer knowledge available, you really can't use it in
production -- I'm finding I have to go into the database on a regular
basis to fix things. It's not ready for non-developers to use -- which
means it's hard to get the feedback from regular users to make it ready,
because there are very few developers who have businesses that need the
kind of accounting system LSMB provides, and are willing to put up with it.

So I really think #2 is on target -- the few of us who do fit that
description -- developers with real accounting needs who are willing to
put up with unstable/broken releases and contribute fixes -- need to be
drawn more into the community, not ignored until they go away.

If the other core team members are not contributing code, not
contributing documentation, not fostering a stronger community,
maintaining the web site, doing something to help the project grow, why
are they still on the core team? Get out of the way and get some fresh
blood in there.

If Erik, Luke, Lyle, Jeff, David Mora, Lacey, Alexey and anyone else who
is contributing on a regular basis were recruited to the core team and
encouraged to actually commit fixes, I think we'd get #1 in usable shape
a lot more quickly. And if Chris got back on IRC and played more of a
mentor role, getting people up to speed and removing road blocks dealing
with this code base, that would help too. An issue queue that people
actually use seems like another fundamental infrastructure bit that's
missing (something we could easily add to the Drupal site if we could
access it).

Cheers,
John Locke
http://freelock.com

Post by Chris Travers
Hi all;
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released. Development may
appear to have slowed. Public discussions become less frequent...
For the last few years, LedgerSMB has achieved significant growth.
Some of that growth has come at an organizational cost and for that I
apologize to the community. Now I have to try to help put the
organizational stuff back together.
In reality, far from being quiet, LedgerSMB 1.3 has had a huge amount
of commissioned work done on it, not only for the core system (where
the customer/vendor management, reconciliation, and payment interfaces
have been completely rewritten) but also in areas of addons for fixed
asset handling, template transactions, so forth. We have eliminated a
lot of performance bottlenecks for larger databases, and provided a
much higher level of security than previous versions. This has been a
very ambitious project and we are much better off for it.
I would like to propose a few specific directional approaches and get
feedback from the community before proceeding.
1) Getting 1.3 out the door.
2) Focusing heavily on community building
3) Trying to build partnerships with other open source business
projects (perhaps GNU Med and others?)
The first is a regular beta release schedule for 1.3... Maybe every
other Tuesday?
There are some committed fixes for 1.2 which have not made it into a
release. I would like to release this as soon as possible. However,
given the fact that bug reports have slowed, I think it is likely that
it is not likely that 1.2 will see another release absent developing
problems like issues caused by new versions of Perl.
I'd also like to encourage anyone who is interested in contributing to
start looking heavily at 1.3. This is a place where you can earn a
name in the CONTRIBUTORS file, or possibly even commit privileges.
But in addition I would like to see what the community thinks. What
do you think we need to do to pull things back together and bring the
project to the next level?
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Ledger-smb-users mailing list
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users

[Luke]

Post by John Locke
Thank you for all your hard work on LedgerSMB, I really appreciate the
time and effort you continue to put into it.

+1!

Post by John Locke
I hate to be a whiner here, but trying to work with LSMB 1.3 has been
frustrating. Stupid bugs on just about every action you try to do. Chris
does a great job of responding to them when you report them, and
accepting patches -- I see credits to half a dozen non-core contributors
in the commit log. But if Chris is doing all the work, it's hard to see
how this project is any more viable than SQL-Ledger, which I abandoned

The most common complaint I see is about installation. If the thing can
not be installed smoothly in a variety of situations and configurations,
nothing else matters.
Sour the user experience out the door, and nothing else will be
forgivable, and interest in even trying it will remain at a very low
level.
Installation issues should be priority #1 for the first new beta release.

It may be harsh, but I have very little faith that 1.3 can actually make
it out the door, or if it does, that it will be something the users have
any great interest in. I have felt that way for over a year now. I had
started getting interested with the prospects for 2.0, but quickly lost
that when I realized that there was an insistence in putting out 1.3. It
has become slogware, despite all the good work that has been put into it.

Maybe that's our fault for not being more involved; maybe it's the core
team's for not letting the community be more involved. It certainly has
to relate to Chris being the only primary code developer. There's only so
much that one person can do.

Post by John Locke
What needs to happen to LSMB is for it to open up more widely to
contributors. I would suggest moving the code development to github --

That suggestion has been made, again and again. There seems a certain
reluctance on the part of the core team. Maybe grounded, maybe not--I
don't know the reasons.

Post by John Locke
I think Chris's priorities are right on -- but the biggest problem with
#1 is that it's very painful to actually use 1.3 right now. It's a major
step back in functionality, with a few nice exceptions. If you don't
have some good developer knowledge available, you really can't use it in
production -- I'm finding I have to go into the database on a regular
basis to fix things. It's not ready for non-developers to use -- which
means it's hard to get the feedback from regular users to make it ready,
because there are very few developers who have businesses that need the
kind of accounting system LSMB provides, and are willing to put up with it.

That would be me. I need the functionality, but I'm also a single
individual, trying to run two businesses. I can devote a little time to
helping to debug my accounting system, yes, but when I don't believe in
the product, it's hard to get up any interest in bothering.
Especially when 1.2, while not perfect, works so reliably, and 1.3 offers
very little that I *need*.

Post by John Locke
So I really think #2 is on target -- the few of us who do fit that
description -- developers with real accounting needs who are willing to
put up with unstable/broken releases and contribute fixes -- need to be
drawn more into the community, not ignored until they go away.

If there is no excitement among the development types that this is a
product that will actually see a release, work, and be useful, not as just
an intermediate step, how can they build interest in the wider community
of users, who just want something that works?

(I do not claim to be a developer, having never contributed code other
than in templates, and that minor)

Post by John Locke
If Erik, Luke, Lyle, Jeff, David Mora, Lacey, Alexey and anyone else who
is contributing on a regular basis were recruited to the core team and

Let us not forget Armaghan Saqib, one of the most obvious choices for
recruitment to the core team (assuming interest).

Luke

[o1bigtenor]

Post by John Locke
Thank you for all your hard work on LedgerSMB, I really appreciate the
time and effort you continue to put into it.

+1!

Post by John Locke
I hate to be a whiner here, but trying to work with LSMB 1.3 has been
frustrating. Stupid bugs on just about every action you try to do. Chris
does a great job of responding to them when you report them, and
accepting patches -- I see credits to half a dozen non-core contributors
in the commit log. But if Chris is doing all the work, it's hard to see
how this project is any more viable than SQL-Ledger, which I abandoned

The most common complaint I see is about installation.  If the thing can
not be installed smoothly in a variety of situations and configurations,
nothing else matters.
Sour the user experience out the door, and nothing else will be
forgivable, and interest in even trying it will remain at a very low
level.
Installation issues should be priority #1 for the first new beta release.

I tried myself to get LSMB going - - no joy.
I hired someone to help me get it going - - still left with lots of
issues after 15 hours of work by said individual.

I don't think I want something that's only 60seconds of work but when
the learning curve is a vertical line and the instructions presuppose
mastery of ALL things Linux - - well you just left out 99.99999% of
your potential users.

Many years ago I actually had the author of SQL-Ledger install it for
me - - it took him over 4 hours at that time (2003 IIRC).

I would agree that this is a major area needing change!

Darald

[Luke]

Post by Chris Travers
For the last few years, LedgerSMB has achieved significant growth.
Some of that growth has come at an organizational cost and for that I
apologize to the community. Now I have to try to help put the
organizational stuff back together.

We had the start of a discussion about that on the devel list a few months
ago/near the end of last year, did we not? There were some good ideas
there, although my own thinking may have revised a little since then.

Post by Chris Travers
1) Getting 1.3 out the door.

Agreed.

Post by Chris Travers
2) Focusing heavily on community building

Certainly. There's not much that can be done for the user community until
after 1.3 is fully released, and maybe not even until 2.0, but for the
developer part of the community, see John's earlier message.

Post by Chris Travers
3) Trying to build partnerships with other open source business
projects (perhaps GNU Med and others?)

Again, I agree, but what do we have to offer them? Your step 1, of beta
releases, doesn't solve the momentum problem. It may have, at one point,
but right now they would be partnering with a promise. I wouldn't, were I
them, unless they are in the same boat.
Right now, our only offering, is a retooled version of
SQL-Ledger, and a sort of working beta of our own version of the same
thing, which we say is better, but very possibly isn't.

Post by Chris Travers
The first is a regular beta release schedule for 1.3... Maybe every
other Tuesday?

Sounds good. It would sound better, if it was every two weeks, which
would reset the clock every time you released one, thus allowing them to
be released more frequently.
No point in releasing a beta, if you fix it three days later, and still
have people downloading and testing the old one, just so you can stick to
a good, but arbitrary, schedule.

Post by Chris Travers
There are some committed fixes for 1.2 which have not made it into a
release. I would like to release this as soon as possible. However,
given the fact that bug reports have slowed, I think it is likely that
it is not likely that 1.2 will see another release absent developing
problems like issues caused by new versions of Perl.

Until you release a full version of 1.3, it is likely that you'll still
have many users on 1.2. I'm sorry to say it, but because of the track
record, holding out for 1.3 and not bothering to fix bugs found in 1.2
after the next release, seems like just another way the user base will be
disinclined to support the project in the future.

I'll say it again. Until 1.2 can actually be replaced with something
full, that works, that isn't an iffy prospect, and that isn't a beta, the
only real way to keep users (not developers, or people like me with a foot
in both camps) interested, is to maintain the flagship product (I.E. 1.2)
up until the last minute, as if it was the only product. That's annoying,
yes, but I think necessary.

You think 1.3 might get out of beta soon, then great - none of the above
matters.
But I believe you have thought that before, and life has a way of changing
what we think into "oh yeah, remember when we thought that?".

Saying that 1.2 will probably not see another release after the next one,
serves only to make those of us who trust it, and more importantly, don't
trust 1.3, wonder if maintaining 1.2 as a separate project, might be a
good idea.

(That was proposed privately to me, last time you said something about
stopping updates for 1.2, by someone who is more than capable of doing the
job.
I don't actually want to see that happen, because it only serves to take
away from the future of the project (which is 2.0). But the more noises
that are made about ending 1.2, before 1.3 is out the door, the more
those who think along those lines, will have cause to do so.)

Post by Chris Travers
But in addition I would like to see what the community thinks. What
do you think we need to do to pull things back together and bring the
project to the next level?

Fix *all* install problems with 1.3.
No other development matters until that happens. If it breaks again with
a future beta, then fine, but so far every other person who posts about
having installed 1.3, has a problem doing it, or immediately after it.
(I am generalizing, of course.)

What's left to do on 1.3? What things don't work but need to before a
release?
What things can be fixed after a release?
What features need to be added?

If you have to, relax your standards for 1.3 a little. If there are
features which are proving difficult, and they aren't required for major
operations, disable them in the official version, announce them as pending
and do subreleases to add them.

(Obviously, I'm not exactly up to date on what is and isn't working in the
latest versions of 1.3. Last time I pulled a copy was probably over a
year ago.)

Luke

[Chris Travers]

Hi Luke

Post by Luke
Until you release a full version of 1.3, it is likely that you'll still
have many users on 1.2.  I'm sorry to say it, but because of the track
record, holding out for 1.3 and not bothering to fix bugs found in 1.2
after the next release, seems like just another way the user base will be
disinclined to support the project in the future.
I'll say it again.  Until 1.2 can actually be replaced with something
full, that works, that isn't an iffy prospect, and that isn't a beta, the
only real way to keep users (not developers, or people like me with a foot
in both camps) interested, is to maintain the flagship product (I.E. 1.2)
up until the last minute, as if it was the only product.  That's annoying,
yes, but I think necessary.

Actually I have been rethinking this....

The fact is there are still a few bugs that occasionally turn up in
1.2. Not often but it happens. These releases are likely to still be
few and far between but there are a few outstanding bugs so at least
two more releases.

The point is that the release cycle of 1.2 is likely to continue to
slow down over time. That part hasn't changed.

Best Wishes,
Chris Travers

[Erik Huelsmann]

Hi Chris,

Thanks for taking the time to write down what your ideas are about
the future direction of the project! And thanks for your continued
support of the project too.

Post by Chris Travers
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released.  Development may
appear to have slowed. Public discussions become less frequent...

[David Mora]

Hey guys and Chris.

I know I've been absent from the project, but i want to share a few
thoughts. First off, I want to thank you for all the effort on the
project, both 1.2 and 1.3. And for all the support I received while I
was contributing to the project.

After a year+ of development, and the investment of some resources, I
decided I needed to drop it. One of the main reasons I quit was that
the milestones and deadlines started to get farther. And as someone
on the list already said, i started to see post about 2.0 while 1.3
was not even out. So it seemed that all the hard work was in vain.

One of the main reasons i started to code 1.3 was to offer my
customers a secure alternative to a fork of sql-ledger we built.
However, we never really tested 1.3 in a production environment since
it wasn't ready. So i had to direct my coders to support our fork
while 1.3 was out and a lot of business opportunities were lost.

I have to say that i really like and love the project. And i would be
willing to contribute with some code/ideas/translation/coffee/anything
to speed the process of 1.3 being released. Please let me know if my
help is wanted/required to make 1.3 see the light.

Best regards.

David Mora

Post by Erik Huelsmann
Hi Chris,
Thanks for taking the time to write  down what your ideas are about
the future direction of the project! And thanks for your continued
support of the project too.

Post by Chris Travers
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released.  Development may
appear to have slowed. Public discussions become less frequent...

[Luke]

On Wed, 18 May 2011, Erik Huelsmann wrote:

[Chris Travers]

[Luke]

probably a good idea to find a mode where releases get only big enough
to address a small number of specific issues (and the regular bug
fixes) on the point releases. That might satisfy only a small group of
current users, but the continued development could easily attract new
users too. That would be a net benefit.

Question: How should we look at getting rid of the old code, post 1.3?

I will trust that you are not talking about 2.0 here. Because down that
way lies madness, at least if 1.3 is ever to happen.

Why not start phasing out (by rewriting) SL/old code, during the
sub-releases of 1.3?
After the main release of 1.3.0, set a list of things to be rewritten. As
bugs are fixed, etc., and new versions are released, the replacement code
can be incorporated with no real notice to the users.

Maybe by the time it gets to 1.3.20 or so, it will be purified.

That would be my suggestion.

Internal dependencies will have to be figured out for each section to be
replaced, and a nightmare it will be, but if you plan to port any of it
forward in bulk, then doing it slowly may be the best way.

That said, sadly, since we already know that the plan for 2.X is for a
new codebase (or was, at least), I doubt many will be willing to do the
work.

So ultimately, maybe my suggestion should be to just leave it alone if it
works, and replace it if it don't.

Luke

[Luke]

Post by Luke
Why not start phasing out (by rewriting) SL/old code, during the
sub-releases of 1.3?
After the main release of 1.3.0, set a list of things to be rewritten. As
bugs are fixed, etc., and new versions are released, the replacement code
can be incorporated with no real notice to the users.

I should add, because it may effect my view of things: I'm
not exactly committed to the idea that no new features or functionality
can be added between major releases.

If it looks like a new thing after, then it's a new major release.
However, if a search feature is added, a report gets some new
capabilities, or a new report or document type is added, I do not see that
as a bad thing at all. It may require that the manuals need to be updated
more frequently, but they do now, anyway.

Gradual improvement until you need to change something huge.

Making it modular? Definitely a major release.
Adding a new API? Possibly a new major release, but maybe not if that's
the only thing that changed.
Restoring features that existed in 1.2, but which didn't make it in to
1.3.0? Minor release.

Just my $.02.

As a result, even if something needs to be taken out of 1.3.0 for now in
order to make it work for release, we can add it back at 1.3.2 or
something.

Luke

[Chris Travers]

probably a good idea to find a mode where releases get only big enough
to address a small number of specific issues (and the regular bug
fixes) on the point releases. That might satisfy only a small group of
current users, but the continued development could easily attract new
users too. That would be a net benefit.

Question:  How should we look at getting rid of the old code, post 1.3?

I will trust that you are not talking about 2.0 here.  Because down that
way lies madness, at least if 1.3 is ever to happen.
Why not start phasing out (by rewriting) SL/old code, during the
sub-releases of 1.3?

Eek. that means replacing 1000+ line files in the middle of a stable
branch..... Not really thrilled about that even if we reconsider the
policy on feature freezes and I'd object to that because I think it is
important that people be able to get bugfix-only releases.

However, one thing I am adding with 1.3 is the ability to do add-ons
which replace or extend functionality in 1.3. This is an area where a
lot of this could be done. The problems however occur when trying to
bring more sanity to the database schema, since those really shouldn't
be in stable branches if we can avoid it.

After the main release of 1.3.0, set a list of things to be rewritten.  As
bugs are fixed, etc., and new versions are released, the replacement code
can be incorporated with no real notice to the users.

Given the changes that are probably needed, "no real notice" is
probably a bad idea..... Better to do it as add-ons if possible, and
then at some point look at a minimal 2.0 build.....

Best Wishes,
Chris Travers

[Luke]

Post by Chris Travers

Post by Luke

probably a good idea to find a mode where releases get only big enough
to address a small number of specific issues (and the regular bug
fixes) on the point releases. That might satisfy only a small group of
current users, but the continued development could easily attract new
users too. That would be a net benefit.

Question:  How should we look at getting rid of the old code, post 1.3?

Why not start phasing out (by rewriting) SL/old code, during the
sub-releases of 1.3?

Eek. that means replacing 1000+ line files in the middle of a stable
branch..... Not really thrilled about that even if we reconsider the

Well then, my answer is: do nothing.
When the major version after 1.3 happens, don't reuse legacy code. Most
of it would have to change anyway, so start from scratch unless you decide
instead to do a 1.4.

Post by Chris Travers
policy on feature freezes and I'd object to that because I think it is
important that people be able to get bugfix-only releases.

You think that, but do your people?:) I personally don't think the
project is mature enough to support the policy. It's one thing in the
case of, say, Drupal, where most "features" are provided modularly; and
the only thing to contrast it with is the previous, worse, major version;
but here, with the loss of features that existed in the parent version, it
doesn't seem wise.
(I'm taking John's word about stuff that's missing, as the last time I
tried to install 1.3 was quite a long time ago)

Luke

[Erik Huelsmann]

Hi All,

1)  Getting 1.3 out the door.

To me, this means being able to develop using the customers model,
differentiating between companies and people. To John Locke this seems
to mean the a stable Reconciliation interface. What does this mean to
others?

1.  Installable by the majority.
2.  All primary features exposed to users, working without significant bugs
in standard use cases.

I would agree with both these.  Also upgrade scripts working from 1.2
without significant problems there.

Exactly. One of the things I try to stick to is installing packages
from my distro's packaging system. Currently, the instructions to get
the right packages from Debian/Fedora/<whatever> are missing. This
makes maintenance harder and upgrading is no longer "just working"
from the distro. It's not the highest priority, but to me it's
something that definately counts as a plus-points when I have several
options to consider.

probably a good idea to find a mode where releases get only big enough
to address a small number of specific issues (and the regular bug
fixes) on the point releases. That might satisfy only a small group of
current users, but the continued development could easily attract new
users too. That would be a net benefit.

Y! E! S!  Exactly that.

Question:  How should we look at getting rid of the old code, post 1.3?

My response: slowly. Really: I think the 1.3 phase tells us that the
LSMB users would rather see progress going on than large periods
without releases. Other developers have expressed loss of interest due
to the fact that the next milestone was too far away.

I'm seeing the same thing with the development of Subversion itself
(I'm a committer): when a release cycle takes too long, people who
don't have an immediate interest in the main feature of the release
loose interest in contributing because "their" contributions will be
held up by the "main feature" not getting out.

To me, it looks like we need much more project activity in order to
get to 1.3 and further. I'm getting the idea that people get nervous
when post-1.3 subjects are being touched. To be honest this doesn't
look like it's the best time to plan anything beyond 1.3 yet, other
than what the those decisions which help determine the scope of 1.3
itself.

Really, whether the next step of "old code elimination" gets named
1.3.4 or 1.4 is ultimately a bikeshed from a users perspective, isn't
it? The fact that the code needs to be eradicated still remains. Let's
choose a way which inspires a broad range of people to contribute to
the project in one way or another.

What's required is a good overview of what's keeping 1.3 from becoming
final. Both David and John indicated that in their mails. If it's up
to me, we follow John's advice and use the bug tracker in SourceForge
(or create one in launchpad, or whereever) and fill that with all the
issues we can find. Then we find people to help fixing them and
testing the solutions.

For now, maybe we should stay away from workflow discussions, since
ultimately, workflow is a preference, meaning there are as many
workflow requirements as there are LSMB users:-) You already see that
in the other thread where I proposed a change to the AR posting
workflow to fix an issue my colleague is running into. As far as we do
need to have workflow discussions in order to get 1.3 out, I think we
need a very strict scope: minimal change to the current code base, no
"blue sky" discussions of how it could become in 2.0.


With respect to "2.0", we use it in the Subversion project as a
container for "the release where we're allowed to break all backward
compatible and do whatever we want". Many things are put in that
release until someone comes along to figure out how to do it in a
backward compatible way.

Maybe 2.0 should be a vision and the 1.x releases should be steps in
that direction. Maybe you'll get there. Maybe not. But in the process,
LSMB will get lots better. At least, that's the idea. I completely
agree with Luke in this respect: gradual improvement with regular
releases are the way to go. Every release will be important to some
users, every release will be a milestone of achievement to nearly all
contributors.


To me it looks we need to enumerate the things we consider "1.3
material" and put those into an issue/request tracker. Then, on top of
that we file all bugs we encounter, classifying them as 1.3-blocker or
not, working only on whatever is blocking 1.3.

Then I have 2 questions:

1. what should be considered 1.3 material?
Answering my own question from other mails in this thread:
-> Well tested web interface
-> Working reports and queries
-> Easy installation
-> Easier migration from 1.2.*
2. How do we make sure we'll make enough progress to interest more contributors?
(i.e. if this all needs to go through Chris, that by itself is
probably a huge throttle on progress)


Bye,
Erik.

[Luke]

Post by Erik Huelsmann

1)  Getting 1.3 out the door.

To me, this means being able to develop using the customers model,
differentiating between companies and people. To John Locke this seems
to mean the a stable Reconciliation interface. What does this mean to
others?

1.  Installable by the majority.
2.  All primary features exposed to users, working without significant bugs
in standard use cases.

[3.] Also upgrade scripts working from 1.2
without significant problems there.

4. Documentation, both user and code.

3 and 4 should probably be flipped in priority.

Post by Erik Huelsmann
Exactly. One of the things I try to stick to is installing packages
from my distro's packaging system. Currently, the instructions to get
the right packages from Debian/Fedora/<whatever> are missing. This
makes maintenance harder and upgrading is no longer "just working"
from the distro. It's not the highest priority, but to me it's
something that definitely counts as a plus-points when I have several
options to consider.

I plan to work on the Debian/Ubuntu side of the packaging requirements, or
at least the necessary packages to install, once the next beta comes out.
I will need to figure it out for myself, so no reason not to write it
down, unless someone beats me to it.

Post by Erik Huelsmann

Question:  How should we look at getting rid of the old code, post 1.3?

My response: slowly. Really: I think the 1.3 phase tells us that the

That was why I suggested phasing it out over the 1.3 lifecycle. But Chris
seems to think that's highly impractical, and he would know better than
anyone.

Since I think the next big version is supposed to be coded from the ground
up, my next suggestion is and was: do nothing. Nobody will want to
rewrite code that is going to be tossed or rewritten anyway, when the
current code, while objectionable, does work.
Unless we really do go to a more incremental release model, and the
version after 1.3 becomes 1.4, instead of the monolithic 2.0 which is
supposed to be all kinds a different.

Post by Erik Huelsmann
I'm seeing the same thing with the development of Subversion itself
(I'm a committer): when a release cycle takes too long, people who
don't have an immediate interest in the main feature of the release
loose interest in contributing because "their" contributions will be
held up by the "main feature" not getting out.

That's why I want to see us off of this bug fix only for an entire version
series model. Well, there's nothing wrong with that, actually,
but we're miserly about when the next version series starts, so what you
describe happens.

Bug fixes in third level versions, features in second level versions, and
major, user-visible rewrites in first level versions, maybe?
With second level versions coming as often as six months, if some new
feature becomes available?

Post by Erik Huelsmann
[.] I'm getting the idea that people get nervous
when post-1.3 subjects are being touched. To be honest this doesn't

I think it causes more a sense of futility than nervousness.
1.3 doesn't look so good in the light of what 2.0 was supposed to be.
However, we are committed to 1.3, and the more we talk about 2.0 and big
future plans, before 1.3 comes out, the less working on 1.3 looks like a
good use of time. So yeah, let's stop talking about it.:)

If we do go to a more rapid series release cycle, however, and go to 1.4,
then 1.5, and so on, I think a lot of that pressure goes away. We may
need to do it for community's sake, if nothing else.
Doing so will dramatically change the landscape for 2.0 and beyond, I
think, and 1.3 suddenly starts looking like a step in the right direction,
instead of as just a bridge to the next big thing.

These years-long feature freezes are deadly, as is the quest for
approximate perfection in each major version. We can never get the
latter, so we should not have the former.

If we can put 1.3 together and actually release it, with a willingness to
release 1.4 the next time a new feature comes along, with bug fixes in the
meantime, we solve several problems. Maybe we cause others, but it's
on-going progress, public on-going progress.

Post by Erik Huelsmann
to me, we follow John's advice and use the bug tracker in SourceForge
(or create one in launchpad, or wherever) and fill that with all the

I think John was suggesting putting one on the ledgersmb.org website. We
should just upgrade that thing to Drupal 7, and revamp it some. If John
is willing to do the work, why not let him?
If we need a team for it, I'd be willing to go in, but I don't care, as
long as stuff starts happening.

Post by Erik Huelsmann
To me it looks we need to enumerate the things we consider "1.3
material" and put those into an issue/request tracker. Then, on top of
that we file all bugs we encounter, classifying them as 1.3-blocker or
not, working only on whatever is blocking 1.3.

I like it, particularly if you are including features in this.

As an aside, I do support moving to git. I know it better, and from what
I've seen, it is easier to get up and running for someone new.

But I would put that behind getting back on track with beta releases,
installation fixes, and documentation efforts.

Although, it would not have to be behind, if we could appoint some
individuals to head up some of these efforts, and keep them on track,
running them in parallel.
Even if Chris has to be involved with all of them in a support
capacity for a while, having others coordinating individual efforts is
still going to make it easier on him, assuming he wants that.

Luke

[Chris Travers]

Hi Luke;

First, thanks for your thoughts here. They are valued.

Post by Luke
3 and 4 should probably be flipped in priority.

First, documentation is a fairly wide field. I think we can break it
down into three areas:

1) User documentation
2) Technical documentation
3) Code documentation

Code documentation is something we have put a lot of work into
throughout the 1.3 release cycle. We do need to go through and review
it again to ensure there isn't a lot that is missing or out of date,
but there is a LOT of documentation available now in that area.
Really to be effective code documentation needs to be a part of the
development cycle and we have striven to do that. It's not quite
where we want it yet but it's coming along fast.

There are also some clear gaps in our code documentation and it's
worth considering that we need to think carefully about how to address
these. It would be good to start another thread on this topic. I
will do that shortly.

For the others, what is needed is to go through the manual and review
everything, adding new sections where appropriate and editing old
ones. In general, most of the manual applies consistently between 1.2
and 1.3, so this is less of a huge job than it seems to be.

Post by Luke

Post by Erik Huelsmann
Exactly. One of the things I try to stick to is installing packages
from my distro's packaging system. Currently, the instructions to get
the right packages from Debian/Fedora/<whatever> are missing. This
makes maintenance harder and upgrading is no longer "just working"
from the distro. It's not the highest priority, but to me it's
something that definitely counts as a plus-points when I have several
options to consider.

I plan to work on the Debian/Ubuntu side of the packaging requirements, or
at least the necessary packages to install, once the next beta comes out.
I will need to figure it out for myself, so no reason not to write it down,
unless someone beats me to it.

Ok. Let me make a suggestion here in that it may be good to work off
of trunk when this comes out so we can fix any problems you run into.
Also if any patches need to be applied to the program, if those could
be submitted so we can store them in the main repo, that would be
helpful.

Post by Luke

Post by Erik Huelsmann

Question:  How should we look at getting rid of the old code, post 1.3?

My response: slowly. Really: I think the 1.3 phase tells us that the

That was why I suggested phasing it out over the 1.3 lifecycle.  But Chris
seems to think that's highly impractical, and he would know better than
anyone.
Since I think the next big version is supposed to be coded from the ground
up, my next suggestion is and was: do nothing.  Nobody will want to rewrite
code that is going to be tossed or rewritten anyway, when the current code,
while objectionable, does work.
Unless we really do go to a more incremental release model, and the version
after 1.3 becomes 1.4, instead of the monolithic 2.0 which is supposed to be
all kinds a different.

Ok, so how about a different approach:

1) Stable branches of addons and main programs are bug-fix only.
2) Addons (official patches, additional modules, etc) have their own
sub-repositories, and can have multiple stable releases against a
stable branch of LSMB.

This allows us to tackle a lot of the old code replacement through
addons, which could be more easily ported to 2.0 without the
likelihood of accidently pushing bugs onto users during upgrades of
stable branches.

Post by Luke

Post by Erik Huelsmann
I'm seeing the same thing with the development of Subversion itself
(I'm a committer): when a release cycle takes  too long, people who
don't have an immediate interest in the main feature of the release
loose interest in contributing because "their" contributions will be
held up by the "main feature" not getting out.

That's why I want to see us off of this bug fix only for an entire version
series model.  Well, there's nothing wrong with that, actually, but we're
miserly about when the next version series starts, so what you describe
happens.

Or at least partly off it. I agree it's not working so well in some
ways and those ways need to be addressed.

Post by Luke
If we do go to a more rapid series release cycle, however, and go to 1.4,
then 1.5, and so on, I think a lot of that pressure goes away.  We may need
to do it for community's sake, if nothing else.
Doing so will dramatically change the landscape for 2.0 and beyond, I think,
and 1.3 suddenly starts looking like a step in the right direction, instead
of as just a bridge to the next big thing.

I guess my question to you is where you think such an addon model
would fall short?

obviously there are a few areas we cannot gracefully handle with
addons. These include the massive refactoring of the
AR/AP/GL/invoice/oe/orderitems tables that need to be done. We can
still, however, partially accomplish this in addons.

Best Wishes,
Chris Travers

[Luke]

Post by Chris Travers
1) Stable branches of addons and main programs are bug-fix only.
2) Addons (official patches, additional modules, etc) have their own
sub-repositories, and can have multiple stable releases against a
stable branch of LSMB.
This allows us to tackle a lot of the old code replacement through
addons, which could be more easily ported to 2.0 without the
likelihood of accidently pushing bugs onto users during upgrades of
stable branches.

[.]

Post by Chris Travers
I guess my question to you is where you think such an addon model
would fall short?

I don't know if it would. I haven't seen it in action, so don't know what
its capabilities are, nor how far it goes to replacing what's running.

It doesn't sound like it would be able to make database changes any more
likely, and I think at least some of the moving forward will require them.

If you are stating categorically that there are no schema changes we can
make without significantly altering the user experience, in ways that are
more than adding features with addons would do, and/or that we can't do
any incremental schema changes, then maybe addons will be sufficient.

Luke

[Chris Travers]

I don't know if it would.  I haven't seen it in action, so don't know what
its capabilities are, nor how far it goes to replacing what's running.
It doesn't sound like it would be able to make database changes any more
likely, and I think at least some of the moving forward will require them.
If you are stating categorically that there are no schema changes we can
make without significantly altering the user experience, in ways that are
more than adding features with addons would do, and/or that we can't do
any incremental schema changes, then maybe addons will be sufficient.

I think that the limitation would be on replacing the current schema.....

However, new versions could be developed parallel, for example, take
the template transaction addon (svn
https://ledger-smb.svn.sourceforge.net/svnroot/ledger-smb/addons/1.3/templatetrans/trunk).
This includes what is essentially an embryo of what I would hope the
basic structure of 2.0's financial transaction schema would be. We
can do this because template transactions never show up on financial
reports. This means that when we are ready to replace the financial
engine, we already have a working schema and routines for saving
transactions.

Right now that module does not do everything that would be needed for
a future version's financial schema... It doesn't handle invoices
with parts attached for example. But for now you can save AR/AP
transactions and journal entries in a new schema which will eventually
get more stuff pushed to it.

Does this make sense?

Best Wishes,
Chris Travers

[l***@clustersolutions.net]

Has LedgerSMB a way to deal with the good ole COGS error with reversing
sales invoice? I imagine this fundamental error is something important to
users who offer tangible goods. One suggestion in the past was to restock
items under AP, but that's not as easy as it seems. For a small business
doing more than a mil annual revenue this plus reconcilation can be
discouraging for sure. To me, payroll is not as important as outsourcing
it is not that expensive, and having a simple way to import the payroll GL
entries would be great plus. Tim

[Luke]

Post by Chris Travers
For the others, what is needed is to go through the manual and review
everything, adding new sections where appropriate and editing old
ones. In general, most of the manual applies consistently between 1.2
and 1.3, so this is less of a huge job than it seems to be.

I am willing to undertake the first stages of it, once the installation
problems are history.

Luke

[Chris Bennett]

Post by Chris Travers
2) Technical documentation
3) Code documentation

User documentation is fine but coders need to have clear documentation for code.
Changing each items documentation as it changes needs to be a requirement for that coder.
No documentation for your function change, can't submit.
This is not a difficult requirement for a couple of changes in a module

Post by Chris Travers
Code documentation is something we have put a lot of work into
throughout the 1.3 release cycle. We do need to go through and review
it again to ensure there isn't a lot that is missing or out of date,
but there is a LOT of documentation available now in that area.
Really to be effective code documentation needs to be a part of the
development cycle and we have striven to do that. It's not quite
where we want it yet but it's coming along fast.
There are also some clear gaps in our code documentation and it's
worth considering that we need to think carefully about how to address
these. It would be good to start another thread on this topic. I
will do that shortly.

Yes, I see that there is some code documention inline, but there is really no detailed man page
describing "the big picture". It would make getting started on coding much easier to see the
overall workflow for a variety of common tasks (from a coding point of view, not a users point of
view).
That's a writen document, a nice review.

A tougher project would be a nice sort of visual flow chart like this but graphic:
sub A($this, $that) -> sub B(etc) -> module whatever sub C

Chris, you would know this overflow best, but only giving a very rough start and handing off all
of the details to others would let this get done fast.
You have been doing almost too much of the work. It is very difficult to try and not do the detail
work but pass it on to others to struggle through. I learned this lesson the hard way with my
business. Get some people started and let them fly or fail. But don't handhold. Very hard to do :)

I can code, but I would prefer to concentrate on the small picture, this "thing" needs to be
changed
I will give it go.

I agree with the comments on SQL COMMENTS on the other thread.
Get all those in place, require them for any new functions (like I said above).
Then make an overall man page for interflow.
A flowchart could also be helpful.

It is pretty easy to get basics out of database. Just need to see general overflow and all will
be "clearish"

Thanks,
Chris Bennett

[Chris Travers]

On Fri, May 20, 2011 at 7:20 AM, Chris Bennett

Post by Chris Bennett

2)  Technical documentation
3)  Code documentation

User documentation is fine but coders need to have clear documentation for code.
Changing each items documentation as it changes needs to be a requirement for that coder.
No documentation for your function change, can't submit.
This is not a difficult requirement for a couple of changes in a module

In cases where there is a change to desired behavior I would agree
with you. In cases where the change is still in line with
documentation, I am not sure that's necessary.

Also I don't think it's practical to fully document the functions in
the files in bin/ (that we inherited from SL) because quite frankly
the code is such a mess that troubleshooting usually has to begin with
a new review of the code. For the files in scripts, I am also not
sure that documenting every function as a function call is helpful
simply because 90% of every piece there is going to be boilerplate.
Maybe it would be better to put in Perl comments (rather than POD)
identifying which screens are rendered by which functions, and have
the flow documented in the technical documentation of the manual.

Post by Chris Bennett

Code documentation is something we have put a lot of work into
throughout the 1.3 release cycle.  We do need to go through and review
it again to ensure there isn't a lot that is missing or out of date,
but there is a LOT of documentation available now in that area.
Really to be effective code documentation needs to be a part of the
development cycle and we have striven to do that.  It's not quite
where we want it yet but it's coming along fast.
There are also some clear gaps in our code documentation and it's
worth considering that we need to think carefully about how to address
these.  It would be good to start another thread on this topic.  I
will do that shortly.

Yes, I see that there is some code documention inline, but there is really no detailed man page
describing "the big picture". It would make getting started on coding much easier to see the
overall workflow for a variety of common tasks (from a coding point of view, not a users point of
view).
That's a writen document, a nice review.

There's a code overview in the manual but it's a little out of date
and needs to be revisited and expanded.

Post by Chris Bennett
sub A($this, $that) -> sub B(etc) -> module whatever sub C
Chris, you would know this overflow best, but only giving a very rough start and handing off all
of the details to others would let this get done fast.

What would folks need from me?

Post by Chris Bennett
You have been doing almost too much of the work. It is very difficult to try and not do the detail
work but pass it on to others to struggle through. I learned this lesson the hard way with  my
business. Get some people started and let them fly or fail. But don't handhold. Very hard to do :)
I can code, but I would prefer to concentrate on the small picture, this "thing" needs to be
changed
I will give it  go.
I agree with the comments on SQL COMMENTS on the other thread.
Get all those in place, require them for any new functions (like I said above).
Then make an overall man page for interflow.
A flowchart could also be helpful.

What do you think a flow chart should cover? Are we talking about an
architecture diagram?

Post by Chris Bennett
It is pretty easy to get basics out of database. Just need to see general overflow and all will
be "clearish"

Thanks for the thoughts :-)

Best Wishes,
Chris Travers

[Chris Bennett]

Post by Chris Travers
In cases where there is a change to desired behavior I would agree
with you. In cases where the change is still in line with
documentation, I am not sure that's necessary.
Also I don't think it's practical to fully document the functions in
the files in bin/ (that we inherited from SL) because quite frankly
the code is such a mess that troubleshooting usually has to begin with
a new review of the code. For the files in scripts, I am also not
sure that documenting every function as a function call is helpful
simply because 90% of every piece there is going to be boilerplate.
Maybe it would be better to put in Perl comments (rather than POD)
identifying which screens are rendered by which functions, and have
the flow documented in the technical documentation of the manual.

Yes, that makes sense.

Post by Chris Travers

Post by Chris Bennett
Yes, I see that there is some code documention inline, but there is really no detailed man page
describing "the big picture". It would make getting started on coding much easier to see the
overall workflow for a variety of common tasks (from a coding point of view, not a users point of
view).
That's a writen document, a nice review.

There's a code overview in the manual but it's a little out of date
and needs to be revisited and expanded.

Yes, that too, but I meant something more like a flowchart, but a written guide.
Some people see "pictures" better others see "words" better.
Its a fair task to do, but bit by bit. Should be easy to update, later, much later :).

Post by Chris Travers

Post by Chris Bennett
sub A($this, $that) -> sub B(etc) -> module whatever sub C
Chris, you would know this overflow best, but only giving a very rough start and handing off all
of the details to others would let this get done fast.

What would folks need from me?

Well, for me, I want enough to get a good feel overall. Its boring to dig and dig to just get that first clue. After that, I think its fun to work on making crappy or badly done code good.

In my opinion, something fairly rough is enough. Outline a few workflows, in loose detail.
Digging into details requires opening an editor, at this end
If its not enough, we can ask more questions.

Post by Chris Travers

Post by Chris Bennett
You have been doing almost too much of the work. It is very difficult to try and not do the detail
work but pass it on to others to struggle through. I learned this lesson the hard way with ?my
business. Get some people started and let them fly or fail. But don't handhold. Very hard to do :)
I can code, but I would prefer to concentrate on the small picture, this "thing" needs to be
changed
I will give it ?go.
I agree with the comments on SQL COMMENTS on the other thread.
Get all those in place, require them for any new functions (like I said above).
Then make an overall man page for interflow.
A flowchart could also be helpful.

What do you think a flow chart should cover? Are we talking about an
architecture diagram?

Basically. But come up with it in digestable pieces.
Others can make "zoom" details later.

Post by Chris Travers

Post by Chris Bennett
It is pretty easy to get basics out of database. Just need to see general overflow and all will
be "clearish"

Thanks for the thoughts :-)
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Ledger-smb-users mailing list
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users

[Luke]

Post by Erik Huelsmann

1)  Getting 1.3 out the door.

To me, this means being able to develop using the customers model,
differentiating between companies and people. To John Locke this seems
to mean the a stable Reconciliation interface. What does this mean to
others?

1.  Installable by the majority.
2.  All primary features exposed to users, working without significant bugs
in standard use cases.

[3.] Also upgrade scripts working from 1.2
without significant problems there.

4. Documentation, both user and code.

3 and 4 should probably be flipped in priority.

Post by Erik Huelsmann
Exactly. One of the things I try to stick to is installing packages
from my distro's packaging system. Currently, the instructions to get
the right packages from Debian/Fedora/<whatever> are missing. This
makes maintenance harder and upgrading is no longer "just working"
from the distro. It's not the highest priority, but to me it's
something that definitely counts as a plus-points when I have several
options to consider.

I plan to work on the Debian/Ubuntu side of the packaging requirements, or
at least the necessary packages to install, once the next beta comes out.
I will need to figure it out for myself, so no reason not to write it
down, unless someone beats me to it.

Post by Erik Huelsmann

Question:  How should we look at getting rid of the old code, post 1.3?

My response: slowly. Really: I think the 1.3 phase tells us that the

That was why I suggested phasing it out over the 1.3 lifecycle. But Chris
seems to think that's highly impractical, and he would know better than
anyone.

Since I think the next big version is supposed to be coded from the ground
up, my next suggestion is and was: do nothing. Nobody will want to
rewrite code that is going to be tossed or rewritten anyway, when the
current code, while objectionable, does work.
Unless we really do go to a more incremental release model, and the
version after 1.3 becomes 1.4, instead of the monolithic 2.0 which is
supposed to be all kinds a different.

Post by Erik Huelsmann
I'm seeing the same thing with the development of Subversion itself
(I'm a committer): when a release cycle takes too long, people who
don't have an immediate interest in the main feature of the release
loose interest in contributing because "their" contributions will be
held up by the "main feature" not getting out.

That's why I want to see us off of this bug fix only for an entire version
series model. Well, there's nothing wrong with that, actually,
but we're miserly about when the next version series starts, so what you
describe happens.

Bug fixes in third level versions, features in second level versions, and
major, user-visible rewrites in first level versions, maybe?
With second level versions coming as often as six months, if some new
feature becomes available?

Post by Erik Huelsmann
[.] I'm getting the idea that people get nervous
when post-1.3 subjects are being touched. To be honest this doesn't

I think it causes more a sense of futility than nervousness.
1.3 doesn't look so good in the light of what 2.0 was supposed to be.
However, we are committed to 1.3, and the more we talk about 2.0 and big
future plans, before 1.3 comes out, the less working on 1.3 looks like a
good use of time. So yeah, let's stop talking about it.:)

If we do go to a more rapid series release cycle, however, and go to 1.4,
then 1.5, and so on, I think a lot of that pressure goes away. We may
need to do it for community's sake, if nothing else.
Doing so will dramatically change the landscape for 2.0 and beyond, I
think, and 1.3 suddenly starts looking like a step in the right direction,
instead of as just a bridge to the next big thing.

These years-long feature freezes are deadly, as is the quest for
approximate perfection in each major version. We can never get the
latter, so we should not have the former.

If we can put 1.3 together and actually release it, with a willingness to
release 1.4 the next time a new feature comes along, with bug fixes in the
meantime, we solve several problems. Maybe we cause others, but it's
on-going progress, public on-going progress.

Post by Erik Huelsmann
to me, we follow John's advice and use the bug tracker in SourceForge
(or create one in launchpad, or wherever) and fill that with all the

I think John was suggesting putting one on the ledgersmb.org website. We
should just upgrade that thing to Drupal 7, and revamp it some. If John
is willing to do the work, why not let him?
If we need a team for it, I'd be willing to go in, but I don't care, as
long as stuff starts happening.

Post by Erik Huelsmann
To me it looks we need to enumerate the things we consider "1.3
material" and put those into an issue/request tracker. Then, on top of
that we file all bugs we encounter, classifying them as 1.3-blocker or
not, working only on whatever is blocking 1.3.

I like it, particularly if you are including features in this.

As an aside, I do support moving to git. I know it better, and from what
I've seen, it is easier to get up and running for someone new.

But I would put that behind getting back on track with beta releases,
installation fixes, and documentation efforts.

Although, it would not have to be behind, if we could appoint some
individuals to head up some of these efforts, and keep them on track,
running them in parallel.
Even if Chris has to be involved with all of them in a support
capacity for a while, having others coordinating individual efforts is
still going to make it easier on him, assuming he wants that.

Luke

[John Locke]

To me, this means being able to develop using the customers model,
differentiating between companies and people. To John Locke this seems
to mean the a stable Reconciliation interface. What does this mean to
others?

Huh, that's kind of funny, reconciliation is only important to me
because the reconciliation in 1.2 so totally screwed up our books we've
basically had to start over. The reconciliation in 1.2 is the same as
SQL-Ledger -- which leads to very easy clearing of the wrong
transactions, and lots of other issues that have my bookkeepers in fits.

Based on the promise of improved reconciliation, we decided to jump in
and try 1.3. And while we've hit bugs there and in the new voucher
payment/receipt system, overall they are a big improvement. And I do
have more confidence in our numbers, with the extra consistency checking
going on.

But... nearly everything else has been a drastic step backwards in
usability/consistency.

Of all the people reading this list: what does "getting 1.3" mean to
you? Do you feel like it's an improvement? If so, why, or if not, why
not?

Basically, it means getting the current good stuff from 1.3 combined
with interfaces that actually work, at least to the level that 1.2 did.

That means for all the variety of reports out there, that you can pick a
period from the drop-down date selectors and actually get transactions
from that period. That means showing an aging report with subtotals for
30, 60, 90 days, not just one big total for all outstanding. That means
a trial balance or income statement that lets you compare two dates.
That means being able to actually find a customer when you type their
name in the customer search, or have a working sales tax report. When
you hit the email button before posting an invoice, you can fill out and
email and click send, and then get an error and lose your message. After
posting/re-opening an invoice, when you enter an email address into the
field different from what's in the customer record, it ignores what you
type and sends to the customer record.

The hard stuff is done, and I do have more confidence in the underlying
system than I did with 1.2. But for regular users, it's a huge step
backwards -- on pretty much every screen, there are fields and buttons
that do not do what they say they do, do not work the way they did in
1.2, and in many cases do not work at all.

These are all really pretty easy bugs to track down and squash -- but
there are a ton of them, and no issue queue that anybody pays attention
to to keep track of which ones have been done and what's remaining.
These would be great for developers wanting to get involved, learn the
code base, and lead their way up to more substantial contribution,
leaving Chris's time for the good stuff -- but there's no effort to
enlist developers to do this, or to facilitate those of us motivated to
get it working to actually get code into the code base. I've got a dozen
commits in my git repo that haven't made it into the release. I'm sure
Chris is as tired of getting bug reports from me as I am of sending them
to him in lieu of an issue tracker and broader active community.

I feel like I'm alone in using LSMB 1.3 in production -- I keep hitting
really basic bugs that prevent me from being able to get my books done,
and I'm sure would affect anybody else using the system. Again, we're
limping along, patching as we need to and have a moment, getting lots of
help from Chris -- but it's far from ready for production. To get there,
it needs more daring shops who can live with some pain to actually put
it into production, like me, so we can all start squashing these bugs --
and we need a way to get the fixes quickly shared with everyone else,
without Chris being a bottleneck.

After a year+ of development, and the investment of some resources, I
decided I needed to drop it. One of the main reasons I quit was that
the milestones and deadlines started to get farther. And as someone
on the list already said, i started to see post about 2.0 while 1.3
was not even out. So it seemed that all the hard work was in vain.

This captures the problem in a nutshell -- too much bikeshedding, not
enough actually getting working code. I've seen David and at least a
couple other contributors come in, make really substantial
contributions, and then get disillusioned by the lack of getting
something out the door and move on.

David, I'm glad to hear you're still willing to contribute. I hope this
discussion leads to enough change in the project to get a more robust
team put together. I'm certainly willing to contribute however I can,
and I can start by posting the patches we've been making to make it so
we can even use 1.3 to the devel list. I do think github is a better
platform than source forge, because then somebody more knowledgeable can
be an effective release manager and have a lot easier time accepting
contributions from a wide range of contributors while still being able
to easily review the incoming code. But if that's too much of a switch
right now, at least we should all start using the issue tracker we
already have on SourceForge, if nothing else. 4 bugs in there from 2010
(one from me, with no responses). None from 2011. And however the
project wants to do it, find some way to get more contributions going --
I think there are quite a few people on this list willing to contribute,
who are frustrated that it's not apparent how.

And yes, it's insanely hard to just get up and running... let alone
trying to upgrade from 1.2. I think those of us who have managed to get
there should be tackling the interface bugs that make it a usability
challenge, while Chris spends some time making that transition a bit
easier, get more developers to a point where they can contribute.

Cheers,
John

[Michael Richardson]

John> Huh, that's kind of funny, reconciliation is only important to
John> me because the reconciliation in 1.2 so totally screwed up our
John> books we've basically had to start over. The reconciliation in

Right, which is why I keep wanting to move forward, until I read:

John> I feel like I'm alone in using LSMB 1.3 in production -- I
John> keep hitting really basic bugs that prevent me from being able
John> to get my books done, and I'm sure would affect anybody else

and then I'm like... "okay, so do I have a set of books that are less
important" and ...

John> using the system. Again, we're limping along, patching as we
John> need to and have a moment, getting lots of help from Chris --
John> but it's far from ready for production. To get there, it needs
John> more daring shops who can live with some pain to actually put
John> it into production, like me, so we can all start squashing
John> these bugs -- and we need a way to get the fixes quickly
John> shared with everyone else, without Chris being a bottleneck.

okay, I promise to move sandelman.ca and credil.org up to 1.3 this
month!

[Nigel Titley]

Post by John Locke
I feel like I'm alone in using LSMB 1.3 in production -- I keep hitting
really basic bugs that prevent me from being able to get my books done,
and I'm sure would affect anybody else using the system. Again, we're
limping along, patching as we need to and have a moment, getting lots of
help from Chris -- but it's far from ready for production. To get there,
it needs more daring shops who can live with some pain to actually put
it into production, like me, so we can all start squashing these bugs --
and we need a way to get the fixes quickly shared with everyone else,
without Chris being a bottleneck.

I agree... I just haven't jumped into 1.3 in production use because I'm
certain that my business will come crashing down around my ears if I do.
I used to use Gnucash to run my business and the beta code was stable
enough that I felt confident in using it for production. Sure, there
were bugs, but nothing that undermined the fundamental coherence of the
accounts (because the gnucash accounting engine is rock solid and very
rarely tampered with). I left gnucash for LSMB because I was attracted
by the inventory and multicurrency business features of LSMB and in the
main they work very well. But the user interface is a crock. Sending out
invoices is a total nightmare. I have one staff member who works full
time on it. Importing bank data is another, again I have a part-timer
whose sole job is to load bank data manually.

I'd love to use 1.3 in production, but I really don't think I can at the
moment. I commit to doing some testing, but experience tells me that
testing only finds 50% of the bugs. The rest come out in actual
production use.

Nigel

[Chris Bennett]

I was lightly involved a good while back, but I had to basically close down my business for a while
to care for my handicapped mother.

[Luke]

Installation is too difficult
Since 1.3 is really just a development phase, I think this issue can be
put at a lower priority
than documentation, but not too low.

I think I disagree with that, at least somewhat, from two prospectives:

First, while 1.3 is a development phase as you say, the project is hanging
its hat on it. We *need* user support for 1.3. The next major release
may be five years from now, who knows.

Therefore, we need non-hard-core developers to start working with it
soonest. Advanced users, partial developers. There are people in the
open source community who will test stuff without documents, if they can
get it up and running. I think there are fewer who will test something
that is well documented, but is so broken that they can't even install it.

Second, If you can't install it, the documents, either development or user
side documentation, are only partially accurate.

If the process doesn't conform to the documents, then the documents are
meaningless. That's on the user side. On the developer side, for
documenting internals, it will be a lot easier for people other than Chris
to help with that, if it can be installed successfully and predictably.

I'd say they are close to equal, but I'd maybe put installation first.

Just my .02

Luke

[Chris Travers]

Installation is too difficult
Since 1.3 is really just a development phase, I think this issue can be
put at a lower priority
than documentation, but not too low.

So let me suggest a priority list at present:

1) First, I need to clear all bugs reported by current users of 1.3
in production. I have allocated time this weekend to work on a lot of
this.

2) We need good testing, feedback on two things:
a) Technical, back-end installation processes (make-based, etc,
maybe a custom make installdb target should be added?)
b) There are a couple of front-end to set up the database but not
sure how well it works. Once everyone is happy with the technical
back-end stuff, we need to focus on testing/fine tuning these.

3) Upgrade scripts

4) Update User Manual as appropriate

If others want to start on 2-3 while I work on 1, that would of course
be helpful. #4 may take some time and more familiarity with 1.3 than
the others.

Also, one point about addons in 1.3....

There are certain portions of the old code that I do not believe can
be reasonably and completely fixed using addons. Those will need to
wait for a future major release. However a lot of the old code can be
addressed this way, in addons that would not require tremendous
porting to work with future versions. Each addon can have its own
release cycle, with features added on each new release. This would
allow, for example, a project accounting addon to be released with new
features against LSMB 1.3, and users of the software could choose
whether or not to install these addons, taking advantage of new
features.

Two good examples of addons already commissioned and available for 1.3
are those for fixed asset tracking and depreciation, and those for
template transactions.

So I don't think we have to have an either/or approach regarding new
features in 1.3 stable.

Best Wishes.
Chris Travers

[Luke]

Where does a snapshot or beta release fit into that priority list?

[Chris Travers]

Post by Luke
Where does a snapshot or beta release fit into that priority list?

I would like to start regular snapshots, every two weeks (or other
schedule if others think there is a better plan) as a routine matter.
I don't think I can do this until at least next Tuesday.

Also I have to fix production issues as a top priority just as a
matter of commitment.....

Best Wishes,
Chris Travers

[Luke]

Post by Chris Travers

Post by Luke
Where does a snapshot or beta release fit into that priority list?

I would like to start regular snapshots, every two weeks (or other
schedule if others think there is a better plan) as a routine matter.
I don't think I can do this until at least next Tuesday.

Seems reasonable, if a bit ambitious.

[Philip Rhoades]

Chris,

Post by Chris Travers
Hi all;
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released. Development may
appear to have slowed. Public discussions become less frequent...
For the last few years, LedgerSMB has achieved significant growth.
Some of that growth has come at an organizational cost and for that I
apologize to the community. Now I have to try to help put the
organizational stuff back together.
In reality, far from being quiet, LedgerSMB 1.3 has had a huge amount
of commissioned work done on it, not only for the core system (where
the customer/vendor management, reconciliation, and payment interfaces
have been completely rewritten) but also in areas of addons for fixed
asset handling, template transactions, so forth. We have eliminated a
lot of performance bottlenecks for larger databases, and provided a
much higher level of security than previous versions. This has been a
very ambitious project and we are much better off for it.
I would like to propose a few specific directional approaches and get
feedback from the community before proceeding.
1) Getting 1.3 out the door.
2) Focusing heavily on community building
3) Trying to build partnerships with other open source business
projects (perhaps GNU Med and others?)
The first is a regular beta release schedule for 1.3... Maybe every
other Tuesday?
There are some committed fixes for 1.2 which have not made it into a
release. I would like to release this as soon as possible. However,
given the fact that bug reports have slowed, I think it is likely that
it is not likely that 1.2 will see another release absent developing
problems like issues caused by new versions of Perl.
I'd also like to encourage anyone who is interested in contributing to
start looking heavily at 1.3. This is a place where you can earn a
name in the CONTRIBUTORS file, or possibly even commit privileges.
But in addition I would like to see what the community thinks. What
do you think we need to do to pull things back together and bring the
project to the next level?

I have been meaning to post re whether 1.3 was still going or not . . so
your post is good timing.

I might summarise my position - I:

- am an ex-user of SQL-L

- have used 1.2 happily in the past on a now defunct company

- have a few uses for LSMB but have avoided installing 1.2 again
hoping that 1.3 would be available "soon"

- have attempted to install and debug 1.3 a couple of times

- would be in the category of a technical (but not a developer) user who
is happy to test new stuff and provide feedback

- would love to see LSMB vigorous and developing

- have looked at PostBooks but it seems overkill for what I want whereas
a solid and reliable LSMB 1.3 would be perfect for me

Regards,

Phil.

[Nigel Titley]

Post by Chris Travers
Hi all;
Many of you may be frustrated at the pace of development of LedgerSMB
and the fact that 1.3 has not yet been released. Development may
appear to have slowed. Public discussions become less frequent...

Like many others have commented, yes, the delay in getting 1.3 out of
the door has been frustrating. However, I appreciate that OS products
often suffer this road bump effect when a major release is coming up.

Post by Chris Travers
For the last few years, LedgerSMB has achieved significant growth.
Some of that growth has come at an organizational cost and for that I
apologize to the community. Now I have to try to help put the
organizational stuff back together.
In reality, far from being quiet, LedgerSMB 1.3 has had a huge amount
of commissioned work done on it, not only for the core system (where
the customer/vendor management, reconciliation, and payment interfaces
have been completely rewritten) but also in areas of addons for fixed
asset handling, template transactions, so forth. We have eliminated a
lot of performance bottlenecks for larger databases, and provided a
much higher level of security than previous versions. This has been a
very ambitious project and we are much better off for it.

As someone who has paid for some of this commissioned work (about 3
years ago) and not yet seen it appear in a release, I'm reserving
judgement. I've no doubt that a lot of work has been done but I'd really
like to see an update to the roadmap with a little more detail,
especially in the near future. Things may well be moving but one thing
I've learned over the years is that communication is king.

Post by Chris Travers
I would like to propose a few specific directional approaches and get
feedback from the community before proceeding.
1) Getting 1.3 out the door.

Fully agree... in particular I am looking forward to the improvements in
reconciliation, customer management and, dare I say it, bulk invoicing.

Post by Chris Travers
2) Focusing heavily on community building

This is vital. LedgerSMB seems to be teetering on the brink of becoming
moribund. Whether this is true or just seems to be true is neither here
nor there, if it *seems* to be true it will become so.

Post by Chris Travers
3) Trying to build partnerships with other open source business
projects (perhaps GNU Med and others?)

Yes... I have an operational bridge working between Oscommerce and
LedgerSMB that I'm happy to throw into the pot, especially once the
Ledgersmb RESTful interface comes out of the woodwork.

Post by Chris Travers
The first is a regular beta release schedule for 1.3... Maybe every
other Tuesday?

Sounds good.

Post by Chris Travers
There are some committed fixes for 1.2 which have not made it into a
release. I would like to release this as soon as possible. However,
given the fact that bug reports have slowed, I think it is likely that
it is not likely that 1.2 will see another release absent developing
problems like issues caused by new versions of Perl.

1.2 works perfectly adequately for our business at the moment. We
haven't seen any show stopper bugs for a very long time.

Post by Chris Travers
I'd also like to encourage anyone who is interested in contributing to
start looking heavily at 1.3. This is a place where you can earn a
name in the CONTRIBUTORS file, or possibly even commit privileges.

I'll get it downloaded and start trialling it...

Post by Chris Travers
But in addition I would like to see what the community thinks. What
do you think we need to do to pull things back together and bring the
project to the next level?

See above... we need to dispel the impression of moribundity that is
hanging around LedgerSMB at the moment. Fresh code attracts fresh ideas
and fresh developers.

Nigel

PS And thanks to all who have developed and continue to develop LSMB

[Håvard Sørli]

Post by Nigel Titley
Yes... I have an operational bridge working between Oscommerce and
LedgerSMB that I'm happy to throw into the pot, especially once the
Ledgersmb RESTful interface comes out of the woodwork.

I added this to the FAQ, hope it's ok:
www.ledgersmb.org/node/468190

H