Re: LedgerSMB companion projects (was: Light manufacturing modules....)

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

On 1/29/07, Jeff Kowalczyk <..hidden..> wrote:
> Jeff Gerritsen wrote:
> > I'm thinking about creating a sourceforge project to post the
> > information to and allowing for others comments?
>
> I think this would be an appropriate time to ask a question I've been
> holding: will the core LedgerSMB developers weigh in on what types of
> LedgerSMB-related projects they would consider allowing to use the (or a)
> repository on the eventual post-sourceforge LedgerSMB development servers?

This certainly has come up in the past.  I am not sure we have a
complete idea of how this is going to work yet.  I think we want to
get more of our own infrastructure developed and tested before opening
it up to other sub-projects, however.  I suspect that the next step
will probably to move the public email lists onto our own servers.
And we need to get our community CMS better developed.  And we still
don't have a public demo up yet.

> I think companion projects like Light Manufacturing Modules would be very
> well served to also run in the (or a) LedgerSMB Trac instance, for the
> same reasons of attracting developers, testers, and users to particpate in
> the sub project.

Personally, I think that a community architecture is going to require
more than just throwing Trac at the problem.  Especially from the
viewpoint of attracting users, I see a lot of needs we need to look at
(for example, online demos, etc).  I think we need an idea of how
feasable it is to meet all these needs before deciding on a solution.
> I would think that as long as a module's functionality has any possibility
> of being integrated with, or some code moved to, the LedgerSMB core, then
> the code base benefits by keeping that development process close to home.

Not quite sure I follow you.  I think it is important for the core
team to be available for input regardless of where the code is hosted,
and I suspect that this is more important than whether it is hosted by
us, by Google, or by Sourceforge.

> If it can be managed without impacting the core developers' operations, it
> would be very nice to have subprojects under a separate path within the
> same repository. Subversion seems to be able to use different authorization
> lists at different paths in the repository, and a Trac instance can
> apparently be rooted at various points in the repository.

I can see positives and negatives to this setup.  I personally think
we need to figure out first what the core project needs (and optimize
this), then we need to find out what companion projects need.  And we
need to bear in mind what our available infrastructure is.  I also
think that those positives and negatives are less important than the
importance in having a core team that is available to help companion
projects minimize foreward-compatibility issues.

Best Wishes,
Chris Travers