Re: Future of LedgerSMB: Ideas and RFC

[Chris Travers <..hidden..>]

Hi Luke;

First, thanks for your thoughts here.  They are valued.
>
> 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.

>
>> 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.
>
>>> 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.

>
>> 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.

> 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