You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Ruth Hoffman <rh...@aesolves.com> on 2009/12/07 18:05:19 UTC
New Users and OFBiz versions was: Bugs and open Jira issues
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
>>>> <ja...@les7arts.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>
>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>
>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>>
>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
Click previous versions - it takes you were you have options. You don't need the options on the home page IMO.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Dec 7, 2009, at 3:51 PM, David E Jones wrote:
>
> The point is we need more than one so people can choose, and are more aware that there is a choice.
>
> -David
>
>
> On Dec 7, 2009, at 2:13 PM, 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" <de...@me.com>
>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Quick answer (hopefully more yesterday)
I found Ruth's proposition as 1st level then Anil's at 2d level a good start
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
From: "David E Jones" <de...@me.com>
> The point is we need more than one so people can choose, and are more aware that there is a choice.
>
> -David
>
>
> On Dec 7, 2009, at 2:13 PM, 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" <de...@me.com>
>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have
>>>>>>>>>>>> expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating
>>>>>>>>>>>> new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the
>>>>>>>>>>>> most important ones (109 are considered as at least important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Scott Gray <sc...@hotwaxmedia.com>.
The download button links to build.ofbiz.org which displays trunk,
9.04 and 4.0.
The only thing I see missing are descriptions of the three.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 8/12/2009, at 11:51 AM, David E Jones wrote:
>
> The point is we need more than one so people can choose, and are
> more aware that there is a choice.
>
> -David
>
>
> On Dec 7, 2009, at 2:13 PM, 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" <de...@me.com>
>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not
>>>>>>>>>>>> only my own feeling but also something some users have
>>>>>>>>>>>> expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of
>>>>>>>>>>>> effort have been made in order to fix OFBiz (yes to fix
>>>>>>>>>>>> OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I
>>>>>>>>>>>> really wonder if we should not slow down the pace in
>>>>>>>>>>>> integrating new features for a short period of time and
>>>>>>>>>>>> should not make and even greatest effort to have a more
>>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's
>>>>>>>>>>>> time for the community to have a look at them and to fix
>>>>>>>>>>>> the most important ones (109 are considered as at least
>>>>>>>>>>>> important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by David E Jones <de...@me.com>.
The point is we need more than one so people can choose, and are more aware that there is a choice.
-David
On Dec 7, 2009, at 2:13 PM, 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" <de...@me.com>
>>> 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
>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>>>>>
>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>>>
>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Anil Patel <an...@hotwaxmedia.com>.
Ruth,
Thanks for pushing Users interest in the community.
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 5:00 PM, Ruth Hoffman wrote:
> 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"
> ruth.hoffman@myofbiz.com
>
> 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" <de...@me.com>
>>>
>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>
>>
>>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
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"
ruth.hoffman@myofbiz.com
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" <de...@me.com>
>>
>>> 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
>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>>>>>
>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>>>
>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>>>
>>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
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" <de...@me.com>
>> 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
>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>>>>
>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>>
>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
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"
ruth.hoffman@myofbiz.com
Jacques Le Roux wrote:
> From: "David E Jones" <de...@me.com>
>> 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
>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only
>>>>>>>>>> my own feeling but also something some users have expressed
>>>>>>>>>> recently.
>>>>>>>>>>
>>>>>>>>>> I'm quite happy to see that these last times a lot of effort
>>>>>>>>>> have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>> wonder if we should not slow down the pace in integrating new
>>>>>>>>>> features for a short period of time and should not make and
>>>>>>>>>> even greatest effort to have a more stable OFBiz.
>>>>>>>>>>
>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time
>>>>>>>>>> for the community to have a look at them and to fix the most
>>>>>>>>>> important ones (109 are considered as at least important) ?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <de...@me.com>
> 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
>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed
>>>>>>>>> recently.
>>>>>>>>>
>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new
>>>>>>>>> features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>
>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most
>>>>>>>>> important ones (109 are considered as at least important) ?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>
>>>
>>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
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"
ruth.hoffman@myofbiz.com
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
>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>>>
>>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>>
>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by David E Jones <de...@me.com>.
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
>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>>
>>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>>
>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>
>>
>>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jeroen van der Wal <jv...@stromboli.it>.
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
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
>>>>>> <ja...@les7arts.com> wrote:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>
>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>
>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by David E Jones <de...@me.com>.
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
>>>>> <ja...@les7arts.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>
>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>
>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
I do not think this is a good idea at all unless we're going to encourage people to start development on the branch - which is NOT what we've been doing all along. Let's make the text more clear as to what they're getting as well as showing them where to go and get it. Looking forward to some copy Ruth when you get a chance.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Dec 9, 2009, at 11:44 AM, Ruth Hoffman wrote:
> Hi Jeroen:
> Thanks for you quick reply!
> To the list and the PMC specifically:
> Could we change the "BIG FAT DOWNLOAD" button to point to this branch/release? Please? Should I enter this request as a JIRA?
>
> Thanks again.
> Ruth
> ----------------------------------------------------
> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
> ruth.hoffman@myofbiz.com
> Jeroen van der Wal wrote:
>> Hi Ruth,
>>
>> Branching is a term common to developers so I understand the confusion.
>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>> for the latest version of the latest release use this link:
>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>> Again a point proven that the community is focused towards developers. Keep
>> asking.
>> -Jeroen
>>
>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>>
>>
>>> Hi Anil:
>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>> could we please take this logic one step further?
>>>
>>> Which of the many download options on the http://build.ofbiz.org is the
>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been there
>>> with that release; no need to go down that path :-)
>>>
>>> I don't see the word "Branch" anywhere on this page. Should I keep staring
>>> at the page longer? Did I miss something?
>>>
>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>
>>> Regards,
>>> Ruth
>>> ----------------------------------------------------
>>>
>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>> ruth.hoffman@myofbiz.com
>>>
>>> Anil Patel wrote:
>>>
>>>
>>>> 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
>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own
>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>
>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder
>>>>>>>>>> if we should not slow down the pace in integrating new features for a short
>>>>>>>>>> period of time and should not make and even greatest effort to have a more
>>>>>>>>>> stable OFBiz.
>>>>>>>>>>
>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the
>>>>>>>>>> community to have a look at them and to fix the most important ones (109 are
>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>
>>>>
>>
>>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Tim:
Ok.
Ruth
Tim Ruppert wrote:
> Write some text that will make it easier and I'll post it in there. If it's confusing, please help to make it better. Those pages were put up there for developers - and having some feedback from a tech writer would definitely be helpful.
>
> Cheers,
> Ruppert
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Dec 9, 2009, at 12:44 PM, Ruth Hoffman wrote:
>
>
>> Hi Jeroen:
>> That would work as long as the instructions etc. were not too complicated. IMO, the existing content is too much for a new user to digest. It works for an experienced OFBiz developer because they know exactly where to go to download code. Someone who has never been to the download page before, well, it is a bit overwhelming as it stands now.
>>
>> Regards,
>> Ruth
>> ----------------------------------------------------
>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>> ruth.hoffman@myofbiz.com
>>
>> Jeroen van der Wal wrote:
>>
>>> IMO the button should direct to a (wiki?)page wich contains links to the
>>> latest 9.04 release, setup instructions and end-user documentation.
>>> -Jeroen
>>>
>>> On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>>>
>>>
>>>
>>>> Hi Jeroen:
>>>> Thanks for you quick reply!
>>>> To the list and the PMC specifically:
>>>> Could we change the "BIG FAT DOWNLOAD" button to point to this
>>>> branch/release? Please? Should I enter this request as a JIRA?
>>>>
>>>> Thanks again.
>>>>
>>>> Ruth
>>>> ----------------------------------------------------
>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>> ruth.hoffman@myofbiz.com
>>>> Jeroen van der Wal wrote:
>>>>
>>>>
>>>>
>>>>> Hi Ruth,
>>>>>
>>>>> Branching is a term common to developers so I understand the confusion.
>>>>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>>>>> for the latest version of the latest release use this link:
>>>>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>>>>> Again a point proven that the community is focused towards developers.
>>>>> Keep
>>>>> asking.
>>>>> -Jeroen
>>>>>
>>>>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Anil:
>>>>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>>>>> could we please take this logic one step further?
>>>>>>
>>>>>> Which of the many download options on the http://build.ofbiz.org is the
>>>>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>>>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>>>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>>>>> there
>>>>>> with that release; no need to go down that path :-)
>>>>>>
>>>>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>>>>> staring
>>>>>> at the page longer? Did I miss something?
>>>>>>
>>>>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>>>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>>>>
>>>>>> Regards,
>>>>>> Ruth
>>>>>> ----------------------------------------------------
>>>>>>
>>>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>>>> ruth.hoffman@myofbiz.com
>>>>>>
>>>>>> Anil Patel wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>>>>> own
>>>>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>>>>> wonder
>>>>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>>>>> for a short
>>>>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>>>>> have a more
>>>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>>>>> the
>>>>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>>>>> ones (109 are
>>>>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jacques
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
Write some text that will make it easier and I'll post it in there. If it's confusing, please help to make it better. Those pages were put up there for developers - and having some feedback from a tech writer would definitely be helpful.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Dec 9, 2009, at 12:44 PM, Ruth Hoffman wrote:
> Hi Jeroen:
> That would work as long as the instructions etc. were not too complicated. IMO, the existing content is too much for a new user to digest. It works for an experienced OFBiz developer because they know exactly where to go to download code. Someone who has never been to the download page before, well, it is a bit overwhelming as it stands now.
>
> Regards,
> Ruth
> ----------------------------------------------------
> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
> ruth.hoffman@myofbiz.com
>
> Jeroen van der Wal wrote:
>> IMO the button should direct to a (wiki?)page wich contains links to the
>> latest 9.04 release, setup instructions and end-user documentation.
>> -Jeroen
>>
>> On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>>
>>
>>> Hi Jeroen:
>>> Thanks for you quick reply!
>>> To the list and the PMC specifically:
>>> Could we change the "BIG FAT DOWNLOAD" button to point to this
>>> branch/release? Please? Should I enter this request as a JIRA?
>>>
>>> Thanks again.
>>>
>>> Ruth
>>> ----------------------------------------------------
>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>> ruth.hoffman@myofbiz.com
>>> Jeroen van der Wal wrote:
>>>
>>>
>>>> Hi Ruth,
>>>>
>>>> Branching is a term common to developers so I understand the confusion.
>>>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>>>> for the latest version of the latest release use this link:
>>>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>>>> Again a point proven that the community is focused towards developers.
>>>> Keep
>>>> asking.
>>>> -Jeroen
>>>>
>>>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Anil:
>>>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>>>> could we please take this logic one step further?
>>>>>
>>>>> Which of the many download options on the http://build.ofbiz.org is the
>>>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>>>> there
>>>>> with that release; no need to go down that path :-)
>>>>>
>>>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>>>> staring
>>>>> at the page longer? Did I miss something?
>>>>>
>>>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>>>
>>>>> Regards,
>>>>> Ruth
>>>>> ----------------------------------------------------
>>>>>
>>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>>> ruth.hoffman@myofbiz.com
>>>>>
>>>>> Anil Patel wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>>>> own
>>>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>>>> wonder
>>>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>>>> for a short
>>>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>>>> have a more
>>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>>>> the
>>>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>>>> ones (109 are
>>>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>>
>>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
In the directions to use we need to distinguish users from devs
2 sections (with adequate short obvious explanation in their title) seem enough to me
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
From: "Ruth Hoffman" <rh...@aesolves.com>
> Hi Jeroen:
> That would work as long as the instructions etc. were not too
> complicated. IMO, the existing content is too much for a new user to
> digest. It works for an experienced OFBiz developer because they know
> exactly where to go to download code. Someone who has never been to the
> download page before, well, it is a bit overwhelming as it stands now.
>
> Regards,
> Ruth
> ----------------------------------------------------
> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
> ruth.hoffman@myofbiz.com
>
> Jeroen van der Wal wrote:
>> IMO the button should direct to a (wiki?)page wich contains links to the
>> latest 9.04 release, setup instructions and end-user documentation.
>> -Jeroen
>>
>> On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>>
>>
>>> Hi Jeroen:
>>> Thanks for you quick reply!
>>> To the list and the PMC specifically:
>>> Could we change the "BIG FAT DOWNLOAD" button to point to this
>>> branch/release? Please? Should I enter this request as a JIRA?
>>>
>>> Thanks again.
>>>
>>> Ruth
>>> ----------------------------------------------------
>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>> ruth.hoffman@myofbiz.com
>>> Jeroen van der Wal wrote:
>>>
>>>
>>>> Hi Ruth,
>>>>
>>>> Branching is a term common to developers so I understand the confusion.
>>>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>>>> for the latest version of the latest release use this link:
>>>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>>>> Again a point proven that the community is focused towards developers.
>>>> Keep
>>>> asking.
>>>> -Jeroen
>>>>
>>>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Anil:
>>>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>>>> could we please take this logic one step further?
>>>>>
>>>>> Which of the many download options on the http://build.ofbiz.org is the
>>>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>>>> there
>>>>> with that release; no need to go down that path :-)
>>>>>
>>>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>>>> staring
>>>>> at the page longer? Did I miss something?
>>>>>
>>>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>>>
>>>>> Regards,
>>>>> Ruth
>>>>> ----------------------------------------------------
>>>>>
>>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>>> ruth.hoffman@myofbiz.com
>>>>>
>>>>> Anil Patel wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>>>> own
>>>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>>>> wonder
>>>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>>>> for a short
>>>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>>>> have a more
>>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>>>> the
>>>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>>>> ones (109 are
>>>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Jeroen:
That would work as long as the instructions etc. were not too
complicated. IMO, the existing content is too much for a new user to
digest. It works for an experienced OFBiz developer because they know
exactly where to go to download code. Someone who has never been to the
download page before, well, it is a bit overwhelming as it stands now.
Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
ruth.hoffman@myofbiz.com
Jeroen van der Wal wrote:
> IMO the button should direct to a (wiki?)page wich contains links to the
> latest 9.04 release, setup instructions and end-user documentation.
> -Jeroen
>
> On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>
>
>> Hi Jeroen:
>> Thanks for you quick reply!
>> To the list and the PMC specifically:
>> Could we change the "BIG FAT DOWNLOAD" button to point to this
>> branch/release? Please? Should I enter this request as a JIRA?
>>
>> Thanks again.
>>
>> Ruth
>> ----------------------------------------------------
>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>> ruth.hoffman@myofbiz.com
>> Jeroen van der Wal wrote:
>>
>>
>>> Hi Ruth,
>>>
>>> Branching is a term common to developers so I understand the confusion.
>>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>>> for the latest version of the latest release use this link:
>>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>>> Again a point proven that the community is focused towards developers.
>>> Keep
>>> asking.
>>> -Jeroen
>>>
>>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>>> Hi Anil:
>>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>>> could we please take this logic one step further?
>>>>
>>>> Which of the many download options on the http://build.ofbiz.org is the
>>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>>> there
>>>> with that release; no need to go down that path :-)
>>>>
>>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>>> staring
>>>> at the page longer? Did I miss something?
>>>>
>>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>>
>>>> Regards,
>>>> Ruth
>>>> ----------------------------------------------------
>>>>
>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>> ruth.hoffman@myofbiz.com
>>>>
>>>> Anil Patel wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> 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
>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>>> own
>>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>>
>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>>> wonder
>>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>>> for a short
>>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>>> have a more
>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>
>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>>> the
>>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>>> ones (109 are
>>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Tim,
I just suggested to have a page editable in OFBIZADMIN (one of 4 spaces on 5 with restricted rights) with appropritate redirect from
and to links, for easier admin. But yes maybe it's not a good idea
BTW, I tried to login to ofbiz-vm.apache.org today and my key was refused. I was precisely looking for these pages and other stuff
pending
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
----- Original Message -----
From: "Tim Ruppert" <ti...@hotwaxmedia.com>
To: <de...@ofbiz.apache.org>
Sent: Thursday, December 10, 2009 12:06 AM
Subject: Re: New Users and OFBiz versions was: Bugs and open Jira issues
You do not want to maintain these download pages in a wiki Jacques - that what all of the infra that we built and Gavin worked on is
for. You can certainly have more explanations there, but the page with all of the older downloads, etc - should never be in the
wiki.
Btw, as far as people updating them. We can check in the code for people to maintain as part of the project whenever - we only did
it and maintained these copies because they were our servers.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Dec 9, 2009, at 2:01 PM, Jacques Le Roux wrote:
> I quicky suggested to use as a basis Ruth's proposition as 1st level then Anil's at 2d level
> I agree a wiki page would be better because it introduce a wider possibilty (population) to edit.
> Actually apart from the main page and some technicals infra pages we should try to have all the documentation in the wiki, it's
> almost done ...
>
> It's always end up to who will do it and when...
>
> Remember that even if you no rights to edit a page (4 of our 5 spaces are not widely open) you can always put a comment (with the
> same edit possibility) and ask for it to be officialy pusblished (and also any comment can be linked to)
>
> Thanks
>
> Jacques
> () ascii ribbon campaign against HTML e-mail
> /\ www.asciiribbon.org
>
>
> From: "Jeroen van der Wal" <jv...@stromboli.it>
>> IMO the button should direct to a (wiki?)page wich contains links to the
>> latest 9.04 release, setup instructions and end-user documentation.
>> -Jeroen
>>
>> On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>>
>>> Hi Jeroen:
>>> Thanks for you quick reply!
>>> To the list and the PMC specifically:
>>> Could we change the "BIG FAT DOWNLOAD" button to point to this
>>> branch/release? Please? Should I enter this request as a JIRA?
>>>
>>> Thanks again.
>>>
>>> Ruth
>>> ----------------------------------------------------
>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>> ruth.hoffman@myofbiz.com
>>> Jeroen van der Wal wrote:
>>>
>>>> Hi Ruth,
>>>>
>>>> Branching is a term common to developers so I understand the confusion.
>>>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>>>> for the latest version of the latest release use this link:
>>>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>>>> Again a point proven that the community is focused towards developers.
>>>> Keep
>>>> asking.
>>>> -Jeroen
>>>>
>>>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Hi Anil:
>>>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>>>> could we please take this logic one step further?
>>>>>
>>>>> Which of the many download options on the http://build.ofbiz.org is the
>>>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>>>> there
>>>>> with that release; no need to go down that path :-)
>>>>>
>>>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>>>> staring
>>>>> at the page longer? Did I miss something?
>>>>>
>>>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>>>
>>>>> Regards,
>>>>> Ruth
>>>>> ----------------------------------------------------
>>>>>
>>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>>> ruth.hoffman@myofbiz.com
>>>>>
>>>>> Anil Patel wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>>>> own
>>>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>>>> wonder
>>>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>>>> for a short
>>>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>>>> have a more
>>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>>>> the
>>>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>>>> ones (109 are
>>>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
You do not want to maintain these download pages in a wiki Jacques - that what all of the infra that we built and Gavin worked on is for. You can certainly have more explanations there, but the page with all of the older downloads, etc - should never be in the wiki.
Btw, as far as people updating them. We can check in the code for people to maintain as part of the project whenever - we only did it and maintained these copies because they were our servers.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Dec 9, 2009, at 2:01 PM, Jacques Le Roux wrote:
> I quicky suggested to use as a basis Ruth's proposition as 1st level then Anil's at 2d level
> I agree a wiki page would be better because it introduce a wider possibilty (population) to edit.
> Actually apart from the main page and some technicals infra pages we should try to have all the documentation in the wiki, it's almost done ...
>
> It's always end up to who will do it and when...
>
> Remember that even if you no rights to edit a page (4 of our 5 spaces are not widely open) you can always put a comment (with the same edit possibility) and ask for it to be officialy pusblished (and also any comment can be linked to)
>
> Thanks
>
> Jacques
> () ascii ribbon campaign against HTML e-mail
> /\ www.asciiribbon.org
>
>
> From: "Jeroen van der Wal" <jv...@stromboli.it>
>> IMO the button should direct to a (wiki?)page wich contains links to the
>> latest 9.04 release, setup instructions and end-user documentation.
>> -Jeroen
>>
>> On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>>
>>> Hi Jeroen:
>>> Thanks for you quick reply!
>>> To the list and the PMC specifically:
>>> Could we change the "BIG FAT DOWNLOAD" button to point to this
>>> branch/release? Please? Should I enter this request as a JIRA?
>>>
>>> Thanks again.
>>>
>>> Ruth
>>> ----------------------------------------------------
>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>> ruth.hoffman@myofbiz.com
>>> Jeroen van der Wal wrote:
>>>
>>>> Hi Ruth,
>>>>
>>>> Branching is a term common to developers so I understand the confusion.
>>>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>>>> for the latest version of the latest release use this link:
>>>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>>>> Again a point proven that the community is focused towards developers.
>>>> Keep
>>>> asking.
>>>> -Jeroen
>>>>
>>>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Hi Anil:
>>>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>>>> could we please take this logic one step further?
>>>>>
>>>>> Which of the many download options on the http://build.ofbiz.org is the
>>>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>>>> there
>>>>> with that release; no need to go down that path :-)
>>>>>
>>>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>>>> staring
>>>>> at the page longer? Did I miss something?
>>>>>
>>>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>>>
>>>>> Regards,
>>>>> Ruth
>>>>> ----------------------------------------------------
>>>>>
>>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>>> ruth.hoffman@myofbiz.com
>>>>>
>>>>> Anil Patel wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>>>> own
>>>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>>>> wonder
>>>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>>>> for a short
>>>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>>>> have a more
>>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>>
>>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>>>> the
>>>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>>>> ones (109 are
>>>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
I quicky suggested to use as a basis Ruth's proposition as 1st level then Anil's at 2d level
I agree a wiki page would be better because it introduce a wider possibilty (population) to edit.
Actually apart from the main page and some technicals infra pages we should try to have all the documentation in the wiki, it's
almost done ...
It's always end up to who will do it and when...
Remember that even if you no rights to edit a page (4 of our 5 spaces are not widely open) you can always put a comment (with the
same edit possibility) and ask for it to be officialy pusblished (and also any comment can be linked to)
Thanks
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
From: "Jeroen van der Wal" <jv...@stromboli.it>
> IMO the button should direct to a (wiki?)page wich contains links to the
> latest 9.04 release, setup instructions and end-user documentation.
> -Jeroen
>
> On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>
>> Hi Jeroen:
>> Thanks for you quick reply!
>> To the list and the PMC specifically:
>> Could we change the "BIG FAT DOWNLOAD" button to point to this
>> branch/release? Please? Should I enter this request as a JIRA?
>>
>> Thanks again.
>>
>> Ruth
>> ----------------------------------------------------
>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>> ruth.hoffman@myofbiz.com
>> Jeroen van der Wal wrote:
>>
>>> Hi Ruth,
>>>
>>> Branching is a term common to developers so I understand the confusion.
>>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>>> for the latest version of the latest release use this link:
>>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>>> Again a point proven that the community is focused towards developers.
>>> Keep
>>> asking.
>>> -Jeroen
>>>
>>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>>> wrote:
>>>
>>>
>>>
>>>> Hi Anil:
>>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>>> could we please take this logic one step further?
>>>>
>>>> Which of the many download options on the http://build.ofbiz.org is the
>>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>>> there
>>>> with that release; no need to go down that path :-)
>>>>
>>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>>> staring
>>>> at the page longer? Did I miss something?
>>>>
>>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>>
>>>> Regards,
>>>> Ruth
>>>> ----------------------------------------------------
>>>>
>>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>>> ruth.hoffman@myofbiz.com
>>>>
>>>> Anil Patel wrote:
>>>>
>>>>
>>>>
>>>>> 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
>>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>>> own
>>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>>
>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>>> wonder
>>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>>> for a short
>>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>>> have a more
>>>>>>>>>>> stable OFBiz.
>>>>>>>>>>>
>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>>> the
>>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>>> ones (109 are
>>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jeroen van der Wal <jv...@stromboli.it>.
IMO the button should direct to a (wiki?)page wich contains links to the
latest 9.04 release, setup instructions and end-user documentation.
-Jeroen
On Wed, Dec 9, 2009 at 7:44 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
> Hi Jeroen:
> Thanks for you quick reply!
> To the list and the PMC specifically:
> Could we change the "BIG FAT DOWNLOAD" button to point to this
> branch/release? Please? Should I enter this request as a JIRA?
>
> Thanks again.
>
> Ruth
> ----------------------------------------------------
> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
> ruth.hoffman@myofbiz.com
> Jeroen van der Wal wrote:
>
>> Hi Ruth,
>>
>> Branching is a term common to developers so I understand the confusion.
>> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
>> for the latest version of the latest release use this link:
>> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
>> Again a point proven that the community is focused towards developers.
>> Keep
>> asking.
>> -Jeroen
>>
>> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com>
>> wrote:
>>
>>
>>
>>> Hi Anil:
>>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>>> could we please take this logic one step further?
>>>
>>> Which of the many download options on the http://build.ofbiz.org is the
>>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
>>> there
>>> with that release; no need to go down that path :-)
>>>
>>> I don't see the word "Branch" anywhere on this page. Should I keep
>>> staring
>>> at the page longer? Did I miss something?
>>>
>>> Seriously, I want to start with a new, clean version of OFBiz and begin
>>> some 9.04 updates to my books. Where should I start in your estimation?
>>>
>>> Regards,
>>> Ruth
>>> ----------------------------------------------------
>>>
>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>> ruth.hoffman@myofbiz.com
>>>
>>> Anil Patel wrote:
>>>
>>>
>>>
>>>> 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
>>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my
>>>>>>>>>> own
>>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>>
>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>>> It's really great to see new features in OFBiz. But I really
>>>>>>>>>> wonder
>>>>>>>>>> if we should not slow down the pace in integrating new features
>>>>>>>>>> for a short
>>>>>>>>>> period of time and should not make and even greatest effort to
>>>>>>>>>> have a more
>>>>>>>>>> stable OFBiz.
>>>>>>>>>>
>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for
>>>>>>>>>> the
>>>>>>>>>> community to have a look at them and to fix the most important
>>>>>>>>>> ones (109 are
>>>>>>>>>> considered as at least important) ?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Jeroen:
Thanks for you quick reply!
To the list and the PMC specifically:
Could we change the "BIG FAT DOWNLOAD" button to point to this
branch/release? Please? Should I enter this request as a JIRA?
Thanks again.
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
ruth.hoffman@myofbiz.com
Jeroen van der Wal wrote:
> Hi Ruth,
>
> Branching is a term common to developers so I understand the confusion.
> There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
> for the latest version of the latest release use this link:
> http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
> Again a point proven that the community is focused towards developers. Keep
> asking.
> -Jeroen
>
> On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>
>
>> Hi Anil:
>> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
>> could we please take this logic one step further?
>>
>> Which of the many download options on the http://build.ofbiz.org is the
>> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
>> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
>> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been there
>> with that release; no need to go down that path :-)
>>
>> I don't see the word "Branch" anywhere on this page. Should I keep staring
>> at the page longer? Did I miss something?
>>
>> Seriously, I want to start with a new, clean version of OFBiz and begin
>> some 9.04 updates to my books. Where should I start in your estimation?
>>
>> Regards,
>> Ruth
>> ----------------------------------------------------
>>
>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>> ruth.hoffman@myofbiz.com
>>
>> Anil Patel wrote:
>>
>>
>>> 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
>>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own
>>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>>
>>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>>> It's really great to see new features in OFBiz. But I really wonder
>>>>>>>>> if we should not slow down the pace in integrating new features for a short
>>>>>>>>> period of time and should not make and even greatest effort to have a more
>>>>>>>>> stable OFBiz.
>>>>>>>>>
>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the
>>>>>>>>> community to have a look at them and to fix the most important ones (109 are
>>>>>>>>> considered as at least important) ?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>
>>>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Jeroen van der Wal <jv...@stromboli.it>.
Hi Ruth,
Branching is a term common to developers so I understand the confusion.
There are two release branches in Ofbiz, 4.0 and 9.04 so if you're looking
for the latest version of the latest release use this link:
http://build.ofbiz.org/builds904/ofbiz-rel9.04-current.zip
Again a point proven that the community is focused towards developers. Keep
asking.
-Jeroen
On Wed, Dec 9, 2009 at 7:30 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
> Hi Anil:
> Thanks for your notes. Please excuse me if I seem a bit pushy here, but
> could we please take this logic one step further?
>
> Which of the many download options on the http://build.ofbiz.org is the
> "Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
> "Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
> of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been there
> with that release; no need to go down that path :-)
>
> I don't see the word "Branch" anywhere on this page. Should I keep staring
> at the page longer? Did I miss something?
>
> Seriously, I want to start with a new, clean version of OFBiz and begin
> some 9.04 updates to my books. Where should I start in your estimation?
>
> Regards,
> Ruth
> ----------------------------------------------------
>
> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
> ruth.hoffman@myofbiz.com
>
> Anil Patel wrote:
>
>> 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
>>>>>>> <ja...@les7arts.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'd like to express a feeling I have. Actually it's not only my own
>>>>>>>> feeling but also something some users have expressed recently.
>>>>>>>>
>>>>>>>> I'm quite happy to see that these last times a lot of effort have
>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>>> It's really great to see new features in OFBiz. But I really wonder
>>>>>>>> if we should not slow down the pace in integrating new features for a short
>>>>>>>> period of time and should not make and even greatest effort to have a more
>>>>>>>> stable OFBiz.
>>>>>>>>
>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the
>>>>>>>> community to have a look at them and to fix the most important ones (109 are
>>>>>>>> considered as at least important) ?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>
>>
>>
>>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Anil:
Thanks for your notes. Please excuse me if I seem a bit pushy here, but
could we please take this logic one step further?
Which of the many download options on the http://build.ofbiz.org is the
"Branch" you speak of? I see: "Nightly Trunk Builds" (probably not the
"Branch"); "Nightly Release 9.04 Builds" (perhaps the "Branch" you speak
of?) and I see "Nightly Release 4.0 Builds" (OK, we have already been
there with that release; no need to go down that path :-)
I don't see the word "Branch" anywhere on this page. Should I keep
staring at the page longer? Did I miss something?
Seriously, I want to start with a new, clean version of OFBiz and begin
some 9.04 updates to my books. Where should I start in your estimation?
Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
ruth.hoffman@myofbiz.com
Anil Patel wrote:
> 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
>>>>>> <ja...@les7arts.com> wrote:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>>
>>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>>
>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>
>
>
Re: New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Anil Patel <an...@hotwaxmedia.com>.
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
>>>>> <ja...@les7arts.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>>>
>>>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>>>
>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>