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