Re: Distributed LedgerSMB Development With DVCS - Git

["Chris Travers" <..hidden..>]

Before I add a couple of tiny nit-picks to Jeff's post I want to say
that I think that this could be a very good thing for the project.
This provides a way for people to create changes in a well-reviewed
way, provide more open development of patches, etc.

> * Putting the plaintext backup of the company database under
>  version control. At any time I can and do make snapshots, then
>  examine the diff to see how each LedgerSMB operation affects
>  the database tables.

BTW, a better idea would be to turn on statement logging and revision
control your logs :-)  database backups can be problematic for
revision control for a number of reasons including the dump order of
the rows.

If anyone needs to know how to do this, let me know :-)

>
> LedgerSMB Development and DVCS
> ==============================
>
> The LedgerSMB projet is organized around a team of core-devs,
> with exclusive commit priviledges to the centralized subversion
> repository hosted on Sourceforge.

Actually, we are organized around a core committee which is not
exactly equal to the committing members (though they currently are
equal in number).  One of the core committee members does not have
commit priv's and one non-core committee member does have commit
priv's.

The core committee's job is to run the project.  We also decide who
gets commit rights, what sort of infrastructure to run as part of the
core project, etc.  The committers job is to write the software.

I just want to also point out that the largest obstacle to getting
involved in the past in LedgerSMB has been the brittleness of the
inherited code.  As we are pulling this out, we are also finding that
we get a lot more involvement from other interested parties.  Hence
looking at this project will become more important as we move forward.

> Even more importantly, it will bring the important and eagerly
> anticipated work being done (such as the recent payment
> functionality by mighty-d) out into the collaborative space. This
> should help speed the collective work along, and improve its
> quality along the way.

This is an important benefit, and as we start to get more
contributions, it will likely become more important to have some sort
of a DVCS infrastructure.  In 1.0, I think we had two contributors
(Chris M and myself).  By 1.1, this number had grown substantially  By
1.2, this had grown again.  The development of 1.3 also has major
portions of it being written by people outside the core committee (one
of whom doesn't even have commit rights yet!).  I see this as an
important sign that the main barriers to involvement are going down,
so we may need some help keeping up.  DVCS technology can help with
that problem.

So I think that this is an important contribution, and one which will
probably become an increasingly important topic.

Best Wishes,
Chris Travers