Re: Future of LedgerSMB: Ideas and RFC

[Erik Huelsmann <..hidden..>]

Hi All,

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