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

Re: Future of LedgerSMB: Ideas and RFC

On Thu, 19 May 2011, Erik Huelsmann wrote:


I think the major priorities at this point need to be:
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.


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. 


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. 


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? 


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


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. 


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