Oops again, I should re-read :/

From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
From: "Jeroen van der Wal" <jvander...@stromboli.it>
Thank you Jacques for addressing this as this situation worries me
too. Although I think the power of the Ofbiz community can handle it
:-)

My suggestions would be:
- Assign volunteers and a lead to each of the components. They can
watch issues of their components and should can be consulted if
anybody wants to make changes in their neighbourhood.
- Work bottom up: start with the framework, then the core modules
(party, product, accounting, workeffort, manufactureing, order) and
finally the specialpurpose modules (I personally consider humanres and
marketing to be specialpurpose)

We already mostly proceed this way
Not sure where to put the limit for marketing and humares, it's true that nothing depends on them http://cwiki.apache.org/confluence/x/MYB2

- Communicate changes to dependent components so they can sanitize
their components
- Don't allow code without tests

I guess it's still not possible in a near future

- Use branching for work in progress to maintain a stable trunk (I
prefer Git over SVN but that's another topic...)

We already do that, some use Git

I'm a big fan of branching, this explains why:
- Code each task (or related set of tasks) in its own branch, then you
will have the flexibility of when you would like to merge these tasks
and perform a release.
- QA should be done on each branch before it is merged to the trunk.
- By doing QA on each individual branch, you will know exactly what
caused the bug easier.
- This solution scales to any number of developers.
- This method works since branching is an almost instant operation in SVN.
- Tag each release that you perform.
- You can develop features that you don't plan to release for a while
and decide exactly when to merge them.
- For all work you do, you can have the benefit of committing your
code. If you work out of the trunk only, you will probably keep your
code uncommitted a lot, and hence unprotected and without automatic
history.
If you try to do the opposite and do all your development in the trunk
you'll be plagged by:
- Constant build problems for daily builds
- Productivity loss when a a developer commits a problem for all other
people on the project
- Longer release cycles, because you need to finally get a stable version
- Less stable releases

This is mostly true  (almost instant operation, mmm..) and I agree.
But as Scott said,, branching is needs more work and sadly we don't have enough 
manpower already

But as Scott said, branching needs more work and sadly we don't have enough 
manpower already

Thanks Jeroen for sharing your thoughts, experience and knowledge, appreciated

Jacques

Best,

Jeroen van der Wal

On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:

Hi,

I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.

I'm quite happy to see that these last times a lot of effort have been made in 
order to fix OFBiz (yes to fix OFBiz!)
It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.

There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?

Thanks

Jacques







Reply via email to