Bugs and open Jira issues

[Jacques Le Roux]

Thanks Bilgin,

Yes this seems fine to me

Jacques
()  ascii ribbon campaign against HTML e-mail
/\  www.asciiribbon.org

From: "Bilgin Ibryam" <[hidden email]>

> Jacques Le Roux wrote:
>>  
>> Don't misundersand me. I'm not worried about new bugs. I totally
>> understand that this is intrinsic nature of software.
>> My point is only for us to give more love to these 109 issues waiting
>> attention in Jira, nothing else...
>>  
> Jacques,
>
> I think we should prioritize the bug issues as follow:
>
> - if an issue doesn't have a patch, ignore it, as nobody is affected by
> it yet. There will be a patch as soon as someone wants it to be fixed.
> - it there is a patch attached, give priority to issues which have at
> lease one review/test (from other users or committers, it doesn;t
> matter) which indicates that the patch is tested and working fine. Or
> there is a VOTE for the issue, meaning that it is not tested/reviewed
> but sounds as a good fix/idea.
>
> This would encourage also other users to review the patches.
>
> my 2 cents
>
> Bilgin

[Jacques Le Roux]

From: "Scott Gray" <[hidden email]>

> On 7/12/2009, at 10:05 PM, Jacques Le Roux wrote:
>
>> Please Scott,
>>
>> Inline...
>>
>> From: "Scott Gray" <[hidden email]>
>>> I disagree, there always have been and always will be bugs in  OFBiz,  there is no escaping this fact.  The only reason there
>>> are  more bugs  now than there were 3 years ago is because there is more  community  activity.  Fixing the bugs in jira will not
>>> prevent new  bugs from  replacing them (and some of the replacements will be the  same bugs we  just fixed).
>>
>> Don't misundersand me. I'm not worried about new bugs. I totally  understand that this is intrinsic nature of software.
>> My point is only for us to give more love to these 109 issues  waiting attention in Jira, nothing else...
>
> I'm saying it's pointless giving them any love without writing tests  for those bugs first.  Every code change (even bug fixes)
> carries the  risk of introducing new bugs and the only thing we can do to reduce  that risk is to write tests.  Without tests the
> number of bugs in jira  will never do anything but increase.

Scott,

As I already said, I completly agree contiuous integration with tests running is the right way to go. We have already some tests,
and for instance Ashish have got some work from them...
I see Gavin is currently working for us (commits in infra) and we are some to push to have all things on ASF servers soon.
BTW I think this means more work for us on the future as I guess we will have any less help than with Contegix...

But I don't agree that this should prevent us to fix existing bugs in the meantime...

Jacques
()  ascii ribbon campaign against HTML e-mail
/\  www.asciiribbon.org

>>> IMO the best thing we can do for the stability of the project is  to  create tests every time we create or modify a service, be
>>> it  during a  bug fix or while implementing new functionality.  Doing  so locks in  the desired behavior and prevents anyone
>>> from  unknowingly changing  that behavior.
>>
>> Yes, I plenty agree
>>
>>> Even without intervention, bugs naturally get fixed over time as   people come to require the functionality being blocked by the
>>> bug,  the  key is to do everything we can to reduce the number of new  bugs being  created.
>>
>> I totally agree, I can agree more I should say. i think I should  have used "Opened important Jira issues" as subject :/
>>
>> Jacques
>> ()  ascii ribbon campaign against HTML e-mail
>> /\  www.asciiribbon.org
>>
>>> Regards
>>> Scott
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>> On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
>>>> Thi is all great,
>>>>
>>>> Put please ladies/gents don't get out of subject.
>>>> I still think the 1st step is to fix the bugs we know exist, are   documented in Jira and even ready to be fixed with patches
>>>> for some.
>>>>
>>>> Jacques
>>>> ()  ascii ribbon campaign against HTML e-mail
>>>> /\  www.asciiribbon.org
>>>>
>>>>
>>>> From: "Anil Patel" <[hidden email]>
>>>>> We do see some great Ideas around what is needed. There was lot  of  conversation on this topic in ApacheCon 2008 and then in
>>>>> 2009  (based on messages on list).
>>>>>
>>>>> You will be surprised there is lot done. We have seen lot of   activity in documenting business processes and end user
>>>>> documentation.
>>>>>
>>>>> More recently David proposed a simple system derived from Ofbiz   that will address needs of small business.
>>>>>
>>>>> We have lot more Ofbiz technical contributors then Business  process  knowledge contributors. It will be really nice if people
>>>>> in this  part of community will step up. It will be nice if  business users  or power business users who are technical
>>>>> developers as well  started to take part of requirement documents  and add to UBPL or  EZBIZ effort.
>>>>>
>>>>> If users can document their business processes needs, give some   wireframe help then technical developers will be able to
>>>>> help  map  them to OOTB features (Gap Analysis).
>>>>>
>>>>> Unless we get real business requirements documents coming from  user  community there is no way for us to fulfill them.
>>>>>
>>>>> I hope you understand I am not asking anybody to break NDA or   whatever.
>>>>>
>>>>> Thanks and Regards
>>>>> Anil Patel
>>>>> HotWax Media Inc
>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>
>>>>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>> Here my opinion about the subject.
>>>>>> To make things clear, it makes about 3-4 month I am working with
>>>>>> OFBiz, using it to implement a project.
>>>>>>
>>>>>> I thing one way to have more people involved in the project is to
>>>>>> lower the "difficulty level" required to understand OFBiz.
>>>>>>
>>>>>> And for this there are several possbilities, and I will focus  on  two :
>>>>>> - modularize the project
>>>>>> - more functional documentation inside the source files
>>>>>>
>>>>>> Modularize the project
>>>>>>
>>>>>> I've seen this subject has already been discussed and I think it  can
>>>>>> profit to the project in several points :
>>>>>> - more modules means less code in each module, which means  modules  are
>>>>>> eaiser to understand, which means more developer may be   interesting to
>>>>>> participate to its development, test, ... There is at least one
>>>>>> obvious module which could be very interesting to externalize,  it's
>>>>>> the entity engine. I don't know so much OFBiz architecture but  I  think
>>>>>> it should be possible to externalize this module and a lot of   projects
>>>>>> totally different of OFBiz could be interesting in it, and so
>>>>>> potentially a lot more developers to maintain and enhance it.
>>>>>> - on another side, more modules would also make it easier to
>>>>>> distribute the issues, each developer specialized on a specific
>>>>>> module. Maybe it's already the case...
>>>>>>
>>>>>> More functional documentation inside the source files
>>>>>>
>>>>>> Here my feeling is that with OFBiz, you really requires both   technical
>>>>>> and functional knowledge to understand how the project work.  Some  part
>>>>>> like the entity engine are purely technical, but the order  module  for
>>>>>> example is really functional, I mean, you need to know a lot  about  how
>>>>>> ordering works in a company to be able to use the module and  even  more
>>>>>> to custommize or propose enhancements to it. So, with more
>>>>>> documentation in the source files, like the XML entity files,  and  then
>>>>>> in the source code for example explaining what a method  concretly  does
>>>>>> may help a lot to understand OFBiz. It seems the link David  sent  about
>>>>>> UBML is about his.
>>>>>>
>>>>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>>>>> participate to the project at least by providing bug reports, I   still
>>>>>> feel for away from providing patches ! :-)
>>>>>>
>>>>>> Hope this will help you, devs, the project is already great, let's
>>>>>> make it more accessible !
>>>>>>
>>>>>> Cimballi
>>>>>
>>>>
>>>>
>>>
>>
>
>

[Jacques Le Roux]

From: "Jeroen van der Wal" <[hidden email]>

> 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

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
> <[hidden email]> 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
>>
>>
>>
>

[Jacques Le Roux]

Oops,

From: "Jacques Le Roux" <[hidden email]>

> From: "Scott Gray" <[hidden email]>
>> On 7/12/2009, at 10:05 PM, Jacques Le Roux wrote:
>>
>>> Please Scott,
>>>
>>> Inline...
>>>
>>> From: "Scott Gray" <[hidden email]>
>>>> I disagree, there always have been and always will be bugs in  OFBiz,  there is no escaping this fact.  The only reason there
>>>> are  more bugs  now than there were 3 years ago is because there is more  community  activity.  Fixing the bugs in jira will
>>>> not prevent new  bugs from  replacing them (and some of the replacements will be the  same bugs we  just fixed).
>>>
>>> Don't misundersand me. I'm not worried about new bugs. I totally  understand that this is intrinsic nature of software.
>>> My point is only for us to give more love to these 109 issues  waiting attention in Jira, nothing else...
>>
>> I'm saying it's pointless giving them any love without writing tests  for those bugs first.  Every code change (even bug fixes)
>> carries the  risk of introducing new bugs and the only thing we can do to reduce  that risk is to write tests.  Without tests the
>> number of bugs in jira  will never do anything but increase.
>
> Scott,
>
> As I already said, I completly agree contiuous integration with tests running is the right way to go. We have already some tests,
> and for instance Ashish have got some work from them...

Ashish has got

> I see Gavin is currently working for us (commits in infra) and we are some to push to have all things on ASF servers soon.
> BTW I think this means more work for us on the future as I guess we will have any less help than with Contegix...
we will have less help

> But I don't agree that this should prevent us to fix existing bugs in the meantime...
>
> Jacques
> ()  ascii ribbon campaign against HTML e-mail
> /\  www.asciiribbon.org
>
>>>> IMO the best thing we can do for the stability of the project is  to  create tests every time we create or modify a service, be
>>>> it  during a  bug fix or while implementing new functionality.  Doing  so locks in  the desired behavior and prevents anyone
>>>> from  unknowingly changing  that behavior.
>>>
>>> Yes, I plenty agree
>>>
>>>> Even without intervention, bugs naturally get fixed over time as   people come to require the functionality being blocked by
>>>> the bug,  the  key is to do everything we can to reduce the number of new  bugs being  created.
>>>
>>> I totally agree, I can agree more I should say. i think I should  have used "Opened important Jira issues" as subject :/
>>>
>>> Jacques
>>> ()  ascii ribbon campaign against HTML e-mail
>>> /\  www.asciiribbon.org
>>>
>>>> Regards
>>>> Scott
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>> On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
>>>>> Thi is all great,
>>>>>
>>>>> Put please ladies/gents don't get out of subject.
>>>>> I still think the 1st step is to fix the bugs we know exist, are   documented in Jira and even ready to be fixed with patches
>>>>> for some.
>>>>>
>>>>> Jacques
>>>>> ()  ascii ribbon campaign against HTML e-mail
>>>>> /\  www.asciiribbon.org
>>>>>
>>>>>
>>>>> From: "Anil Patel" <[hidden email]>
>>>>>> We do see some great Ideas around what is needed. There was lot  of  conversation on this topic in ApacheCon 2008 and then in
>>>>>> 2009  (based on messages on list).
>>>>>>
>>>>>> You will be surprised there is lot done. We have seen lot of   activity in documenting business processes and end user
>>>>>> documentation.
>>>>>>
>>>>>> More recently David proposed a simple system derived from Ofbiz   that will address needs of small business.
>>>>>>
>>>>>> We have lot more Ofbiz technical contributors then Business  process  knowledge contributors. It will be really nice if
>>>>>> people in this  part of community will step up. It will be nice if  business users  or power business users who are technical
>>>>>> developers as well  started to take part of requirement documents  and add to UBPL or  EZBIZ effort.
>>>>>>
>>>>>> If users can document their business processes needs, give some   wireframe help then technical developers will be able to
>>>>>> help  map  them to OOTB features (Gap Analysis).
>>>>>>
>>>>>> Unless we get real business requirements documents coming from  user  community there is no way for us to fulfill them.
>>>>>>
>>>>>> I hope you understand I am not asking anybody to break NDA or   whatever.
>>>>>>
>>>>>> Thanks and Regards
>>>>>> Anil Patel
>>>>>> HotWax Media Inc
>>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>>
>>>>>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> Here my opinion about the subject.
>>>>>>> To make things clear, it makes about 3-4 month I am working with
>>>>>>> OFBiz, using it to implement a project.
>>>>>>>
>>>>>>> I thing one way to have more people involved in the project is to
>>>>>>> lower the "difficulty level" required to understand OFBiz.
>>>>>>>
>>>>>>> And for this there are several possbilities, and I will focus  on  two :
>>>>>>> - modularize the project
>>>>>>> - more functional documentation inside the source files
>>>>>>>
>>>>>>> Modularize the project
>>>>>>>
>>>>>>> I've seen this subject has already been discussed and I think it  can
>>>>>>> profit to the project in several points :
>>>>>>> - more modules means less code in each module, which means  modules  are
>>>>>>> eaiser to understand, which means more developer may be   interesting to
>>>>>>> participate to its development, test, ... There is at least one
>>>>>>> obvious module which could be very interesting to externalize,  it's
>>>>>>> the entity engine. I don't know so much OFBiz architecture but  I  think
>>>>>>> it should be possible to externalize this module and a lot of   projects
>>>>>>> totally different of OFBiz could be interesting in it, and so
>>>>>>> potentially a lot more developers to maintain and enhance it.
>>>>>>> - on another side, more modules would also make it easier to
>>>>>>> distribute the issues, each developer specialized on a specific
>>>>>>> module. Maybe it's already the case...
>>>>>>>
>>>>>>> More functional documentation inside the source files
>>>>>>>
>>>>>>> Here my feeling is that with OFBiz, you really requires both   technical
>>>>>>> and functional knowledge to understand how the project work.  Some  part
>>>>>>> like the entity engine are purely technical, but the order  module  for
>>>>>>> example is really functional, I mean, you need to know a lot  about  how
>>>>>>> ordering works in a company to be able to use the module and  even  more
>>>>>>> to custommize or propose enhancements to it. So, with more
>>>>>>> documentation in the source files, like the XML entity files,  and  then
>>>>>>> in the source code for example explaining what a method  concretly  does
>>>>>>> may help a lot to understand OFBiz. It seems the link David  sent  about
>>>>>>> UBML is about his.
>>>>>>>
>>>>>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>>>>>> participate to the project at least by providing bug reports, I   still
>>>>>>> feel for away from providing patches ! :-)
>>>>>>>
>>>>>>> Hope this will help you, devs, the project is already great, let's
>>>>>>> make it more accessible !
>>>>>>>
>>>>>>> Cimballi
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

[Jacques Le Roux]

Oops again, I should re-read :/

From: "Jacques Le Roux" <[hidden email]>

> From: "Jeroen van der Wal" <[hidden email]>
>> 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
>> <[hidden email]> 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
>>>
>>>
>>>
>>
>
>

[Ruth Hoffman-2]

Hi Brett:
Its a moving target.
How can there possibly be any progress when the target keeps changing?
Stop the commits, fix the process by establishing automated functional
tests (unit testing doesn't help much in this situation) w/Selenium, and
then begin again.
Ruth


Brett Palmer wrote:

> Ruth,
>
> You make a good point.  This has been a topic for a couple of years now.  As
> OFBiz continues to grow doing even a simple "smoke test" on the build will
> be difficult.  This is why I think the only scalable solution is to run a
> series of automated unit and functional (selenium like) tests on the
> application for each daily build.
>
> If this was automated we could send the ofbiz-dev list an email with the the
> broken tests and the information (stake trace, etc) about the failure.
>
> There are a few of us working on this but getting valid user tests from the
> community would be very helpful.
>
>
> Brett
>
> On Sun, Dec 6, 2009 at 4:57 PM, Ruth Hoffman <[hidden email]> wrote:
>
>  
>> Hi David:
>> I wasn't going to say anything about this, but my most recent experience
>> with the nightly trunk download has me fuming again...Just because an
>> organization is made up of volunteers, doesn't mean there is no need for
>> rules, respect for others and most importantly leadership.
>>
>> Here's how I would start to "fix things". I'd say: No more commits until
>> the community gets the one or more processes in place necessary to
>> coordinate testing, builds and releases. Anyone who violates the rule,
>> looses the right to commit. When all the processes are in place and agreed
>> upon, then you can give all the violators back the right to commit.
>>
>> You, David, have the power to give developer's commit access to the source
>> code repository. You, David, can take it away. Or am I wrong about that?
>> Who, BTW, gave all these people commit access to the source code repository
>> initially?
>>
>> Regards,
>> Ruth
>>
>>
>>
>> David E Jones wrote:
>>
>>    
>>> To be clear, I'd like to hear from other people too. If anyone has any
>>> ideas about how we can get people to do this, by all means let's discuss it!
>>>
>>> This need and concern has come up in many places many times over the years
>>> of the project. I have some thoughts on good ways to go about this (like the
>>> UBPL stuff, automated testing which is going on now, etc, etc), but how to
>>> get people to do things, especially in a volunteer organization like this,
>>> is another question...
>>>
>>> -David
>>>
>>>
>>> On Dec 6, 2009, at 12:29 PM, Jacques Le Roux wrote:
>>>
>>>
>>>
>>>      
>>>> Hi David,
>>>>
>>>> I have no answers yet, I must says I have not even thought about it...
>>>> For the moment I only propose to concentrate on existing known bugs
>>>> repertoried in opened Jira issues.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>> ()  ascii ribbon campaign against HTML e-mail
>>>> /\  www.asciiribbon.org
>>>>
>>>>
>>>> ----- Original Message ----- From: "David E Jones" <[hidden email]>
>>>> To: <[hidden email]>
>>>> Sent: Sunday, December 06, 2009 6:36 PM
>>>> Subject: Re: Bugs and open Jira issues
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>> Jacques,
>>>>>
>>>>> I appreciate this feeling. In general OFBiz would benefit a lot from
>>>>> more testing, more definition of what to test against (ie what does a pass
>>>>> or fail look like, ie what is the design to test against), and in general
>>>>> more care about respecting others by not breaking things that already exist.
>>>>>
>>>>> The questions is, how do we get people to do this?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>
>>>
>>>      
>
>  

[Ruth Hoffman-2]

Hi Scott:
Then stop the committing and do some reviewing. There is more to
software development than committing code to a repository.
Regards,
Ruth

Scott Gray wrote:

> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>
>> 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.
>
> We already have these volunteers, they're called people who review
> commits and I could probably count them on one hand.
> Everything you've suggested requires more resources than this
> community can provide.
>
>> - 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)
>> - Communicate changes to dependent components so they can sanitize
>> their components
>> - Don't allow code without tests
>> - Use branching for work in progress to maintain a stable trunk (I
>> prefer Git over SVN but that's another topic...)
>>
>> 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
>>
>> Best,
>>
>> Jeroen van der Wal
>>
>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>> <[hidden email]> 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
>>>
>>>
>>>
>

[Anil Patel-3]

Ruth,
Why don't you consider using one of the release branches?

Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"

On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:

> Hi Scott:
> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.

> Regards,
> Ruth
>
> Scott Gray wrote:
>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>
>>> 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.
>>
>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>> Everything you've suggested requires more resources than this community can provide.
>>
>>> - 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)
>>> - Communicate changes to dependent components so they can sanitize
>>> their components
>>> - Don't allow code without tests
>>> - Use branching for work in progress to maintain a stable trunk (I
>>> prefer Git over SVN but that's another topic...)
>>>
>>> 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
>>>
>>> Best,
>>>
>>> Jeroen van der Wal
>>>
>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>> <[hidden email]> 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
>>>>
>>>>
>>>>
>>

[Jacques Le Roux]

From: "Brett Palmer" <[hidden email]>

> Ruth,
>
> You make a good point.  This has been a topic for a couple of years now.  As
> OFBiz continues to grow doing even a simple "smoke test" on the build will
> be difficult.  This is why I think the only scalable solution is to run a
> series of automated unit and functional (selenium like) tests on the
> application for each daily build.
>
> If this was automated we could send the ofbiz-dev list an email with the the
> broken tests and the information (stake trace, etc) about the failure.

It's automated see stdio in the red part of the Waterfall (tests don't pass these last times)
Waterfall : http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none
Test : http://ci.apache.org/builders/ofbiz-trunk/builds/2004/steps/compile_1/logs/stdio

Jacques
()  ascii ribbon campaign against HTML e-mail
/\  www.asciiribbon.org
 

> There are a few of us working on this but getting valid user tests from the
> community would be very helpful.
>
>
> Brett
>
> On Sun, Dec 6, 2009 at 4:57 PM, Ruth Hoffman <[hidden email]> wrote:
>
>> Hi David:
>> I wasn't going to say anything about this, but my most recent experience
>> with the nightly trunk download has me fuming again...Just because an
>> organization is made up of volunteers, doesn't mean there is no need for
>> rules, respect for others and most importantly leadership.
>>
>> Here's how I would start to "fix things". I'd say: No more commits until
>> the community gets the one or more processes in place necessary to
>> coordinate testing, builds and releases. Anyone who violates the rule,
>> looses the right to commit. When all the processes are in place and agreed
>> upon, then you can give all the violators back the right to commit.
>>
>> You, David, have the power to give developer's commit access to the source
>> code repository. You, David, can take it away. Or am I wrong about that?
>> Who, BTW, gave all these people commit access to the source code repository
>> initially?
>>
>> Regards,
>> Ruth
>>
>>
>>
>> David E Jones wrote:
>>
>>> To be clear, I'd like to hear from other people too. If anyone has any
>>> ideas about how we can get people to do this, by all means let's discuss it!
>>>
>>> This need and concern has come up in many places many times over the years
>>> of the project. I have some thoughts on good ways to go about this (like the
>>> UBPL stuff, automated testing which is going on now, etc, etc), but how to
>>> get people to do things, especially in a volunteer organization like this,
>>> is another question...
>>>
>>> -David
>>>
>>>
>>> On Dec 6, 2009, at 12:29 PM, Jacques Le Roux wrote:
>>>
>>>
>>>
>>>> Hi David,
>>>>
>>>> I have no answers yet, I must says I have not even thought about it...
>>>> For the moment I only propose to concentrate on existing known bugs
>>>> repertoried in opened Jira issues.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>> ()  ascii ribbon campaign against HTML e-mail
>>>> /\  www.asciiribbon.org
>>>>
>>>>
>>>> ----- Original Message ----- From: "David E Jones" <[hidden email]>
>>>> To: <[hidden email]>
>>>> Sent: Sunday, December 06, 2009 6:36 PM
>>>> Subject: Re: Bugs and open Jira issues
>>>>
>>>>
>>>>
>>>>
>>>>> Jacques,
>>>>>
>>>>> I appreciate this feeling. In general OFBiz would benefit a lot from
>>>>> more testing, more definition of what to test against (ie what does a pass
>>>>> or fail look like, ie what is the design to test against), and in general
>>>>> more care about respecting others by not breaking things that already exist.
>>>>>
>>>>> The questions is, how do we get people to do this?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>

[Ruth Hoffman-2]

Hi Anil:
I feel like I'm spitting in the wind here...Please, let's just start
this conversation over again. Under the following circumstances, which
version or release of OFBiz should I use?

I'm a new user and I want to customize my OFBiz instance for a new ERP
deployment.

TIA
Ruth
Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"




Anil Patel wrote:

> Ruth,
> Why don't you consider using one of the release branches?
>
> Thanks and Regards
> Anil Patel
> HotWax Media Inc
> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>
> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>
>  
>> Hi Scott:
>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>    
> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>
>
>  
>> Regards,
>> Ruth
>>
>> Scott Gray wrote:
>>    
>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>
>>>      
>>>> 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.
>>>>        
>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>> Everything you've suggested requires more resources than this community can provide.
>>>
>>>      
>>>> - 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)
>>>> - Communicate changes to dependent components so they can sanitize
>>>> their components
>>>> - Don't allow code without tests
>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>> prefer Git over SVN but that's another topic...)
>>>>
>>>> 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
>>>>
>>>> Best,
>>>>
>>>> Jeroen van der Wal
>>>>
>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>> <[hidden email]> 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
>>>>>
>>>>>
>>>>>
>>>>>          
>
>
>  

[David E. Jones-2]

This page might be helpful, and answers the more general question behind the question:

http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started

-David


On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:

> Hi Anil:
> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following circumstances, which version or release of OFBiz should I use?
>
> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>
> TIA
> Ruth
> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>
>
>
>
> Anil Patel wrote:
>> Ruth,
>> Why don't you consider using one of the release branches?
>>
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>
>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>
>>  
>>> Hi Scott:
>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>    
>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>>
>>
>>  
>>> Regards,
>>> Ruth
>>>
>>> Scott Gray wrote:
>>>    
>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>
>>>>      
>>>>> 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.
>>>>>        
>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>> Everything you've suggested requires more resources than this community can provide.
>>>>
>>>>      
>>>>> - 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)
>>>>> - Communicate changes to dependent components so they can sanitize
>>>>> their components
>>>>> - Don't allow code without tests
>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>> prefer Git over SVN but that's another topic...)
>>>>>
>>>>> 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
>>>>>
>>>>> Best,
>>>>>
>>>>> Jeroen van der Wal
>>>>>
>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>> <[hidden email]> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>          
>>
>>
>>  

[Anil Patel-3]

Ruth,
Its depends on How you plan to work.

If a
    1) branch has all features you need
    2) you plan to only customize for business use
    3) Don't plan to contribute enhancements to Ofbiz trunk.
Then
    Use Branch
Else If
    1) You need features from latest trunk
    2) You don't care for upcoming features
    3) You don't care for contributing enhancements to Ofbiz trunk
Then
    Create Vendor branch from current trunk revision. This is painful and not easy.
Else
    Keep current with trunk, work with community to get it better.
End If

These are my personal quick notes for you. I know David has already directed you to page that has more complete answer.
 
Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"

On Dec 7, 2009, at 12:05 PM, Ruth Hoffman wrote:

> Hi Anil:
> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following circumstances, which version or release of OFBiz should I use?
>
> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>
> TIA
> Ruth
> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>
>
>
>
> Anil Patel wrote:
>> Ruth,
>> Why don't you consider using one of the release branches?
>>
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>
>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>
>>  
>>> Hi Scott:
>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>    
>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>>
>>
>>  
>>> Regards,
>>> Ruth
>>>
>>> Scott Gray wrote:
>>>    
>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>
>>>>      
>>>>> 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.
>>>>>        
>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>> Everything you've suggested requires more resources than this community can provide.
>>>>
>>>>      
>>>>> - 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)
>>>>> - Communicate changes to dependent components so they can sanitize
>>>>> their components
>>>>> - Don't allow code without tests
>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>> prefer Git over SVN but that's another topic...)
>>>>>
>>>>> 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
>>>>>
>>>>> Best,
>>>>>
>>>>> Jeroen van der Wal
>>>>>
>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>> <[hidden email]> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>          
>>
>>
>>  

[Ruth Hoffman-2]

HI David:
If that resource is the "definitive" answer, then why does that "BIG FAT
DOWNLOAD" button/link point to a "trunk" build? Shouldn't it point to a
"release branch tag" build with a good probability of working?
Am I missing something here?
Am I not reading all this information correctly?
Why does that button point to a build using Java 1.6 when that couldn't
possibly be a build that has any history of testing behind it..you just
started using Java 1.6 after all.

TIA
Ruth

David E Jones wrote:

> This page might be helpful, and answers the more general question behind the question:
>
> http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started
>
> -David
>
>
> On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
>
>  
>> Hi Anil:
>> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following circumstances, which version or release of OFBiz should I use?
>>
>> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>>
>> TIA
>> Ruth
>> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>>
>>
>>
>>
>> Anil Patel wrote:
>>    
>>> Ruth,
>>> Why don't you consider using one of the release branches?
>>>
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>
>>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>>
>>>  
>>>      
>>>> Hi Scott:
>>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>>    
>>>>        
>>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>>>
>>>
>>>  
>>>      
>>>> Regards,
>>>> Ruth
>>>>
>>>> Scott Gray wrote:
>>>>    
>>>>        
>>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>>
>>>>>      
>>>>>          
>>>>>> 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.
>>>>>>        
>>>>>>            
>>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>>> Everything you've suggested requires more resources than this community can provide.
>>>>>
>>>>>      
>>>>>          
>>>>>> - 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)
>>>>>> - Communicate changes to dependent components so they can sanitize
>>>>>> their components
>>>>>> - Don't allow code without tests
>>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>>> prefer Git over SVN but that's another topic...)
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Jeroen van der Wal
>>>>>>
>>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>>> <[hidden email]> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>          
>>>>>>>              
>>>  
>>>      
>
>
>  

[Jeroen van der Wal-2]

Hi Ruth,

I agree with you on having a branch for the JDK switch (as I propose
to use branches for every change) but it doesn't help to be so
ruthless (what's in a name) towards the community. I use Max OSX too
and are still not able to run Ofbiz from trunk. First I had a JDK
issue which I was manage to overcome, now I got an error "Can't find
home, jk2.properties not loaded". As you can see the community is here
to fix errors. And improve from the lessons learned. For your own
comfort please use a release branch until the trunk is stable.

Best,
Jeroen van der Wal

[David E. Jones-2]

I suppose we are shameless optimists and hope that people will choose to collaborate with other people using the software, and perhaps even participate in the development.

Still, I agree the big download button is a bad design and I never liked it given that there are various options to download and personally I like the idea of making people make choices... ;)

-David


On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote:

> HI David:
> If that resource is the "definitive" answer, then why does that "BIG FAT DOWNLOAD" button/link point to a "trunk" build? Shouldn't it point to a "release branch tag" build with a good probability of working?
> Am I missing something here?
> Am I not reading all this information correctly?
> Why does that button point to a build using Java 1.6 when that couldn't possibly be a build that has any history of testing behind it..you just started using Java 1.6 after all.
>
> TIA
> Ruth
>
> David E Jones wrote:
>> This page might be helpful, and answers the more general question behind the question:
>>
>> http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>
>> -David
>>
>>
>> On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
>>
>>  
>>> Hi Anil:
>>> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following circumstances, which version or release of OFBiz should I use?
>>>
>>> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>>>
>>> TIA
>>> Ruth
>>> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>>>
>>>
>>>
>>>
>>> Anil Patel wrote:
>>>    
>>>> Ruth,
>>>> Why don't you consider using one of the release branches?
>>>>
>>>> Thanks and Regards
>>>> Anil Patel
>>>> HotWax Media Inc
>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>
>>>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>>>
>>>>      
>>>>> Hi Scott:
>>>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>>>          
>>>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>>>>
>>>>
>>>>      
>>>>> Regards,
>>>>> Ruth
>>>>>
>>>>> Scott Gray wrote:
>>>>>          
>>>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>>>
>>>>>>              
>>>>>>> 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.
>>>>>>>                  
>>>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>>>> Everything you've suggested requires more resources than this community can provide.
>>>>>>
>>>>>>              
>>>>>>> - 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)
>>>>>>> - Communicate changes to dependent components so they can sanitize
>>>>>>> their components
>>>>>>> - Don't allow code without tests
>>>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>>>> prefer Git over SVN but that's another topic...)
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Jeroen van der Wal
>>>>>>>
>>>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>>>> <[hidden email]> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                      
>>>>      
>>
>>
>>  

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> I suppose we are shameless optimists and hope that people will choose to collaborate with other people using the software, and
> perhaps even participate in the development.
>
> Still, I agree the big download button is a bad design and I never liked it given that there are various options to download and
> personally I like the idea of making people make choices... ;)

If number of people don't like it, then it should be discussed

Jacques
()  ascii ribbon campaign against HTML e-mail
/\  www.asciiribbon.org

> -David
>
>
> On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote:
>
>> HI David:
>> If that resource is the "definitive" answer, then why does that "BIG FAT DOWNLOAD" button/link point to a "trunk" build?
>> Shouldn't it point to a "release branch tag" build with a good probability of working?
>> Am I missing something here?
>> Am I not reading all this information correctly?
>> Why does that button point to a build using Java 1.6 when that couldn't possibly be a build that has any history of testing
>> behind it..you just started using Java 1.6 after all.
>>
>> TIA
>> Ruth
>>
>> David E Jones wrote:
>>> This page might be helpful, and answers the more general question behind the question:
>>>
>>> http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>
>>> -David
>>>
>>>
>>> On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
>>>
>>>
>>>> Hi Anil:
>>>> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following
>>>> circumstances, which version or release of OFBiz should I use?
>>>>
>>>> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>>>>
>>>> TIA
>>>> Ruth
>>>> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>>>>
>>>>
>>>>
>>>>
>>>> Anil Patel wrote:
>>>>
>>>>> Ruth,
>>>>> Why don't you consider using one of the release branches?
>>>>>
>>>>> Thanks and Regards
>>>>> Anil Patel
>>>>> HotWax Media Inc
>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>
>>>>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>>>>
>>>>>
>>>>>> Hi Scott:
>>>>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>>>>
>>>>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs
>>>>> more stable version we do have release branch.
>>>>>
>>>>>
>>>>>
>>>>>> Regards,
>>>>>> Ruth
>>>>>>
>>>>>> Scott Gray wrote:
>>>>>>
>>>>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>>>>> Everything you've suggested requires more resources than this community can provide.
>>>>>>>
>>>>>>>
>>>>>>>> - 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)
>>>>>>>> - Communicate changes to dependent components so they can sanitize
>>>>>>>> their components
>>>>>>>> - Don't allow code without tests
>>>>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>>>>> prefer Git over SVN but that's another topic...)
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Jeroen van der Wal
>>>>>>>>
>>>>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>>>>> <[hidden email]> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>
>>>
>>>
>

[Tim Ruppert]

Most of the major projects have a big DOWNLOAD button - it's a good idea - and I'd be surprised if a call to action does not encourage more people to download.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Dec 7, 2009, at 12:55 PM, Jacques Le Roux wrote:

> From: "David E Jones" <[hidden email]>
>> I suppose we are shameless optimists and hope that people will choose to collaborate with other people using the software, and perhaps even participate in the development.
>>
>> Still, I agree the big download button is a bad design and I never liked it given that there are various options to download and personally I like the idea of making people make choices... ;)
>
> If number of people don't like it, then it should be discussed
>
> Jacques
> ()  ascii ribbon campaign against HTML e-mail
> /\  www.asciiribbon.org
>
>> -David
>>
>>
>> On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote:
>>
>>> HI David:
>>> If that resource is the "definitive" answer, then why does that "BIG FAT DOWNLOAD" button/link point to a "trunk" build? Shouldn't it point to a "release branch tag" build with a good probability of working?
>>> Am I missing something here?
>>> Am I not reading all this information correctly?
>>> Why does that button point to a build using Java 1.6 when that couldn't possibly be a build that has any history of testing behind it..you just started using Java 1.6 after all.
>>>
>>> TIA
>>> Ruth
>>>
>>> David E Jones wrote:
>>>> This page might be helpful, and answers the more general question behind the question:
>>>>
>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>>
>>>> -David
>>>>
>>>>
>>>> On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
>>>>
>>>>
>>>>> Hi Anil:
>>>>> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following circumstances, which version or release of OFBiz should I use?
>>>>>
>>>>> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>>>>>
>>>>> TIA
>>>>> Ruth
>>>>> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Anil Patel wrote:
>>>>>
>>>>>> Ruth,
>>>>>> Why don't you consider using one of the release branches?
>>>>>>
>>>>>> Thanks and Regards
>>>>>> Anil Patel
>>>>>> HotWax Media Inc
>>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>>
>>>>>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Scott:
>>>>>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>>>>>
>>>>>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>>
>>>>>>> Scott Gray wrote:
>>>>>>>
>>>>>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>>>>>> Everything you've suggested requires more resources than this community can provide.
>>>>>>>>
>>>>>>>>
>>>>>>>>> - 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)
>>>>>>>>> - Communicate changes to dependent components so they can sanitize
>>>>>>>>> their components
>>>>>>>>> - Don't allow code without tests
>>>>>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>>>>>> prefer Git over SVN but that's another topic...)
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Jeroen van der Wal
>>>>>>>>>
>>>>>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>
>

[Ruth Hoffman-2]

Hi David:
Shameless optimists, perhaps. "Realists", maybe not.

This has nothing to do with collaboration or freedom of "choice". This
is all about new users being helped or should I say guided towards
downloading a version of the project. IMO and experience, not very many
people are going to spend the several hours it takes to wade through and
decipher all the noise surrounding the answer to a very simple question:
"Which version do I download"?

Let's be real. If you or anyone else in this community want to gain mind
share and get more collaborators, you first need to get more users.

Now, I'll ask this question: How many downloads has the project
experienced recently? If anyone knows the answer to this question,
please speak up. If no one is downloading software, then perhaps
something is wrong. Or maybe you don't want any new users? Just
experienced collaborators?

If, on the other hand,  downloads are proceeding at a brisk pace, well
then I'll shut up and go figure out how to get another JIRA account and
continue reporting bugs.

Just my 2 cents.

Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
[hidden email]

David E Jones wrote:

> I suppose we are shameless optimists and hope that people will choose to collaborate with other people using the software, and perhaps even participate in the development.
>
> Still, I agree the big download button is a bad design and I never liked it given that there are various options to download and personally I like the idea of making people make choices... ;)
>
> -David
>
>
> On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote:
>
>  
>> HI David:
>> If that resource is the "definitive" answer, then why does that "BIG FAT DOWNLOAD" button/link point to a "trunk" build? Shouldn't it point to a "release branch tag" build with a good probability of working?
>> Am I missing something here?
>> Am I not reading all this information correctly?
>> Why does that button point to a build using Java 1.6 when that couldn't possibly be a build that has any history of testing behind it..you just started using Java 1.6 after all.
>>
>> TIA
>> Ruth
>>
>> David E Jones wrote:
>>    
>>> This page might be helpful, and answers the more general question behind the question:
>>>
>>> http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>
>>> -David
>>>
>>>
>>> On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
>>>
>>>  
>>>      
>>>> Hi Anil:
>>>> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following circumstances, which version or release of OFBiz should I use?
>>>>
>>>> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>>>>
>>>> TIA
>>>> Ruth
>>>> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>>>>
>>>>
>>>>
>>>>
>>>> Anil Patel wrote:
>>>>    
>>>>        
>>>>> Ruth,
>>>>> Why don't you consider using one of the release branches?
>>>>>
>>>>> Thanks and Regards
>>>>> Anil Patel
>>>>> HotWax Media Inc
>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>
>>>>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>>>>
>>>>>      
>>>>>          
>>>>>> Hi Scott:
>>>>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>>>>          
>>>>>>            
>>>>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>>>>>
>>>>>
>>>>>      
>>>>>          
>>>>>> Regards,
>>>>>> Ruth
>>>>>>
>>>>>> Scott Gray wrote:
>>>>>>          
>>>>>>            
>>>>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>>>>
>>>>>>>              
>>>>>>>              
>>>>>>>> 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.
>>>>>>>>                  
>>>>>>>>                
>>>>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>>>>> Everything you've suggested requires more resources than this community can provide.
>>>>>>>
>>>>>>>              
>>>>>>>              
>>>>>>>> - 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)
>>>>>>>> - Communicate changes to dependent components so they can sanitize
>>>>>>>> their components
>>>>>>>> - Don't allow code without tests
>>>>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>>>>> prefer Git over SVN but that's another topic...)
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Jeroen van der Wal
>>>>>>>>
>>>>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>>>>> <[hidden email]> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                      
>>>>>>>>>                  
>>>>>      
>>>>>          
>>>  
>>>      
>
>
>  

[Ruth Hoffman-2]

Hi Jacques:
Please, lets discuss. Here's what I'd like to see:
A download button that points to a known, good release of OFBiz. I don't
care if its a 4.x or 9.x version. Just one that has been built and at
least runs the eCommerce demo with a minimum of problems. This version
should pass the agreed upon unit tests and functional tests. Problems
(including testing issues) that are known to exist should be document in
the README file or some other "Release Notes".

WDYT?
Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
[hidden email]

Jacques Le Roux wrote:

> From: "David E Jones" <[hidden email]>
>> I suppose we are shameless optimists and hope that people will choose
>> to collaborate with other people using the software, and perhaps even
>> participate in the development.
>>
>> Still, I agree the big download button is a bad design and I never
>> liked it given that there are various options to download and
>> personally I like the idea of making people make choices... ;)
>
> If number of people don't like it, then it should be discussed
>
> Jacques
> ()  ascii ribbon campaign against HTML e-mail
> /\  www.asciiribbon.org
>
>> -David
>>
>>
>> On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote:
>>
>>> HI David:
>>> If that resource is the "definitive" answer, then why does that "BIG
>>> FAT DOWNLOAD" button/link point to a "trunk" build? Shouldn't it
>>> point to a "release branch tag" build with a good probability of
>>> working?
>>> Am I missing something here?
>>> Am I not reading all this information correctly?
>>> Why does that button point to a build using Java 1.6 when that
>>> couldn't possibly be a build that has any history of testing behind
>>> it..you just started using Java 1.6 after all.
>>>
>>> TIA
>>> Ruth
>>>
>>> David E Jones wrote:
>>>> This page might be helpful, and answers the more general question
>>>> behind the question:
>>>>
>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started 
>>>>
>>>>
>>>> -David
>>>>
>>>>
>>>> On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
>>>>
>>>>
>>>>> Hi Anil:
>>>>> I feel like I'm spitting in the wind here...Please, let's just
>>>>> start this conversation over again. Under the following
>>>>> circumstances, which version or release of OFBiz should I use?
>>>>>
>>>>> I'm a new user and I want to customize my OFBiz instance for a new
>>>>> ERP deployment.
>>>>>
>>>>> TIA
>>>>> Ruth
>>>>> Find me on the web at http://www.myofbiz.com or Google Keyword
>>>>> "myofbiz"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Anil Patel wrote:
>>>>>
>>>>>> Ruth,
>>>>>> Why don't you consider using one of the release branches?
>>>>>>
>>>>>> Thanks and Regards
>>>>>> Anil Patel
>>>>>> HotWax Media Inc
>>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>>
>>>>>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Scott:
>>>>>>> Then stop the committing and do some reviewing. There is more to
>>>>>>> software development than committing code to a repository.
>>>>>>>
>>>>>> This is interesting perspective. Trunk is expected to remain
>>>>>> active. New development must continue. For the people who needs
>>>>>> more stable version we do have release branch.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>>
>>>>>>> Scott Gray wrote:
>>>>>>>
>>>>>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>> We already have these volunteers, they're called people who
>>>>>>>> review commits and I could probably count them on one hand.
>>>>>>>> Everything you've suggested requires more resources than this
>>>>>>>> community can provide.
>>>>>>>>
>>>>>>>>
>>>>>>>>> - 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)
>>>>>>>>> - Communicate changes to dependent components so they can
>>>>>>>>> sanitize
>>>>>>>>> their components
>>>>>>>>> - Don't allow code without tests
>>>>>>>>> - Use branching for work in progress to maintain a stable
>>>>>>>>> trunk (I
>>>>>>>>> prefer Git over SVN but that's another topic...)
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Jeroen van der Wal
>>>>>>>>>
>>>>>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>
>
>

[Ruth Hoffman-2]

Hi Tim:
I like the download button idea. It helps new users figure out "first
steps". It minimizes the chance of error. I would argue not to remove
the download button but rather have it point to something else. In fact,
I'd like to have it point to several clearly marked downloads:

1) A good solid pre-built release of OFBiz. One that I would not
hesitate to recommend to new users.
2) The latest developer's (built) release
3) A framework only version
4) SVN access information

Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
[hidden email]

Tim Ruppert wrote:

> Most of the major projects have a big DOWNLOAD button - it's a good idea - and I'd be surprised if a call to action does not encourage more people to download.
>
> Cheers,
> Ruppert
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Dec 7, 2009, at 12:55 PM, Jacques Le Roux wrote:
>
>  
>> From: "David E Jones" <[hidden email]>
>>    
>>> I suppose we are shameless optimists and hope that people will choose to collaborate with other people using the software, and perhaps even participate in the development.
>>>
>>> Still, I agree the big download button is a bad design and I never liked it given that there are various options to download and personally I like the idea of making people make choices... ;)
>>>      
>> If number of people don't like it, then it should be discussed
>>
>> Jacques
>> ()  ascii ribbon campaign against HTML e-mail
>> /\  www.asciiribbon.org
>>
>>    
>>> -David
>>>
>>>
>>> On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote:
>>>
>>>      
>>>> HI David:
>>>> If that resource is the "definitive" answer, then why does that "BIG FAT DOWNLOAD" button/link point to a "trunk" build? Shouldn't it point to a "release branch tag" build with a good probability of working?
>>>> Am I missing something here?
>>>> Am I not reading all this information correctly?
>>>> Why does that button point to a build using Java 1.6 when that couldn't possibly be a build that has any history of testing behind it..you just started using Java 1.6 after all.
>>>>
>>>> TIA
>>>> Ruth
>>>>
>>>> David E Jones wrote:
>>>>        
>>>>> This page might be helpful, and answers the more general question behind the question:
>>>>>
>>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
>>>>>
>>>>>
>>>>>          
>>>>>> Hi Anil:
>>>>>> I feel like I'm spitting in the wind here...Please, let's just start this conversation over again. Under the following circumstances, which version or release of OFBiz should I use?
>>>>>>
>>>>>> I'm a new user and I want to customize my OFBiz instance for a new ERP deployment.
>>>>>>
>>>>>> TIA
>>>>>> Ruth
>>>>>> Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Anil Patel wrote:
>>>>>>
>>>>>>            
>>>>>>> Ruth,
>>>>>>> Why don't you consider using one of the release branches?
>>>>>>>
>>>>>>> Thanks and Regards
>>>>>>> Anil Patel
>>>>>>> HotWax Media Inc
>>>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>>>
>>>>>>> On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>> Hi Scott:
>>>>>>>> Then stop the committing and do some reviewing. There is more to software development than committing code to a repository.
>>>>>>>>
>>>>>>>>                
>>>>>>> This is interesting perspective. Trunk is expected to remain active. New development must continue. For the people who needs more stable version we do have release branch.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>> Regards,
>>>>>>>> Ruth
>>>>>>>>
>>>>>>>> Scott Gray wrote:
>>>>>>>>
>>>>>>>>                
>>>>>>>>> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>> We already have these volunteers, they're called people who review commits and I could probably count them on one hand.
>>>>>>>>> Everything you've suggested requires more resources than this community can provide.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>> - 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)
>>>>>>>>>> - Communicate changes to dependent components so they can sanitize
>>>>>>>>>> their components
>>>>>>>>>> - Don't allow code without tests
>>>>>>>>>> - Use branching for work in progress to maintain a stable trunk (I
>>>>>>>>>> prefer Git over SVN but that's another topic...)
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>> Jeroen van der Wal
>>>>>>>>>>
>>>>>>>>>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>>>>>>>>>> <[hidden email]> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>
>>>>>          
>>    
>
>