Re: Community supported releases WAS [Re: Properly edited OFBiz manuals]

[Andrew Sykes <an...@sykesdevelopment.com>]

Ian,

Yes, I'd agree, that's pretty fair comment, having used OfBiz from the
very early days, one of the things that has appealed to me is that there
always seemed to be a fairly clear idea of who the system was being
written for.

As you'll no doubt be aware OfBiz is a big and complex system, I'd hate
to see the code get even more complex in an effort to make it applicable
to those with less complex requirements (hope that makes sense!?).

As Jacopo mentioned a little while ago the territory you are talking
about is already pretty well staked out. At present for a smaller entity
to commit to OfBiz takes a lot of vision on the part of the person with
their hands on the purse strings but I have personally seen some of
these people make OfBiz a big success.

I'm not convinced that simply providing an installer etc would make
OfBiz much more accessible as you'd still need to wade through a never-
ending mass of options for every little thing you wanted to do, that
takes a lot of study, or input from an experienced OfBizer.

I do however see your point, and would love to see OfBiz become more
accessible, but I really think this would involve writing a lightweight
little brother with a lot of prescriptive OOTB pre-configuration.

- Andrew


On Wed, 2007-01-03 at 17:21 +0000, Ian McNulty wrote:
> Andrew (Sykes),
> 
> Might you not be putting the cart before the horse here?
> 
> Maybe the reason you have yet to encounter anyone who uses OFBiz in this 
> way is precisely because there are no automated installs you can use 
> straight out of the box. And if there were, you would!
> 
> The extra knowledge that comes from getting to grips with the 
> fundamentals may be worth its weight in gold in terms of deepening the 
> knowledge of the existing user base. But that does not prove that it is 
> not also the major obstacle to widening it.
> 
> Just because one proposition is true, does not necessarily mean that 
> others are not also equally true!
> 
> Ian
> 
> 
> Andrew Sykes wrote:
> > Andrew,
> >
> > Automated installs are probably a bad idea, because they assume you are
> > just going to use OfBiz straight out of the box.
> >
> > I am yet to come across anyone who uses OfBiz in this way unless it's a
> > very small hobby project of the like.
> >
> > I'd encourage people to do their best to get to grips with some of the
> > fundamentals of installing/modifying, the extra knowledge is worth its
> > weight in gold!
> >
> > - Andrew (Sykes)
> >
> > On Tue, 2007-01-02 at 11:07 +0000, Andrew Ballantine wrote:
> >   
> >> I second all of that and would like to add a request that each new release
> >> provides an automated installation procedure on MS Windows and one flavour
> >> of Linux, say Ubuntu 6.06.
> >>
> >> Kind regards,
> >>
> >> Andrew Ballantine
> >>
> >> -----Original Message-----
> >> From: Cameron Smith [mailto:cameron_ord_smith@yahoo.co.uk]
> >> Sent: 29 December 2006 09:42
> >> To: ofbiz-user@incubator.apache.org
> >> Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
> >> manuals]
> >>
> >>
> >> My 2 metical after following all the other arguments....  I would be happy
> >> to help with detailing and preparing the release procedures and regression
> >> tests (see below).
> >>
> >> 1. Goal of a Release
> >> I agree with David that it should provide a stable set of artifacts.  NOT
> >> just at the level of screens, but at the level of services and entities
> >> because almost everyone who deploys OFBiz customizes it in some way.  This
> >> is different from some end-user apps which periodically do a complete
> >> rewrite of the internals but keep the interface sufficiently recognizable so
> >> as not to alienate the customer base (ex. MS Office, Tomcat 3 -> 4 -> 5).
> >>
> >> OFBiz has a great advantage here because all core funcionality exposes an
> >> API which is basically the sum of the services and Entities involved, plus a
> >> few other standard config structures (ofbiz-component.xml and
> >> controller.xml). Therefore I believe we should structure our compatibility
> >> objectives around services and entities.  For instance, if we say that
> >> release B is "API backwards compatible" with release A, that means
> >> extensions which depended on services and/or entities from release A will
> >> still work with B.  Some of these services or entities may have added
> >> optional parameters or new nullable columns, just as long as they keep
> >> providing the old API.
> >>
> >> In contrast, if someone writes their extension to also depend on a certain
> >> Util class or simple-method, the releases make no compatibility guarantees
> >> here.
> >>
> >> For instance I am writing a module now, to do end-of-month VAT
> >> reconciliation according to Mozambican regulations.  It uses certain
> >> services in the accounting module as building blocks.  If a future release
> >> removed or altered the API of those services, I would be stuck.  If a future
> >> release added a few extra optional parameters to those services, I would not
> >> be forced to alter anything.
> >>
> >> 2. Release versioning policy and testing
> >> Based on the above discussion and also the contributions made thus far, I
> >> would suggest the following approach.
> >> a) We aim at ONE release per year, coming out every June or thereabouts.   I
> >> think it is better to have ONE deliverable per year and meet it than two or
> >> three which immediately slip.  The Ubuntu project has a larger community, a
> >> rich private backer (Mark Shuttleworth), started with a much more
> >> established set of release tools and procedures (from Debian), and still
> >> slipped Dapper from being 6.04 to 6.06.   Note that only 6.06 is LTS (long
> >> term support), and 6.10 is not.
> >>
> >> b) The SysPro argument for continuous updates is interesting but rings
> >> completely false with the target market I have in mind - small bricks and
> >> mortar commercial enterprises.  From my experience both in UK and MZ, these
> >> places know their businesses and once they have got ERP support for their
> >> core processes, they prefer to get on with business instead of constantly
> >> looking for new features.  They prefer to workaround minor feature
> >> incompatibilities than risk disruption and instability.
> >>
> >> c) So an annual release in the middle of each year gives us this rhythm:
> >>  *At the start of the year, start stabilizing any new or reworked
> >> functionality.
> >>  *In May or thereabouts, core commiters insitutue a freeze on big changes
> >> and only let in bugfixes
> >>  *In June, make the new branch, test it and commit fixes to the branch.
> >>  *End of June, version the branch and announce it as a release.
> >>  *At this point, commiters let big changes back into the trunk
> >>  *In parallel, the release maintainers do bugfixes ONLY on the release and
> >> merge them back into trunk wherever it makes sense.
> >>  *By December, anyone who takes the latest version of the release, should be
> >> guaranteed that it is pretty stable.  If they want any features they go for
> >> the SVN trunk.
> >>
> >> d) Using the definitions here: http://apr.apache.org/versioning.html
> >>  *A release from year N should be minor version compatible with the release
> >> from year N-1
> >>  *Once the release from year N is out, it should only suffer patch versions
> >>
> >> e) Testing.   David makes a good point about the vastness of OFBiz and the
> >> difficulty of guaranteeing that a certain version is stable.  I believe that
> >> in the long term, the only solution is to build up a suite of regression
> >> tests.  Its a lot of work but it is definitely worth it, for the security it
> >> gives you when refactoring.
> >>
> >> I believe we need to build up two layers of tests:
> >>  *Integration tests: black-box tests which test the APIs of all the services
> >> and entities.  I am already using the OFBiz TestContainer framework for
> >> this.  I suggested some tweaks to it a few months back but didn't get any
> >> feedback at that time.
> >>  *Web Tests: white box tests which exercise/simulate a browser and test core
> >> use cases (e.g. create invoice, receive order, etc, etc).  I am already
> >> using Watir for this but there are other frameworks.  I would be happy to
> >> write up a little tutorial for how to do this on the OFBiz wiki.
> >>
> >> 3. SVN policy
> >> I believe we SHOULD use branching, because it allows for a stable release in
> >> that it receives bugfixes ONLY, which can be backported to the trunk if
> >> necessary.  So basically at any one time, the community is supporting 3
> >> streams: the trunk + last release branch + upcoming release branch.
> >>
> >> 4. Modules
> >> I agree with David that we should NOT try to separate modules.  At most
> >> releasing framework and applications as two separate chunks, as David
> >> suggests, but I think even that is a secondary priority to having stable
> >> supported releases.   There are several reasons for this....
> >>  a) For Commercial ERPs, the "modules" are largely a way of justifying a
> >> larger bill to the client.  The boundaries between modules are often
> >> gerrymandered so that when you buy modules A and B, you have to buy C as
> >> well just because it has one little function that a "normal person" would
> >> say logically should be part of C.
> >>  b) OFBiz modules are largely structures to facilitate team development.
> >> They are not fully independent - there is a lot of interdependence at the
> >> entity and service level - and this is natural given that the whole point is
> >> an Integrated system.  Businesses are borne integrated and often
> >> departmentalize as a side-effect of growth.  Later on they spend huge
> >> efforts trying to reintegrate once more.
> >>  c) I don't believe the community is big enough to support the additional
> >> effort of unpicking, specifying and maintain "clean interfaces" and
> >> data-flow consistency between all the modules.  I believe that effort would
> >> be better spend stabilizing the APIs at service and entity level as
> >> discussed above.
> >>  d) David is right about the Linux packaging systems.  Whether RPM or DEB,
> >> they have a laudable ideal but in practice can make a nominally simple job
> >> inordinately complex.   So people have to write (very) clever helper tools
> >> on top of them (ex Synaptic on top of apt on top of dpkg on top of deb!!)
> >>
> >> 5. Documentation
> >> I agree with Torsten that we need to lower the cost of entry to OFBiz, but I
> >> also agree that we need to ask "lower the cost of entry to what?".
> >>
> >> In fact, contrary to what Jacopo suggests, I believe that there IS a set of
> >> core functions which I believe there is a huge target market for in much of
> >> the world, among people who could never afford SAP.  These functions are
> >> fairly consistent - and they don't need to come with "bells on".  And I
> >> would imagine its not a coincidence that OpenTAPS has chosen several of them
> >> as the focus for its Financials module.
> >>
> >> Basic Accounting (Journal Entry with separate Posting, Balance Sheet, Trial
> >> Balance, Data export to Excel)
> >> Client Account management (invoices, statements by age, payments, basic
> >> customer details)
> >> Supplier management (basic supplier details, invoices, statements by age,
> >> payments)
> >>
> >> A secondary set of priorities would be:
> >> Integration between Client/Supplier managament and accounting
> >> Payroll management
> >> Stocks mgt (warehouse, orders in and out)
> >> VAT or equivalent
> >>
> >> An alternative core set, which OFBiz seems to have been quite a sucess at in
> >> terms of actual installations, is an ecommerce store backed by limited stock
> >> management.
> >>
> >> A manual which had a first section dealing with the above issues, a second
> >> section dealing with setting up an ecommerce store, and a third section
> >> dealing with tech issues (basic setup, how to make a screen, and entity, a
> >> service, use the webtools etc), would be very handy.  My firm at least would
> >> buy a copy!!
> >>
> >> As for who produces the manuals, I believe that the "centralized, benevolent
> >> dictator" approach works better here than a free-for-all Wiki.  I reckon the
> >> best way to produce a core manual would be via some kind of commercialized
> >> approach - the Pragmatic Programmers  managed to cover their costs and a wee
> >> bit more this way.  Spring also has excellent documentation and books
> >> available.
> >>
> >> >From the posts I have seen on this list, there are several core committers
> >> who have the knowledge and explanatory ability to produce a decent book,
> >> with the support of a technical writer.  What these people don't have is
> >> "quality time" to sit down and write the fecker!  And they never will unless
> >> you attach an income stream to it.
> >>
> >> cameron
> >>
> >> ----- Original Message ----
> >> From: Jacopo Cappellato <ti...@sastau.it>
> >> To: ofbiz-user@incubator.apache.org
> >> Sent: Thursday, 28 December, 2006 11:09:27 AM
> >> Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
> >> manuals]
> >>
> >> David E Jones wrote:
> >>     
> >>> I guess it depends on what the goal of doing a release is. In my mind
> >>> the goal should be to create (over time...) a stable set of artifacts
> >>> that people can build and deploy on if they choose not to go with the
> >>> latest/greatest.
> >>>
> >>> What you're describing is interesting, but how is that any different
> >>> than just using the latest from SVN with a little timing based on
> >>> knowing what is going on added in, and keeping a list somewhere of all
> >>> non-backwards compatible changes and their revision numbers?
> >>>
> >>>       
> >> Yes, you have described pretty well what I'm suggesting; I'd only add to
> >> these that we should also create the upgrade services (and/or upgrade
> >> instructions) every time we commit a non-backwards compatible change in
> >> svn. As you said, this is not so different from what we are (implicitly)
> >> suggesting to do right now (as a best practice to stay up-to-date with
> >> the trunk) but I think that it would be nice if the community will
> >> officially support it for a few reasons:
> >>
> >> 1) it's often difficult for users to pick a 'stable' svn snapshot
> >> 2) it's often difficult for users to keep track of important changes
> >> between their revision and the trunk
> >> 3) since it is not so different from what we are suggesting right now,
> >> it will not add a huge cost maintaining these extra processes/releases
> >>
> >>     
> >>> On that last bit, whatever we do with the releases having an official
> >>> wiki page with all non-backward-compatible changes listed on it with the
> >>> revision number for each would be a good thing to do...
> >>>
> >>>       
> >> +1
> >>
> >>     
> >>> But, back to the main point: what is the goal of a release in your mind
> >>> (and in the mind of anyone else reading in too)?
> >>>
> >>>       
> >> I'd like to get the opinions from others too.
> >> Personally I think that releases (or release instructions/plans) should
> >> at least help users to keep their system/data in sync with the main
> >> trunk, minimizing the upgrade costs and simplifying the users' decisions
> >> (i.e. "should I upgrade now?").
> >> Of course it would also be great to have a real 'stable' releases (with
> >> patches for them etc...) as you are suggesting (and I really think we
> >> could implement the two approaches simultaneously since what I've
> >> proposed could be the basis of a real release management) but I'm not
> >> sure the community will really maintain them...
> >>
> >> Jacopo
> >>
> >>     
> >>> -David
> >>>
> >>>       
> >>
> >>
> >>
> >> Send instant messages to your online friends http://uk.messenger.yahoo.com
> >>
> >>
> >> --
> >> No virus found in this incoming message.
> >> Checked by AVG Free Edition.
> >> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
> >> 14:50
> >>
> >>
> >> --
> >> No virus found in this incoming message.
> >> Checked by AVG Free Edition.
> >> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
> >> 14:50
> >>
> >> --
> >> No virus found in this outgoing message.
> >> Checked by AVG Free Edition.
> >> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
> >> 14:50
> >>
> >>
> >>
> >> *****************************************************************
> >> This email has been checked by the altohiway Mailcontroller Service
> >> *****************************************************************
> >>     
> 
-- 
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com

Re: Community supported releases WAS [Re: Properly edited OFBiz manuals]

[Ian McNulty <ia...@mcnultymedia.co.uk>]

Andrew,

>
> As you'll no doubt be aware OfBiz is a big and complex system, I'd hate
> to see the code get even more complex in an effort to make it applicable
> to those with less complex requirements (hope that makes sense!?).
>   

It makes absolute sense and I couldn't agree more.

One of the criterion I would propose would be simplification at every level.

> As Jacopo mentioned a little while ago the territory you are talking
> about is already pretty well staked out.

It certainly is. And that's what Henry Ford thought too :)

>  At present for a smaller entity
> to commit to OfBiz takes a lot of vision on the part of the person with
> their hands on the purse strings but I have personally seen some of
> these people make OfBiz a big success.
>   

You've put your finger right on it. The person controlling the purse 
strings needs a lot of vision!

My proposition is to put some resources into making that less of a 
vision they have to generate themselves, and more a working model of 
exactly what that vision could be.

> I'm not convinced that simply providing an installer etc would make
> OfBiz much more accessible as you'd still need to wade through a never-
> ending mass of options for every little thing you wanted to do, that
> takes a lot of study, or input from an experienced OfBizer.
>   

I completely agree. Not the way to go at all.

But we already have excellent models of how it can work.

Firefox and Thunderbird are shining examples. OOTB. Does exactly what it 
says on the tin. Even your grandmother could learn how to use it!

But much more complicated installations like Apache, MySQL and even 
Linux have all been made accessible for installation and maintenance by 
engineers with basic back-street garage skills and a basic kit of tools 
at prices the average user might be able to afford.

> I do however see your point, and would love to see OfBiz become more
> accessible, but I really think this would involve writing a lightweight
> little brother with a lot of prescriptive OOTB pre-configuration.
>   

That may be true. But it also ought not be too difficult to do.

Much more important, in my view, is the organisation of whatever lies 
behind any kind of release.

If it goes wrong, who you gonna call? What kind of response will you 
get? How much will it cost? These are things most people need to know 
before they even think of opening the box.

That's the first point of contact with the interface.

If that can be made to run smooth as silk, then all the rest can fall 
nicely into place behind!

Ian

> - Andrew
>   



Andrew Sykes wrote:
> Ian,
>
> Yes, I'd agree, that's pretty fair comment, having used OfBiz from the
> very early days, one of the things that has appealed to me is that there
> always seemed to be a fairly clear idea of who the system was being
> written for.
>
> As you'll no doubt be aware OfBiz is a big and complex system, I'd hate
> to see the code get even more complex in an effort to make it applicable
> to those with less complex requirements (hope that makes sense!?).
>
> As Jacopo mentioned a little while ago the territory you are talking
> about is already pretty well staked out. At present for a smaller entity
> to commit to OfBiz takes a lot of vision on the part of the person with
> their hands on the purse strings but I have personally seen some of
> these people make OfBiz a big success.
>
> I'm not convinced that simply providing an installer etc would make
> OfBiz much more accessible as you'd still need to wade through a never-
> ending mass of options for every little thing you wanted to do, that
> takes a lot of study, or input from an experienced OfBizer.
>
> I do however see your point, and would love to see OfBiz become more
> accessible, but I really think this would involve writing a lightweight
> little brother with a lot of prescriptive OOTB pre-configuration.
>
> - Andrew
>
>
> On Wed, 2007-01-03 at 17:21 +0000, Ian McNulty wrote:
>   
>> Andrew (Sykes),
>>
>> Might you not be putting the cart before the horse here?
>>
>> Maybe the reason you have yet to encounter anyone who uses OFBiz in this 
>> way is precisely because there are no automated installs you can use 
>> straight out of the box. And if there were, you would!
>>
>> The extra knowledge that comes from getting to grips with the 
>> fundamentals may be worth its weight in gold in terms of deepening the 
>> knowledge of the existing user base. But that does not prove that it is 
>> not also the major obstacle to widening it.
>>
>> Just because one proposition is true, does not necessarily mean that 
>> others are not also equally true!
>>
>> Ian
>>
>>
>> Andrew Sykes wrote:
>>     
>>> Andrew,
>>>
>>> Automated installs are probably a bad idea, because they assume you are
>>> just going to use OfBiz straight out of the box.
>>>
>>> I am yet to come across anyone who uses OfBiz in this way unless it's a
>>> very small hobby project of the like.
>>>
>>> I'd encourage people to do their best to get to grips with some of the
>>> fundamentals of installing/modifying, the extra knowledge is worth its
>>> weight in gold!
>>>
>>> - Andrew (Sykes)
>>>
>>> On Tue, 2007-01-02 at 11:07 +0000, Andrew Ballantine wrote:
>>>   
>>>       
>>>> I second all of that and would like to add a request that each new release
>>>> provides an automated installation procedure on MS Windows and one flavour
>>>> of Linux, say Ubuntu 6.06.
>>>>
>>>> Kind regards,
>>>>
>>>> Andrew Ballantine
>>>>
>>>> -----Original Message-----
>>>> From: Cameron Smith [mailto:cameron_ord_smith@yahoo.co.uk]
>>>> Sent: 29 December 2006 09:42
>>>> To: ofbiz-user@incubator.apache.org
>>>> Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
>>>> manuals]
>>>>
>>>>
>>>> My 2 metical after following all the other arguments....  I would be happy
>>>> to help with detailing and preparing the release procedures and regression
>>>> tests (see below).
>>>>
>>>> 1. Goal of a Release
>>>> I agree with David that it should provide a stable set of artifacts.  NOT
>>>> just at the level of screens, but at the level of services and entities
>>>> because almost everyone who deploys OFBiz customizes it in some way.  This
>>>> is different from some end-user apps which periodically do a complete
>>>> rewrite of the internals but keep the interface sufficiently recognizable so
>>>> as not to alienate the customer base (ex. MS Office, Tomcat 3 -> 4 -> 5).
>>>>
>>>> OFBiz has a great advantage here because all core funcionality exposes an
>>>> API which is basically the sum of the services and Entities involved, plus a
>>>> few other standard config structures (ofbiz-component.xml and
>>>> controller.xml). Therefore I believe we should structure our compatibility
>>>> objectives around services and entities.  For instance, if we say that
>>>> release B is "API backwards compatible" with release A, that means
>>>> extensions which depended on services and/or entities from release A will
>>>> still work with B.  Some of these services or entities may have added
>>>> optional parameters or new nullable columns, just as long as they keep
>>>> providing the old API.
>>>>
>>>> In contrast, if someone writes their extension to also depend on a certain
>>>> Util class or simple-method, the releases make no compatibility guarantees
>>>> here.
>>>>
>>>> For instance I am writing a module now, to do end-of-month VAT
>>>> reconciliation according to Mozambican regulations.  It uses certain
>>>> services in the accounting module as building blocks.  If a future release
>>>> removed or altered the API of those services, I would be stuck.  If a future
>>>> release added a few extra optional parameters to those services, I would not
>>>> be forced to alter anything.
>>>>
>>>> 2. Release versioning policy and testing
>>>> Based on the above discussion and also the contributions made thus far, I
>>>> would suggest the following approach.
>>>> a) We aim at ONE release per year, coming out every June or thereabouts.   I
>>>> think it is better to have ONE deliverable per year and meet it than two or
>>>> three which immediately slip.  The Ubuntu project has a larger community, a
>>>> rich private backer (Mark Shuttleworth), started with a much more
>>>> established set of release tools and procedures (from Debian), and still
>>>> slipped Dapper from being 6.04 to 6.06.   Note that only 6.06 is LTS (long
>>>> term support), and 6.10 is not.
>>>>
>>>> b) The SysPro argument for continuous updates is interesting but rings
>>>> completely false with the target market I have in mind - small bricks and
>>>> mortar commercial enterprises.  From my experience both in UK and MZ, these
>>>> places know their businesses and once they have got ERP support for their
>>>> core processes, they prefer to get on with business instead of constantly
>>>> looking for new features.  They prefer to workaround minor feature
>>>> incompatibilities than risk disruption and instability.
>>>>
>>>> c) So an annual release in the middle of each year gives us this rhythm:
>>>>  *At the start of the year, start stabilizing any new or reworked
>>>> functionality.
>>>>  *In May or thereabouts, core commiters insitutue a freeze on big changes
>>>> and only let in bugfixes
>>>>  *In June, make the new branch, test it and commit fixes to the branch.
>>>>  *End of June, version the branch and announce it as a release.
>>>>  *At this point, commiters let big changes back into the trunk
>>>>  *In parallel, the release maintainers do bugfixes ONLY on the release and
>>>> merge them back into trunk wherever it makes sense.
>>>>  *By December, anyone who takes the latest version of the release, should be
>>>> guaranteed that it is pretty stable.  If they want any features they go for
>>>> the SVN trunk.
>>>>
>>>> d) Using the definitions here: http://apr.apache.org/versioning.html
>>>>  *A release from year N should be minor version compatible with the release
>>>> from year N-1
>>>>  *Once the release from year N is out, it should only suffer patch versions
>>>>
>>>> e) Testing.   David makes a good point about the vastness of OFBiz and the
>>>> difficulty of guaranteeing that a certain version is stable.  I believe that
>>>> in the long term, the only solution is to build up a suite of regression
>>>> tests.  Its a lot of work but it is definitely worth it, for the security it
>>>> gives you when refactoring.
>>>>
>>>> I believe we need to build up two layers of tests:
>>>>  *Integration tests: black-box tests which test the APIs of all the services
>>>> and entities.  I am already using the OFBiz TestContainer framework for
>>>> this.  I suggested some tweaks to it a few months back but didn't get any
>>>> feedback at that time.
>>>>  *Web Tests: white box tests which exercise/simulate a browser and test core
>>>> use cases (e.g. create invoice, receive order, etc, etc).  I am already
>>>> using Watir for this but there are other frameworks.  I would be happy to
>>>> write up a little tutorial for how to do this on the OFBiz wiki.
>>>>
>>>> 3. SVN policy
>>>> I believe we SHOULD use branching, because it allows for a stable release in
>>>> that it receives bugfixes ONLY, which can be backported to the trunk if
>>>> necessary.  So basically at any one time, the community is supporting 3
>>>> streams: the trunk + last release branch + upcoming release branch.
>>>>
>>>> 4. Modules
>>>> I agree with David that we should NOT try to separate modules.  At most
>>>> releasing framework and applications as two separate chunks, as David
>>>> suggests, but I think even that is a secondary priority to having stable
>>>> supported releases.   There are several reasons for this....
>>>>  a) For Commercial ERPs, the "modules" are largely a way of justifying a
>>>> larger bill to the client.  The boundaries between modules are often
>>>> gerrymandered so that when you buy modules A and B, you have to buy C as
>>>> well just because it has one little function that a "normal person" would
>>>> say logically should be part of C.
>>>>  b) OFBiz modules are largely structures to facilitate team development.
>>>> They are not fully independent - there is a lot of interdependence at the
>>>> entity and service level - and this is natural given that the whole point is
>>>> an Integrated system.  Businesses are borne integrated and often
>>>> departmentalize as a side-effect of growth.  Later on they spend huge
>>>> efforts trying to reintegrate once more.
>>>>  c) I don't believe the community is big enough to support the additional
>>>> effort of unpicking, specifying and maintain "clean interfaces" and
>>>> data-flow consistency between all the modules.  I believe that effort would
>>>> be better spend stabilizing the APIs at service and entity level as
>>>> discussed above.
>>>>  d) David is right about the Linux packaging systems.  Whether RPM or DEB,
>>>> they have a laudable ideal but in practice can make a nominally simple job
>>>> inordinately complex.   So people have to write (very) clever helper tools
>>>> on top of them (ex Synaptic on top of apt on top of dpkg on top of deb!!)
>>>>
>>>> 5. Documentation
>>>> I agree with Torsten that we need to lower the cost of entry to OFBiz, but I
>>>> also agree that we need to ask "lower the cost of entry to what?".
>>>>
>>>> In fact, contrary to what Jacopo suggests, I believe that there IS a set of
>>>> core functions which I believe there is a huge target market for in much of
>>>> the world, among people who could never afford SAP.  These functions are
>>>> fairly consistent - and they don't need to come with "bells on".  And I
>>>> would imagine its not a coincidence that OpenTAPS has chosen several of them
>>>> as the focus for its Financials module.
>>>>
>>>> Basic Accounting (Journal Entry with separate Posting, Balance Sheet, Trial
>>>> Balance, Data export to Excel)
>>>> Client Account management (invoices, statements by age, payments, basic
>>>> customer details)
>>>> Supplier management (basic supplier details, invoices, statements by age,
>>>> payments)
>>>>
>>>> A secondary set of priorities would be:
>>>> Integration between Client/Supplier managament and accounting
>>>> Payroll management
>>>> Stocks mgt (warehouse, orders in and out)
>>>> VAT or equivalent
>>>>
>>>> An alternative core set, which OFBiz seems to have been quite a sucess at in
>>>> terms of actual installations, is an ecommerce store backed by limited stock
>>>> management.
>>>>
>>>> A manual which had a first section dealing with the above issues, a second
>>>> section dealing with setting up an ecommerce store, and a third section
>>>> dealing with tech issues (basic setup, how to make a screen, and entity, a
>>>> service, use the webtools etc), would be very handy.  My firm at least would
>>>> buy a copy!!
>>>>
>>>> As for who produces the manuals, I believe that the "centralized, benevolent
>>>> dictator" approach works better here than a free-for-all Wiki.  I reckon the
>>>> best way to produce a core manual would be via some kind of commercialized
>>>> approach - the Pragmatic Programmers  managed to cover their costs and a wee
>>>> bit more this way.  Spring also has excellent documentation and books
>>>> available.
>>>>
>>>> >From the posts I have seen on this list, there are several core committers
>>>> who have the knowledge and explanatory ability to produce a decent book,
>>>> with the support of a technical writer.  What these people don't have is
>>>> "quality time" to sit down and write the fecker!  And they never will unless
>>>> you attach an income stream to it.
>>>>
>>>> cameron
>>>>
>>>> ----- Original Message ----
>>>> From: Jacopo Cappellato <ti...@sastau.it>
>>>> To: ofbiz-user@incubator.apache.org
>>>> Sent: Thursday, 28 December, 2006 11:09:27 AM
>>>> Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
>>>> manuals]
>>>>
>>>> David E Jones wrote:
>>>>     
>>>>         
>>>>> I guess it depends on what the goal of doing a release is. In my mind
>>>>> the goal should be to create (over time...) a stable set of artifacts
>>>>> that people can build and deploy on if they choose not to go with the
>>>>> latest/greatest.
>>>>>
>>>>> What you're describing is interesting, but how is that any different
>>>>> than just using the latest from SVN with a little timing based on
>>>>> knowing what is going on added in, and keeping a list somewhere of all
>>>>> non-backwards compatible changes and their revision numbers?
>>>>>
>>>>>       
>>>>>           
>>>> Yes, you have described pretty well what I'm suggesting; I'd only add to
>>>> these that we should also create the upgrade services (and/or upgrade
>>>> instructions) every time we commit a non-backwards compatible change in
>>>> svn. As you said, this is not so different from what we are (implicitly)
>>>> suggesting to do right now (as a best practice to stay up-to-date with
>>>> the trunk) but I think that it would be nice if the community will
>>>> officially support it for a few reasons:
>>>>
>>>> 1) it's often difficult for users to pick a 'stable' svn snapshot
>>>> 2) it's often difficult for users to keep track of important changes
>>>> between their revision and the trunk
>>>> 3) since it is not so different from what we are suggesting right now,
>>>> it will not add a huge cost maintaining these extra processes/releases
>>>>
>>>>     
>>>>         
>>>>> On that last bit, whatever we do with the releases having an official
>>>>> wiki page with all non-backward-compatible changes listed on it with the
>>>>> revision number for each would be a good thing to do...
>>>>>
>>>>>       
>>>>>           
>>>> +1
>>>>
>>>>     
>>>>         
>>>>> But, back to the main point: what is the goal of a release in your mind
>>>>> (and in the mind of anyone else reading in too)?
>>>>>
>>>>>       
>>>>>           
>>>> I'd like to get the opinions from others too.
>>>> Personally I think that releases (or release instructions/plans) should
>>>> at least help users to keep their system/data in sync with the main
>>>> trunk, minimizing the upgrade costs and simplifying the users' decisions
>>>> (i.e. "should I upgrade now?").
>>>> Of course it would also be great to have a real 'stable' releases (with
>>>> patches for them etc...) as you are suggesting (and I really think we
>>>> could implement the two approaches simultaneously since what I've
>>>> proposed could be the basis of a real release management) but I'm not
>>>> sure the community will really maintain them...
>>>>
>>>> Jacopo
>>>>
>>>>     
>>>>         
>>>>> -David
>>>>>
>>>>>       
>>>>>           
>>>>
>>>> Send instant messages to your online friends http://uk.messenger.yahoo.com
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
>>>> 14:50
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
>>>> 14:50
>>>>
>>>> --
>>>> No virus found in this outgoing message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
>>>> 14:50
>>>>
>>>>
>>>>
>>>> *****************************************************************
>>>> This email has been checked by the altohiway Mailcontroller Service
>>>> *****************************************************************
>>>>     
>>>>         

-- 
----------------------------------------------------------------------------------------------
mcnultyMEDIA
60 Birkdale Gardens
Durham
DH1 2UL

t: +44 (0)191 384 4736
e: ian@mcnultymedia.co.uk
w: www.mcnultymedia.co.uk
==============================================================================================
This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on +44 (0)191 384 4736

This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment.
==============================================================================================