You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2009/12/05 20:51:04 UTC
Bugs and open Jira issues
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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>
New Users and OFBiz versions was: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
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: Bugs and open Jira issues
Posted by Anil Patel <an...@hotwaxmedia.com>.
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: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Scott:
Then stop the committing and do some reviewing. There is more to
software development than committing code to a repository.
Regards,
Ruth
Scott Gray wrote:
> On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
>
>> Thank you Jacques for addressing this as this situation worries me
>> too. Although I think the power of the Ofbiz community can handle it
>> :-)
>>
>> My suggestions would be:
>> - Assign volunteers and a lead to each of the components. They can
>> watch issues of their components and should can be consulted if
>> anybody wants to make changes in their neighbourhood.
>
> We already have these volunteers, they're called people who review
> commits and I could probably count them on one hand.
> Everything you've suggested requires more resources than this
> community can provide.
>
>> - Work bottom up: start with the framework, then the core modules
>> (party, product, accounting, workeffort, manufactureing, order) and
>> finally the specialpurpose modules (I personally consider humanres and
>> marketing to be specialpurpose)
>> - Communicate changes to dependent components so they can sanitize
>> their components
>> - Don't allow code without tests
>> - Use branching for work in progress to maintain a stable trunk (I
>> prefer Git over SVN but that's another topic...)
>>
>> I'm a big fan of branching, this explains why:
>> - Code each task (or related set of tasks) in its own branch, then you
>> will have the flexibility of when you would like to merge these tasks
>> and perform a release.
>> - QA should be done on each branch before it is merged to the trunk.
>> - By doing QA on each individual branch, you will know exactly what
>> caused the bug easier.
>> - This solution scales to any number of developers.
>> - This method works since branching is an almost instant operation in
>> SVN.
>> - Tag each release that you perform.
>> - You can develop features that you don't plan to release for a while
>> and decide exactly when to merge them.
>> - For all work you do, you can have the benefit of committing your
>> code. If you work out of the trunk only, you will probably keep your
>> code uncommitted a lot, and hence unprotected and without automatic
>> history.
>> If you try to do the opposite and do all your development in the trunk
>> you'll be plagged by:
>> - Constant build problems for daily builds
>> - Productivity loss when a a developer commits a problem for all other
>> people on the project
>> - Longer release cycles, because you need to finally get a stable
>> version
>> - Less stable releases
>>
>> Best,
>>
>> Jeroen van der Wal
>>
>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>> <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: Bugs and open Jira issues
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Oops again, I should re-read :/
From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Jeroen van der Wal" <jv...@stromboli.it>
>> Thank you Jacques for addressing this as this situation worries me
>> too. Although I think the power of the Ofbiz community can handle it
>> :-)
>>
>> My suggestions would be:
>> - Assign volunteers and a lead to each of the components. They can
>> watch issues of their components and should can be consulted if
>> anybody wants to make changes in their neighbourhood.
>> - Work bottom up: start with the framework, then the core modules
>> (party, product, accounting, workeffort, manufactureing, order) and
>> finally the specialpurpose modules (I personally consider humanres and
>> marketing to be specialpurpose)
>
> We already mostly proceed this way
> Not sure where to put the limit for marketing and humares, it's true that nothing depends on them
> http://cwiki.apache.org/confluence/x/MYB2
>
>> - Communicate changes to dependent components so they can sanitize
>> their components
>> - Don't allow code without tests
>
> I guess it's still not possible in a near future
>
>> - Use branching for work in progress to maintain a stable trunk (I
>> prefer Git over SVN but that's another topic...)
>
> We already do that, some use Git
>
>> I'm a big fan of branching, this explains why:
>> - Code each task (or related set of tasks) in its own branch, then you
>> will have the flexibility of when you would like to merge these tasks
>> and perform a release.
>> - QA should be done on each branch before it is merged to the trunk.
>> - By doing QA on each individual branch, you will know exactly what
>> caused the bug easier.
>> - This solution scales to any number of developers.
>> - This method works since branching is an almost instant operation in SVN.
>> - Tag each release that you perform.
>> - You can develop features that you don't plan to release for a while
>> and decide exactly when to merge them.
>> - For all work you do, you can have the benefit of committing your
>> code. If you work out of the trunk only, you will probably keep your
>> code uncommitted a lot, and hence unprotected and without automatic
>> history.
>> If you try to do the opposite and do all your development in the trunk
>> you'll be plagged by:
>> - Constant build problems for daily builds
>> - Productivity loss when a a developer commits a problem for all other
>> people on the project
>> - Longer release cycles, because you need to finally get a stable version
>> - Less stable releases
>
> This is mostly true (almost instant operation, mmm..) and I agree.
> But as Scott said,, branching is needs more work and sadly we don't have enough manpower already
But as Scott said, branching needs more work and sadly we don't have enough manpower already
> Thanks Jeroen for sharing your thoughts, experience and knowledge, appreciated
>
> Jacques
>
>> Best,
>>
>> Jeroen van der Wal
>>
>> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
>> <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: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jeroen van der Wal" <jv...@stromboli.it>
> Thank you Jacques for addressing this as this situation worries me
> too. Although I think the power of the Ofbiz community can handle it
> :-)
>
> My suggestions would be:
> - Assign volunteers and a lead to each of the components. They can
> watch issues of their components and should can be consulted if
> anybody wants to make changes in their neighbourhood.
> - Work bottom up: start with the framework, then the core modules
> (party, product, accounting, workeffort, manufactureing, order) and
> finally the specialpurpose modules (I personally consider humanres and
> marketing to be specialpurpose)
We already mostly proceed this way
Not sure where to put the limit for marketing and humares, it's true that nothing depends on them
http://cwiki.apache.org/confluence/x/MYB2
> - Communicate changes to dependent components so they can sanitize
> their components
> - Don't allow code without tests
I guess it's still not possible in a near future
> - Use branching for work in progress to maintain a stable trunk (I
> prefer Git over SVN but that's another topic...)
We already do that, some use Git
> I'm a big fan of branching, this explains why:
> - Code each task (or related set of tasks) in its own branch, then you
> will have the flexibility of when you would like to merge these tasks
> and perform a release.
> - QA should be done on each branch before it is merged to the trunk.
> - By doing QA on each individual branch, you will know exactly what
> caused the bug easier.
> - This solution scales to any number of developers.
> - This method works since branching is an almost instant operation in SVN.
> - Tag each release that you perform.
> - You can develop features that you don't plan to release for a while
> and decide exactly when to merge them.
> - For all work you do, you can have the benefit of committing your
> code. If you work out of the trunk only, you will probably keep your
> code uncommitted a lot, and hence unprotected and without automatic
> history.
> If you try to do the opposite and do all your development in the trunk
> you'll be plagged by:
> - Constant build problems for daily builds
> - Productivity loss when a a developer commits a problem for all other
> people on the project
> - Longer release cycles, because you need to finally get a stable version
> - Less stable releases
This is mostly true (almost instant operation, mmm..) and I agree.
But as Scott said,, branching is needs more work and sadly we don't have enough manpower already
Thanks Jeroen for sharing your thoughts, experience and knowledge, appreciated
Jacques
> Best,
>
> Jeroen van der Wal
>
> On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
> <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: Bugs and open Jira issues
Posted by Jeroen van der Wal <jv...@stromboli.it>.
Thank you Jacques for addressing this as this situation worries me
too. Although I think the power of the Ofbiz community can handle it
:-)
My suggestions would be:
- Assign volunteers and a lead to each of the components. They can
watch issues of their components and should can be consulted if
anybody wants to make changes in their neighbourhood.
- Work bottom up: start with the framework, then the core modules
(party, product, accounting, workeffort, manufactureing, order) and
finally the specialpurpose modules (I personally consider humanres and
marketing to be specialpurpose)
- 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: Bugs and open Jira issues
Posted by Anil Patel <an...@hotwaxmedia.com>.
Jacques,
Thanks for initiative.
Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
On Dec 5, 2009, at 2:51 PM, Jacques Le Roux wrote:
> Hi,
>
> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>
> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>
> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>
> Thanks
>
> Jacques
>
>
>
Re: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Brett:
Its a moving target.
How can there possibly be any progress when the target keeps changing?
Stop the commits, fix the process by establishing automated functional
tests (unit testing doesn't help much in this situation) w/Selenium, and
then begin again.
Ruth
Brett Palmer wrote:
> Ruth,
>
> You make a good point. This has been a topic for a couple of years now. As
> OFBiz continues to grow doing even a simple "smoke test" on the build will
> be difficult. This is why I think the only scalable solution is to run a
> series of automated unit and functional (selenium like) tests on the
> application for each daily build.
>
> If this was automated we could send the ofbiz-dev list an email with the the
> broken tests and the information (stake trace, etc) about the failure.
>
> There are a few of us working on this but getting valid user tests from the
> community would be very helpful.
>
>
> Brett
>
> On Sun, Dec 6, 2009 at 4:57 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>
>
>> Hi David:
>> I wasn't going to say anything about this, but my most recent experience
>> with the nightly trunk download has me fuming again...Just because an
>> organization is made up of volunteers, doesn't mean there is no need for
>> rules, respect for others and most importantly leadership.
>>
>> Here's how I would start to "fix things". I'd say: No more commits until
>> the community gets the one or more processes in place necessary to
>> coordinate testing, builds and releases. Anyone who violates the rule,
>> looses the right to commit. When all the processes are in place and agreed
>> upon, then you can give all the violators back the right to commit.
>>
>> You, David, have the power to give developer's commit access to the source
>> code repository. You, David, can take it away. Or am I wrong about that?
>> Who, BTW, gave all these people commit access to the source code repository
>> initially?
>>
>> Regards,
>> Ruth
>>
>>
>>
>> David E Jones wrote:
>>
>>
>>> To be clear, I'd like to hear from other people too. If anyone has any
>>> ideas about how we can get people to do this, by all means let's discuss it!
>>>
>>> This need and concern has come up in many places many times over the years
>>> of the project. I have some thoughts on good ways to go about this (like the
>>> UBPL stuff, automated testing which is going on now, etc, etc), but how to
>>> get people to do things, especially in a volunteer organization like this,
>>> is another question...
>>>
>>> -David
>>>
>>>
>>> On Dec 6, 2009, at 12:29 PM, Jacques Le Roux wrote:
>>>
>>>
>>>
>>>
>>>> Hi David,
>>>>
>>>> I have no answers yet, I must says I have not even thought about it...
>>>> For the moment I only propose to concentrate on existing known bugs
>>>> repertoried in opened Jira issues.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>> () ascii ribbon campaign against HTML e-mail
>>>> /\ www.asciiribbon.org
>>>>
>>>>
>>>> ----- Original Message ----- From: "David E Jones" <de...@me.com>
>>>> To: <de...@ofbiz.apache.org>
>>>> Sent: Sunday, December 06, 2009 6:36 PM
>>>> Subject: Re: Bugs and open Jira issues
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Jacques,
>>>>>
>>>>> I appreciate this feeling. In general OFBiz would benefit a lot from
>>>>> more testing, more definition of what to test against (ie what does a pass
>>>>> or fail look like, ie what is the design to test against), and in general
>>>>> more care about respecting others by not breaking things that already exist.
>>>>>
>>>>> The questions is, how do we get people to do this?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to express a feeling I have. Actually it's not only my own
>>>>>> feeling but also something some users have expressed recently.
>>>>>>
>>>>>> I'm quite happy to see that these last times a lot of effort have been
>>>>>> made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>> It's really great to see new features in OFBiz. But I really wonder if
>>>>>> we should not slow down the pace in integrating new features for a short
>>>>>> period of time and should not make and even greatest effort to have a more
>>>>>> stable OFBiz.
>>>>>>
>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the
>>>>>> community to have a look at them and to fix the most important ones (109 are
>>>>>> considered as at least important) ?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>
>
Re: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Brett Palmer" <br...@gmail.com>
> Ruth,
>
> You make a good point. This has been a topic for a couple of years now. As
> OFBiz continues to grow doing even a simple "smoke test" on the build will
> be difficult. This is why I think the only scalable solution is to run a
> series of automated unit and functional (selenium like) tests on the
> application for each daily build.
>
> If this was automated we could send the ofbiz-dev list an email with the the
> broken tests and the information (stake trace, etc) about the failure.
It's automated see stdio in the red part of the Waterfall (tests don't pass these last times)
Waterfall : http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk&reload=none
Test : http://ci.apache.org/builders/ofbiz-trunk/builds/2004/steps/compile_1/logs/stdio
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
> There are a few of us working on this but getting valid user tests from the
> community would be very helpful.
>
>
> Brett
>
> On Sun, Dec 6, 2009 at 4:57 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
>
>> Hi David:
>> I wasn't going to say anything about this, but my most recent experience
>> with the nightly trunk download has me fuming again...Just because an
>> organization is made up of volunteers, doesn't mean there is no need for
>> rules, respect for others and most importantly leadership.
>>
>> Here's how I would start to "fix things". I'd say: No more commits until
>> the community gets the one or more processes in place necessary to
>> coordinate testing, builds and releases. Anyone who violates the rule,
>> looses the right to commit. When all the processes are in place and agreed
>> upon, then you can give all the violators back the right to commit.
>>
>> You, David, have the power to give developer's commit access to the source
>> code repository. You, David, can take it away. Or am I wrong about that?
>> Who, BTW, gave all these people commit access to the source code repository
>> initially?
>>
>> Regards,
>> Ruth
>>
>>
>>
>> David E Jones wrote:
>>
>>> To be clear, I'd like to hear from other people too. If anyone has any
>>> ideas about how we can get people to do this, by all means let's discuss it!
>>>
>>> This need and concern has come up in many places many times over the years
>>> of the project. I have some thoughts on good ways to go about this (like the
>>> UBPL stuff, automated testing which is going on now, etc, etc), but how to
>>> get people to do things, especially in a volunteer organization like this,
>>> is another question...
>>>
>>> -David
>>>
>>>
>>> On Dec 6, 2009, at 12:29 PM, Jacques Le Roux wrote:
>>>
>>>
>>>
>>>> Hi David,
>>>>
>>>> I have no answers yet, I must says I have not even thought about it...
>>>> For the moment I only propose to concentrate on existing known bugs
>>>> repertoried in opened Jira issues.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>> () ascii ribbon campaign against HTML e-mail
>>>> /\ www.asciiribbon.org
>>>>
>>>>
>>>> ----- Original Message ----- From: "David E Jones" <de...@me.com>
>>>> To: <de...@ofbiz.apache.org>
>>>> Sent: Sunday, December 06, 2009 6:36 PM
>>>> Subject: Re: Bugs and open Jira issues
>>>>
>>>>
>>>>
>>>>
>>>>> Jacques,
>>>>>
>>>>> I appreciate this feeling. In general OFBiz would benefit a lot from
>>>>> more testing, more definition of what to test against (ie what does a pass
>>>>> or fail look like, ie what is the design to test against), and in general
>>>>> more care about respecting others by not breaking things that already exist.
>>>>>
>>>>> The questions is, how do we get people to do this?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to express a feeling I have. Actually it's not only my own
>>>>>> feeling but also something some users have expressed recently.
>>>>>>
>>>>>> I'm quite happy to see that these last times a lot of effort have been
>>>>>> made in order to fix OFBiz (yes to fix OFBiz!)
>>>>>> It's really great to see new features in OFBiz. But I really wonder if
>>>>>> we should not slow down the pace in integrating new features for a short
>>>>>> period of time and should not make and even greatest effort to have a more
>>>>>> stable OFBiz.
>>>>>>
>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the
>>>>>> community to have a look at them and to fix the most important ones (109 are
>>>>>> considered as at least important) ?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
Re: Bugs and open Jira issues
Posted by Brett Palmer <br...@gmail.com>.
Ruth,
You make a good point. This has been a topic for a couple of years now. As
OFBiz continues to grow doing even a simple "smoke test" on the build will
be difficult. This is why I think the only scalable solution is to run a
series of automated unit and functional (selenium like) tests on the
application for each daily build.
If this was automated we could send the ofbiz-dev list an email with the the
broken tests and the information (stake trace, etc) about the failure.
There are a few of us working on this but getting valid user tests from the
community would be very helpful.
Brett
On Sun, Dec 6, 2009 at 4:57 PM, Ruth Hoffman <rh...@aesolves.com> wrote:
> Hi David:
> I wasn't going to say anything about this, but my most recent experience
> with the nightly trunk download has me fuming again...Just because an
> organization is made up of volunteers, doesn't mean there is no need for
> rules, respect for others and most importantly leadership.
>
> Here's how I would start to "fix things". I'd say: No more commits until
> the community gets the one or more processes in place necessary to
> coordinate testing, builds and releases. Anyone who violates the rule,
> looses the right to commit. When all the processes are in place and agreed
> upon, then you can give all the violators back the right to commit.
>
> You, David, have the power to give developer's commit access to the source
> code repository. You, David, can take it away. Or am I wrong about that?
> Who, BTW, gave all these people commit access to the source code repository
> initially?
>
> Regards,
> Ruth
>
>
>
> David E Jones wrote:
>
>> To be clear, I'd like to hear from other people too. If anyone has any
>> ideas about how we can get people to do this, by all means let's discuss it!
>>
>> This need and concern has come up in many places many times over the years
>> of the project. I have some thoughts on good ways to go about this (like the
>> UBPL stuff, automated testing which is going on now, etc, etc), but how to
>> get people to do things, especially in a volunteer organization like this,
>> is another question...
>>
>> -David
>>
>>
>> On Dec 6, 2009, at 12:29 PM, Jacques Le Roux wrote:
>>
>>
>>
>>> Hi David,
>>>
>>> I have no answers yet, I must says I have not even thought about it...
>>> For the moment I only propose to concentrate on existing known bugs
>>> repertoried in opened Jira issues.
>>>
>>> Thanks
>>>
>>> Jacques
>>> () ascii ribbon campaign against HTML e-mail
>>> /\ www.asciiribbon.org
>>>
>>>
>>> ----- Original Message ----- From: "David E Jones" <de...@me.com>
>>> To: <de...@ofbiz.apache.org>
>>> Sent: Sunday, December 06, 2009 6:36 PM
>>> Subject: Re: Bugs and open Jira issues
>>>
>>>
>>>
>>>
>>>> Jacques,
>>>>
>>>> I appreciate this feeling. In general OFBiz would benefit a lot from
>>>> more testing, more definition of what to test against (ie what does a pass
>>>> or fail look like, ie what is the design to test against), and in general
>>>> more care about respecting others by not breaking things that already exist.
>>>>
>>>> The questions is, how do we get people to do this?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I'd like to express a feeling I have. Actually it's not only my own
>>>>> feeling but also something some users have expressed recently.
>>>>>
>>>>> I'm quite happy to see that these last times a lot of effort have been
>>>>> made in order to fix OFBiz (yes to fix OFBiz!)
>>>>> It's really great to see new features in OFBiz. But I really wonder if
>>>>> we should not slow down the pace in integrating new features for a short
>>>>> period of time and should not make and even greatest effort to have a more
>>>>> stable OFBiz.
>>>>>
>>>>> There are 180 bugs opened in Jira. Don't you think it's time for the
>>>>> community to have a look at them and to fix the most important ones (109 are
>>>>> considered as at least important) ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>>
>
Re: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Bilgin,
Yes this seems fine to me
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
From: "Bilgin Ibryam" <bi...@gmail.com>
> Jacques Le Roux wrote:
>>
>> Don't misundersand me. I'm not worried about new bugs. I totally
>> understand that this is intrinsic nature of software.
>> My point is only for us to give more love to these 109 issues waiting
>> attention in Jira, nothing else...
>>
> Jacques,
>
> I think we should prioritize the bug issues as follow:
>
> - if an issue doesn't have a patch, ignore it, as nobody is affected by
> it yet. There will be a patch as soon as someone wants it to be fixed.
> - it there is a patch attached, give priority to issues which have at
> lease one review/test (from other users or committers, it doesn;t
> matter) which indicates that the patch is tested and working fine. Or
> there is a VOTE for the issue, meaning that it is not tested/reviewed
> but sounds as a good fix/idea.
>
> This would encourage also other users to review the patches.
>
> my 2 cents
>
> Bilgin
Re: Bugs and open Jira issues
Posted by Bilgin Ibryam <bi...@gmail.com>.
Jacques Le Roux wrote:
>
> Don't misundersand me. I'm not worried about new bugs. I totally
> understand that this is intrinsic nature of software.
> My point is only for us to give more love to these 109 issues waiting
> attention in Jira, nothing else...
>
Jacques,
I think we should prioritize the bug issues as follow:
- if an issue doesn't have a patch, ignore it, as nobody is affected by
it yet. There will be a patch as soon as someone wants it to be fixed.
- it there is a patch attached, give priority to issues which have at
lease one review/test (from other users or committers, it doesn;t
matter) which indicates that the patch is tested and working fine. Or
there is a VOTE for the issue, meaning that it is not tested/reviewed
but sounds as a good fix/idea.
This would encourage also other users to review the patches.
my 2 cents
Bilgin
Re: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Oops,
From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Scott Gray" <sc...@hotwaxmedia.com>
>> On 7/12/2009, at 10:05 PM, Jacques Le Roux wrote:
>>
>>> Please Scott,
>>>
>>> Inline...
>>>
>>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>>> I disagree, there always have been and always will be bugs in OFBiz, there is no escaping this fact. The only reason there
>>>> are more bugs now than there were 3 years ago is because there is more community activity. Fixing the bugs in jira will
>>>> not prevent new bugs from replacing them (and some of the replacements will be the same bugs we just fixed).
>>>
>>> Don't misundersand me. I'm not worried about new bugs. I totally understand that this is intrinsic nature of software.
>>> My point is only for us to give more love to these 109 issues waiting attention in Jira, nothing else...
>>
>> I'm saying it's pointless giving them any love without writing tests for those bugs first. Every code change (even bug fixes)
>> carries the risk of introducing new bugs and the only thing we can do to reduce that risk is to write tests. Without tests the
>> number of bugs in jira will never do anything but increase.
>
> Scott,
>
> As I already said, I completly agree contiuous integration with tests running is the right way to go. We have already some tests,
> and for instance Ashish have got some work from them...
Ashish has got
> I see Gavin is currently working for us (commits in infra) and we are some to push to have all things on ASF servers soon.
> BTW I think this means more work for us on the future as I guess we will have any less help than with Contegix...
we will have less help
> But I don't agree that this should prevent us to fix existing bugs in the meantime...
>
> Jacques
> () ascii ribbon campaign against HTML e-mail
> /\ www.asciiribbon.org
>
>>>> IMO the best thing we can do for the stability of the project is to create tests every time we create or modify a service, be
>>>> it during a bug fix or while implementing new functionality. Doing so locks in the desired behavior and prevents anyone
>>>> from unknowingly changing that behavior.
>>>
>>> Yes, I plenty agree
>>>
>>>> Even without intervention, bugs naturally get fixed over time as people come to require the functionality being blocked by
>>>> the bug, the key is to do everything we can to reduce the number of new bugs being created.
>>>
>>> I totally agree, I can agree more I should say. i think I should have used "Opened important Jira issues" as subject :/
>>>
>>> Jacques
>>> () ascii ribbon campaign against HTML e-mail
>>> /\ www.asciiribbon.org
>>>
>>>> Regards
>>>> Scott
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>> On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
>>>>> Thi is all great,
>>>>>
>>>>> Put please ladies/gents don't get out of subject.
>>>>> I still think the 1st step is to fix the bugs we know exist, are documented in Jira and even ready to be fixed with patches
>>>>> for some.
>>>>>
>>>>> Jacques
>>>>> () ascii ribbon campaign against HTML e-mail
>>>>> /\ www.asciiribbon.org
>>>>>
>>>>>
>>>>> From: "Anil Patel" <an...@hotwaxmedia.com>
>>>>>> We do see some great Ideas around what is needed. There was lot of conversation on this topic in ApacheCon 2008 and then in
>>>>>> 2009 (based on messages on list).
>>>>>>
>>>>>> You will be surprised there is lot done. We have seen lot of activity in documenting business processes and end user
>>>>>> documentation.
>>>>>>
>>>>>> More recently David proposed a simple system derived from Ofbiz that will address needs of small business.
>>>>>>
>>>>>> We have lot more Ofbiz technical contributors then Business process knowledge contributors. It will be really nice if
>>>>>> people in this part of community will step up. It will be nice if business users or power business users who are technical
>>>>>> developers as well started to take part of requirement documents and add to UBPL or EZBIZ effort.
>>>>>>
>>>>>> If users can document their business processes needs, give some wireframe help then technical developers will be able to
>>>>>> help map them to OOTB features (Gap Analysis).
>>>>>>
>>>>>> Unless we get real business requirements documents coming from user community there is no way for us to fulfill them.
>>>>>>
>>>>>> I hope you understand I am not asking anybody to break NDA or whatever.
>>>>>>
>>>>>> Thanks and Regards
>>>>>> Anil Patel
>>>>>> HotWax Media Inc
>>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>>
>>>>>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> Here my opinion about the subject.
>>>>>>> To make things clear, it makes about 3-4 month I am working with
>>>>>>> OFBiz, using it to implement a project.
>>>>>>>
>>>>>>> I thing one way to have more people involved in the project is to
>>>>>>> lower the "difficulty level" required to understand OFBiz.
>>>>>>>
>>>>>>> And for this there are several possbilities, and I will focus on two :
>>>>>>> - modularize the project
>>>>>>> - more functional documentation inside the source files
>>>>>>>
>>>>>>> Modularize the project
>>>>>>>
>>>>>>> I've seen this subject has already been discussed and I think it can
>>>>>>> profit to the project in several points :
>>>>>>> - more modules means less code in each module, which means modules are
>>>>>>> eaiser to understand, which means more developer may be interesting to
>>>>>>> participate to its development, test, ... There is at least one
>>>>>>> obvious module which could be very interesting to externalize, it's
>>>>>>> the entity engine. I don't know so much OFBiz architecture but I think
>>>>>>> it should be possible to externalize this module and a lot of projects
>>>>>>> totally different of OFBiz could be interesting in it, and so
>>>>>>> potentially a lot more developers to maintain and enhance it.
>>>>>>> - on another side, more modules would also make it easier to
>>>>>>> distribute the issues, each developer specialized on a specific
>>>>>>> module. Maybe it's already the case...
>>>>>>>
>>>>>>> More functional documentation inside the source files
>>>>>>>
>>>>>>> Here my feeling is that with OFBiz, you really requires both technical
>>>>>>> and functional knowledge to understand how the project work. Some part
>>>>>>> like the entity engine are purely technical, but the order module for
>>>>>>> example is really functional, I mean, you need to know a lot about how
>>>>>>> ordering works in a company to be able to use the module and even more
>>>>>>> to custommize or propose enhancements to it. So, with more
>>>>>>> documentation in the source files, like the XML entity files, and then
>>>>>>> in the source code for example explaining what a method concretly does
>>>>>>> may help a lot to understand OFBiz. It seems the link David sent about
>>>>>>> UBML is about his.
>>>>>>>
>>>>>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>>>>>> participate to the project at least by providing bug reports, I still
>>>>>>> feel for away from providing patches ! :-)
>>>>>>>
>>>>>>> Hope this will help you, devs, the project is already great, let's
>>>>>>> make it more accessible !
>>>>>>>
>>>>>>> Cimballi
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
Re: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Scott Gray" <sc...@hotwaxmedia.com>
> On 7/12/2009, at 10:05 PM, Jacques Le Roux wrote:
>
>> Please Scott,
>>
>> Inline...
>>
>> From: "Scott Gray" <sc...@hotwaxmedia.com>
>>> I disagree, there always have been and always will be bugs in OFBiz, there is no escaping this fact. The only reason there
>>> are more bugs now than there were 3 years ago is because there is more community activity. Fixing the bugs in jira will not
>>> prevent new bugs from replacing them (and some of the replacements will be the same bugs we just fixed).
>>
>> Don't misundersand me. I'm not worried about new bugs. I totally understand that this is intrinsic nature of software.
>> My point is only for us to give more love to these 109 issues waiting attention in Jira, nothing else...
>
> I'm saying it's pointless giving them any love without writing tests for those bugs first. Every code change (even bug fixes)
> carries the risk of introducing new bugs and the only thing we can do to reduce that risk is to write tests. Without tests the
> number of bugs in jira will never do anything but increase.
Scott,
As I already said, I completly agree contiuous integration with tests running is the right way to go. We have already some tests,
and for instance Ashish have got some work from them...
I see Gavin is currently working for us (commits in infra) and we are some to push to have all things on ASF servers soon.
BTW I think this means more work for us on the future as I guess we will have any less help than with Contegix...
But I don't agree that this should prevent us to fix existing bugs in the meantime...
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
>>> IMO the best thing we can do for the stability of the project is to create tests every time we create or modify a service, be
>>> it during a bug fix or while implementing new functionality. Doing so locks in the desired behavior and prevents anyone
>>> from unknowingly changing that behavior.
>>
>> Yes, I plenty agree
>>
>>> Even without intervention, bugs naturally get fixed over time as people come to require the functionality being blocked by the
>>> bug, the key is to do everything we can to reduce the number of new bugs being created.
>>
>> I totally agree, I can agree more I should say. i think I should have used "Opened important Jira issues" as subject :/
>>
>> Jacques
>> () ascii ribbon campaign against HTML e-mail
>> /\ www.asciiribbon.org
>>
>>> Regards
>>> Scott
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>> On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
>>>> Thi is all great,
>>>>
>>>> Put please ladies/gents don't get out of subject.
>>>> I still think the 1st step is to fix the bugs we know exist, are documented in Jira and even ready to be fixed with patches
>>>> for some.
>>>>
>>>> Jacques
>>>> () ascii ribbon campaign against HTML e-mail
>>>> /\ www.asciiribbon.org
>>>>
>>>>
>>>> From: "Anil Patel" <an...@hotwaxmedia.com>
>>>>> We do see some great Ideas around what is needed. There was lot of conversation on this topic in ApacheCon 2008 and then in
>>>>> 2009 (based on messages on list).
>>>>>
>>>>> You will be surprised there is lot done. We have seen lot of activity in documenting business processes and end user
>>>>> documentation.
>>>>>
>>>>> More recently David proposed a simple system derived from Ofbiz that will address needs of small business.
>>>>>
>>>>> We have lot more Ofbiz technical contributors then Business process knowledge contributors. It will be really nice if people
>>>>> in this part of community will step up. It will be nice if business users or power business users who are technical
>>>>> developers as well started to take part of requirement documents and add to UBPL or EZBIZ effort.
>>>>>
>>>>> If users can document their business processes needs, give some wireframe help then technical developers will be able to
>>>>> help map them to OOTB features (Gap Analysis).
>>>>>
>>>>> Unless we get real business requirements documents coming from user community there is no way for us to fulfill them.
>>>>>
>>>>> I hope you understand I am not asking anybody to break NDA or whatever.
>>>>>
>>>>> Thanks and Regards
>>>>> Anil Patel
>>>>> HotWax Media Inc
>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>>
>>>>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>> Here my opinion about the subject.
>>>>>> To make things clear, it makes about 3-4 month I am working with
>>>>>> OFBiz, using it to implement a project.
>>>>>>
>>>>>> I thing one way to have more people involved in the project is to
>>>>>> lower the "difficulty level" required to understand OFBiz.
>>>>>>
>>>>>> And for this there are several possbilities, and I will focus on two :
>>>>>> - modularize the project
>>>>>> - more functional documentation inside the source files
>>>>>>
>>>>>> Modularize the project
>>>>>>
>>>>>> I've seen this subject has already been discussed and I think it can
>>>>>> profit to the project in several points :
>>>>>> - more modules means less code in each module, which means modules are
>>>>>> eaiser to understand, which means more developer may be interesting to
>>>>>> participate to its development, test, ... There is at least one
>>>>>> obvious module which could be very interesting to externalize, it's
>>>>>> the entity engine. I don't know so much OFBiz architecture but I think
>>>>>> it should be possible to externalize this module and a lot of projects
>>>>>> totally different of OFBiz could be interesting in it, and so
>>>>>> potentially a lot more developers to maintain and enhance it.
>>>>>> - on another side, more modules would also make it easier to
>>>>>> distribute the issues, each developer specialized on a specific
>>>>>> module. Maybe it's already the case...
>>>>>>
>>>>>> More functional documentation inside the source files
>>>>>>
>>>>>> Here my feeling is that with OFBiz, you really requires both technical
>>>>>> and functional knowledge to understand how the project work. Some part
>>>>>> like the entity engine are purely technical, but the order module for
>>>>>> example is really functional, I mean, you need to know a lot about how
>>>>>> ordering works in a company to be able to use the module and even more
>>>>>> to custommize or propose enhancements to it. So, with more
>>>>>> documentation in the source files, like the XML entity files, and then
>>>>>> in the source code for example explaining what a method concretly does
>>>>>> may help a lot to understand OFBiz. It seems the link David sent about
>>>>>> UBML is about his.
>>>>>>
>>>>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>>>>> participate to the project at least by providing bug reports, I still
>>>>>> feel for away from providing patches ! :-)
>>>>>>
>>>>>> Hope this will help you, devs, the project is already great, let's
>>>>>> make it more accessible !
>>>>>>
>>>>>> Cimballi
>>>>>
>>>>
>>>>
>>>
>>
>
>
Re: Bugs and open Jira issues
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 7/12/2009, at 10:05 PM, Jacques Le Roux wrote:
> Please Scott,
>
> Inline...
>
> From: "Scott Gray" <sc...@hotwaxmedia.com>
>> I disagree, there always have been and always will be bugs in
>> OFBiz, there is no escaping this fact. The only reason there are
>> more bugs now than there were 3 years ago is because there is more
>> community activity. Fixing the bugs in jira will not prevent new
>> bugs from replacing them (and some of the replacements will be the
>> same bugs we just fixed).
>
> Don't misundersand me. I'm not worried about new bugs. I totally
> understand that this is intrinsic nature of software.
> My point is only for us to give more love to these 109 issues
> waiting attention in Jira, nothing else...
I'm saying it's pointless giving them any love without writing tests
for those bugs first. Every code change (even bug fixes) carries the
risk of introducing new bugs and the only thing we can do to reduce
that risk is to write tests. Without tests the number of bugs in jira
will never do anything but increase.
>> IMO the best thing we can do for the stability of the project is
>> to create tests every time we create or modify a service, be it
>> during a bug fix or while implementing new functionality. Doing
>> so locks in the desired behavior and prevents anyone from
>> unknowingly changing that behavior.
>
> Yes, I plenty agree
>
>> Even without intervention, bugs naturally get fixed over time as
>> people come to require the functionality being blocked by the bug,
>> the key is to do everything we can to reduce the number of new
>> bugs being created.
>
> I totally agree, I can agree more I should say. i think I should
> have used "Opened important Jira issues" as subject :/
>
> Jacques
> () ascii ribbon campaign against HTML e-mail
> /\ www.asciiribbon.org
>
>> Regards
>> Scott
>> HotWax Media
>> http://www.hotwaxmedia.com
>> On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
>>> Thi is all great,
>>>
>>> Put please ladies/gents don't get out of subject.
>>> I still think the 1st step is to fix the bugs we know exist, are
>>> documented in Jira and even ready to be fixed with patches for some.
>>>
>>> Jacques
>>> () ascii ribbon campaign against HTML e-mail
>>> /\ www.asciiribbon.org
>>>
>>>
>>> From: "Anil Patel" <an...@hotwaxmedia.com>
>>>> We do see some great Ideas around what is needed. There was lot
>>>> of conversation on this topic in ApacheCon 2008 and then in
>>>> 2009 (based on messages on list).
>>>>
>>>> You will be surprised there is lot done. We have seen lot of
>>>> activity in documenting business processes and end user
>>>> documentation.
>>>>
>>>> More recently David proposed a simple system derived from Ofbiz
>>>> that will address needs of small business.
>>>>
>>>> We have lot more Ofbiz technical contributors then Business
>>>> process knowledge contributors. It will be really nice if people
>>>> in this part of community will step up. It will be nice if
>>>> business users or power business users who are technical
>>>> developers as well started to take part of requirement documents
>>>> and add to UBPL or EZBIZ effort.
>>>>
>>>> If users can document their business processes needs, give some
>>>> wireframe help then technical developers will be able to help
>>>> map them to OOTB features (Gap Analysis).
>>>>
>>>> Unless we get real business requirements documents coming from
>>>> user community there is no way for us to fulfill them.
>>>>
>>>> I hope you understand I am not asking anybody to break NDA or
>>>> whatever.
>>>>
>>>> Thanks and Regards
>>>> Anil Patel
>>>> HotWax Media Inc
>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>>
>>>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>>>
>>>>> Hi devs,
>>>>>
>>>>> Here my opinion about the subject.
>>>>> To make things clear, it makes about 3-4 month I am working with
>>>>> OFBiz, using it to implement a project.
>>>>>
>>>>> I thing one way to have more people involved in the project is to
>>>>> lower the "difficulty level" required to understand OFBiz.
>>>>>
>>>>> And for this there are several possbilities, and I will focus
>>>>> on two :
>>>>> - modularize the project
>>>>> - more functional documentation inside the source files
>>>>>
>>>>> Modularize the project
>>>>>
>>>>> I've seen this subject has already been discussed and I think it
>>>>> can
>>>>> profit to the project in several points :
>>>>> - more modules means less code in each module, which means
>>>>> modules are
>>>>> eaiser to understand, which means more developer may be
>>>>> interesting to
>>>>> participate to its development, test, ... There is at least one
>>>>> obvious module which could be very interesting to externalize,
>>>>> it's
>>>>> the entity engine. I don't know so much OFBiz architecture but
>>>>> I think
>>>>> it should be possible to externalize this module and a lot of
>>>>> projects
>>>>> totally different of OFBiz could be interesting in it, and so
>>>>> potentially a lot more developers to maintain and enhance it.
>>>>> - on another side, more modules would also make it easier to
>>>>> distribute the issues, each developer specialized on a specific
>>>>> module. Maybe it's already the case...
>>>>>
>>>>> More functional documentation inside the source files
>>>>>
>>>>> Here my feeling is that with OFBiz, you really requires both
>>>>> technical
>>>>> and functional knowledge to understand how the project work.
>>>>> Some part
>>>>> like the entity engine are purely technical, but the order
>>>>> module for
>>>>> example is really functional, I mean, you need to know a lot
>>>>> about how
>>>>> ordering works in a company to be able to use the module and
>>>>> even more
>>>>> to custommize or propose enhancements to it. So, with more
>>>>> documentation in the source files, like the XML entity files,
>>>>> and then
>>>>> in the source code for example explaining what a method
>>>>> concretly does
>>>>> may help a lot to understand OFBiz. It seems the link David
>>>>> sent about
>>>>> UBML is about his.
>>>>>
>>>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>>>> participate to the project at least by providing bug reports, I
>>>>> still
>>>>> feel for away from providing patches ! :-)
>>>>>
>>>>> Hope this will help you, devs, the project is already great, let's
>>>>> make it more accessible !
>>>>>
>>>>> Cimballi
>>>>
>>>
>>>
>>
>
Re: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Please Scott,
Inline...
From: "Scott Gray" <sc...@hotwaxmedia.com>
>I disagree, there always have been and always will be bugs in OFBiz,
> there is no escaping this fact. The only reason there are more bugs
> now than there were 3 years ago is because there is more community
> activity. Fixing the bugs in jira will not prevent new bugs from
> replacing them (and some of the replacements will be the same bugs we
> just fixed).
Don't misundersand me. I'm not worried about new bugs. I totally understand that this is intrinsic nature of software.
My point is only for us to give more love to these 109 issues waiting attention in Jira, nothing else...
> IMO the best thing we can do for the stability of the project is to
> create tests every time we create or modify a service, be it during a
> bug fix or while implementing new functionality. Doing so locks in
> the desired behavior and prevents anyone from unknowingly changing
> that behavior.
Yes, I plenty agree
> Even without intervention, bugs naturally get fixed over time as
> people come to require the functionality being blocked by the bug, the
> key is to do everything we can to reduce the number of new bugs being
> created.
I totally agree, I can agree more I should say. i think I should have used "Opened important Jira issues" as subject :/
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
>
>> Thi is all great,
>>
>> Put please ladies/gents don't get out of subject.
>> I still think the 1st step is to fix the bugs we know exist, are
>> documented in Jira and even ready to be fixed with patches for some.
>>
>> Jacques
>> () ascii ribbon campaign against HTML e-mail
>> /\ www.asciiribbon.org
>>
>>
>> From: "Anil Patel" <an...@hotwaxmedia.com>
>>> We do see some great Ideas around what is needed. There was lot of
>>> conversation on this topic in ApacheCon 2008 and then in 2009
>>> (based on messages on list).
>>>
>>> You will be surprised there is lot done. We have seen lot of
>>> activity in documenting business processes and end user
>>> documentation.
>>>
>>> More recently David proposed a simple system derived from Ofbiz
>>> that will address needs of small business.
>>>
>>> We have lot more Ofbiz technical contributors then Business process
>>> knowledge contributors. It will be really nice if people in this
>>> part of community will step up. It will be nice if business users
>>> or power business users who are technical developers as well
>>> started to take part of requirement documents and add to UBPL or
>>> EZBIZ effort.
>>>
>>> If users can document their business processes needs, give some
>>> wireframe help then technical developers will be able to help map
>>> them to OOTB features (Gap Analysis).
>>>
>>> Unless we get real business requirements documents coming from user
>>> community there is no way for us to fulfill them.
>>>
>>> I hope you understand I am not asking anybody to break NDA or
>>> whatever.
>>>
>>> Thanks and Regards
>>> Anil Patel
>>> HotWax Media Inc
>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>>
>>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>>
>>>> Hi devs,
>>>>
>>>> Here my opinion about the subject.
>>>> To make things clear, it makes about 3-4 month I am working with
>>>> OFBiz, using it to implement a project.
>>>>
>>>> I thing one way to have more people involved in the project is to
>>>> lower the "difficulty level" required to understand OFBiz.
>>>>
>>>> And for this there are several possbilities, and I will focus on
>>>> two :
>>>> - modularize the project
>>>> - more functional documentation inside the source files
>>>>
>>>> Modularize the project
>>>>
>>>> I've seen this subject has already been discussed and I think it can
>>>> profit to the project in several points :
>>>> - more modules means less code in each module, which means modules
>>>> are
>>>> eaiser to understand, which means more developer may be
>>>> interesting to
>>>> participate to its development, test, ... There is at least one
>>>> obvious module which could be very interesting to externalize, it's
>>>> the entity engine. I don't know so much OFBiz architecture but I
>>>> think
>>>> it should be possible to externalize this module and a lot of
>>>> projects
>>>> totally different of OFBiz could be interesting in it, and so
>>>> potentially a lot more developers to maintain and enhance it.
>>>> - on another side, more modules would also make it easier to
>>>> distribute the issues, each developer specialized on a specific
>>>> module. Maybe it's already the case...
>>>>
>>>> More functional documentation inside the source files
>>>>
>>>> Here my feeling is that with OFBiz, you really requires both
>>>> technical
>>>> and functional knowledge to understand how the project work. Some
>>>> part
>>>> like the entity engine are purely technical, but the order module
>>>> for
>>>> example is really functional, I mean, you need to know a lot about
>>>> how
>>>> ordering works in a company to be able to use the module and even
>>>> more
>>>> to custommize or propose enhancements to it. So, with more
>>>> documentation in the source files, like the XML entity files, and
>>>> then
>>>> in the source code for example explaining what a method concretly
>>>> does
>>>> may help a lot to understand OFBiz. It seems the link David sent
>>>> about
>>>> UBML is about his.
>>>>
>>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>>> participate to the project at least by providing bug reports, I
>>>> still
>>>> feel for away from providing patches ! :-)
>>>>
>>>> Hope this will help you, devs, the project is already great, let's
>>>> make it more accessible !
>>>>
>>>> Cimballi
>>>
>>
>>
>
>
Re: Bugs and open Jira issues
Posted by Scott Gray <sc...@hotwaxmedia.com>.
I disagree, there always have been and always will be bugs in OFBiz,
there is no escaping this fact. The only reason there are more bugs
now than there were 3 years ago is because there is more community
activity. Fixing the bugs in jira will not prevent new bugs from
replacing them (and some of the replacements will be the same bugs we
just fixed).
IMO the best thing we can do for the stability of the project is to
create tests every time we create or modify a service, be it during a
bug fix or while implementing new functionality. Doing so locks in
the desired behavior and prevents anyone from unknowingly changing
that behavior.
Even without intervention, bugs naturally get fixed over time as
people come to require the functionality being blocked by the bug, the
key is to do everything we can to reduce the number of new bugs being
created.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote:
> Thi is all great,
>
> Put please ladies/gents don't get out of subject.
> I still think the 1st step is to fix the bugs we know exist, are
> documented in Jira and even ready to be fixed with patches for some.
>
> Jacques
> () ascii ribbon campaign against HTML e-mail
> /\ www.asciiribbon.org
>
>
> From: "Anil Patel" <an...@hotwaxmedia.com>
>> We do see some great Ideas around what is needed. There was lot of
>> conversation on this topic in ApacheCon 2008 and then in 2009
>> (based on messages on list).
>>
>> You will be surprised there is lot done. We have seen lot of
>> activity in documenting business processes and end user
>> documentation.
>>
>> More recently David proposed a simple system derived from Ofbiz
>> that will address needs of small business.
>>
>> We have lot more Ofbiz technical contributors then Business process
>> knowledge contributors. It will be really nice if people in this
>> part of community will step up. It will be nice if business users
>> or power business users who are technical developers as well
>> started to take part of requirement documents and add to UBPL or
>> EZBIZ effort.
>>
>> If users can document their business processes needs, give some
>> wireframe help then technical developers will be able to help map
>> them to OOTB features (Gap Analysis).
>>
>> Unless we get real business requirements documents coming from user
>> community there is no way for us to fulfill them.
>>
>> I hope you understand I am not asking anybody to break NDA or
>> whatever.
>>
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>
>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>
>>> Hi devs,
>>>
>>> Here my opinion about the subject.
>>> To make things clear, it makes about 3-4 month I am working with
>>> OFBiz, using it to implement a project.
>>>
>>> I thing one way to have more people involved in the project is to
>>> lower the "difficulty level" required to understand OFBiz.
>>>
>>> And for this there are several possbilities, and I will focus on
>>> two :
>>> - modularize the project
>>> - more functional documentation inside the source files
>>>
>>> Modularize the project
>>>
>>> I've seen this subject has already been discussed and I think it can
>>> profit to the project in several points :
>>> - more modules means less code in each module, which means modules
>>> are
>>> eaiser to understand, which means more developer may be
>>> interesting to
>>> participate to its development, test, ... There is at least one
>>> obvious module which could be very interesting to externalize, it's
>>> the entity engine. I don't know so much OFBiz architecture but I
>>> think
>>> it should be possible to externalize this module and a lot of
>>> projects
>>> totally different of OFBiz could be interesting in it, and so
>>> potentially a lot more developers to maintain and enhance it.
>>> - on another side, more modules would also make it easier to
>>> distribute the issues, each developer specialized on a specific
>>> module. Maybe it's already the case...
>>>
>>> More functional documentation inside the source files
>>>
>>> Here my feeling is that with OFBiz, you really requires both
>>> technical
>>> and functional knowledge to understand how the project work. Some
>>> part
>>> like the entity engine are purely technical, but the order module
>>> for
>>> example is really functional, I mean, you need to know a lot about
>>> how
>>> ordering works in a company to be able to use the module and even
>>> more
>>> to custommize or propose enhancements to it. So, with more
>>> documentation in the source files, like the XML entity files, and
>>> then
>>> in the source code for example explaining what a method concretly
>>> does
>>> may help a lot to understand OFBiz. It seems the link David sent
>>> about
>>> UBML is about his.
>>>
>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>> participate to the project at least by providing bug reports, I
>>> still
>>> feel for away from providing patches ! :-)
>>>
>>> Hope this will help you, devs, the project is already great, let's
>>> make it more accessible !
>>>
>>> Cimballi
>>
>
>
Re: Bugs and open Jira issues
Posted by Pierre Smits <pi...@gmail.com>.
Hans,
No worries.... We just differ sometimes in opinions. We both want to enhance
OfBiz to the best of our beliefs and abillities.
Regards,
Pierre
2009/12/7 Hans Bakker <ma...@antwebsystems.com>
> Hi Pierre,
>
> your involvement is more than welcome, remind me when i am a bit
> slow :-)
>
> Regards,
> Hans
>
>
> On Mon, 2009-12-07 at 10:36 +0100, Pierre Smits wrote:
> > Hi all,
> >
> > I have looked mainly into the SFA and Project Mgt components over the
> last
> > few months and am more than willing to help these components (for
> starters)
> > forward. Even in a greater role than just providing feedback.
> >
> > Regards, Pierre.
> >
> > 2009/12/7 Jacques Le Roux <ja...@les7arts.com>
> >
> > > Thi is all great,
> > >
> > > Put please ladies/gents don't get out of subject.
> > > I still think the 1st step is to fix the bugs we know exist, are
> documented
> > > in Jira and even ready to be fixed with patches for some.
> > >
> > >
> > > Jacques
> > > () ascii ribbon campaign against HTML e-mail
> > > /\ www.asciiribbon.org
> > >
> > >
> > > From: "Anil Patel" <an...@hotwaxmedia.com>
> > >
> > > We do see some great Ideas around what is needed. There was lot of
> > >> conversation on this topic in ApacheCon 2008 and then in 2009 (based
> on
> > >> messages on list).
> > >>
> > >> You will be surprised there is lot done. We have seen lot of activity
> in
> > >> documenting business processes and end user documentation.
> > >>
> > >> More recently David proposed a simple system derived from Ofbiz that
> will
> > >> address needs of small business.
> > >>
> > >> We have lot more Ofbiz technical contributors then Business process
> > >> knowledge contributors. It will be really nice if people in this part
> of
> > >> community will step up. It will be nice if business users or power
> business
> > >> users who are technical developers as well started to take part of
> > >> requirement documents and add to UBPL or EZBIZ effort.
> > >>
> > >> If users can document their business processes needs, give some
> wireframe
> > >> help then technical developers will be able to help map them to OOTB
> > >> features (Gap Analysis).
> > >>
> > >> Unless we get real business requirements documents coming from user
> > >> community there is no way for us to fulfill them.
> > >>
> > >> I hope you understand I am not asking anybody to break NDA or
> whatever.
> > >>
> > >> Thanks and Regards
> > >> Anil Patel
> > >> HotWax Media Inc
> > >> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
> > >>
> > >> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
> > >>
> > >> Hi devs,
> > >>>
> > >>> Here my opinion about the subject.
> > >>> To make things clear, it makes about 3-4 month I am working with
> > >>> OFBiz, using it to implement a project.
> > >>>
> > >>> I thing one way to have more people involved in the project is to
> > >>> lower the "difficulty level" required to understand OFBiz.
> > >>>
> > >>> And for this there are several possbilities, and I will focus on two
> :
> > >>> - modularize the project
> > >>> - more functional documentation inside the source files
> > >>>
> > >>> Modularize the project
> > >>>
> > >>> I've seen this subject has already been discussed and I think it can
> > >>> profit to the project in several points :
> > >>> - more modules means less code in each module, which means modules
> are
> > >>> eaiser to understand, which means more developer may be interesting
> to
> > >>> participate to its development, test, ... There is at least one
> > >>> obvious module which could be very interesting to externalize, it's
> > >>> the entity engine. I don't know so much OFBiz architecture but I
> think
> > >>> it should be possible to externalize this module and a lot of
> projects
> > >>> totally different of OFBiz could be interesting in it, and so
> > >>> potentially a lot more developers to maintain and enhance it.
> > >>> - on another side, more modules would also make it easier to
> > >>> distribute the issues, each developer specialized on a specific
> > >>> module. Maybe it's already the case...
> > >>>
> > >>> More functional documentation inside the source files
> > >>>
> > >>> Here my feeling is that with OFBiz, you really requires both
> technical
> > >>> and functional knowledge to understand how the project work. Some
> part
> > >>> like the entity engine are purely technical, but the order module for
> > >>> example is really functional, I mean, you need to know a lot about
> how
> > >>> ordering works in a company to be able to use the module and even
> more
> > >>> to custommize or propose enhancements to it. So, with more
> > >>> documentation in the source files, like the XML entity files, and
> then
> > >>> in the source code for example explaining what a method concretly
> does
> > >>> may help a lot to understand OFBiz. It seems the link David sent
> about
> > >>> UBML is about his.
> > >>>
> > >>> Here is my feeling about OFBiz as a fresh developers. I try to
> > >>> participate to the project at least by providing bug reports, I still
> > >>> feel for away from providing patches ! :-)
> > >>>
> > >>> Hope this will help you, devs, the project is already great, let's
> > >>> make it more accessible !
> > >>>
> > >>> Cimballi
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>
>
Re: Bugs and open Jira issues
Posted by Hans Bakker <ma...@antwebsystems.com>.
Hi Pierre,
your involvement is more than welcome, remind me when i am a bit
slow :-)
Regards,
Hans
On Mon, 2009-12-07 at 10:36 +0100, Pierre Smits wrote:
> Hi all,
>
> I have looked mainly into the SFA and Project Mgt components over the last
> few months and am more than willing to help these components (for starters)
> forward. Even in a greater role than just providing feedback.
>
> Regards, Pierre.
>
> 2009/12/7 Jacques Le Roux <ja...@les7arts.com>
>
> > Thi is all great,
> >
> > Put please ladies/gents don't get out of subject.
> > I still think the 1st step is to fix the bugs we know exist, are documented
> > in Jira and even ready to be fixed with patches for some.
> >
> >
> > Jacques
> > () ascii ribbon campaign against HTML e-mail
> > /\ www.asciiribbon.org
> >
> >
> > From: "Anil Patel" <an...@hotwaxmedia.com>
> >
> > We do see some great Ideas around what is needed. There was lot of
> >> conversation on this topic in ApacheCon 2008 and then in 2009 (based on
> >> messages on list).
> >>
> >> You will be surprised there is lot done. We have seen lot of activity in
> >> documenting business processes and end user documentation.
> >>
> >> More recently David proposed a simple system derived from Ofbiz that will
> >> address needs of small business.
> >>
> >> We have lot more Ofbiz technical contributors then Business process
> >> knowledge contributors. It will be really nice if people in this part of
> >> community will step up. It will be nice if business users or power business
> >> users who are technical developers as well started to take part of
> >> requirement documents and add to UBPL or EZBIZ effort.
> >>
> >> If users can document their business processes needs, give some wireframe
> >> help then technical developers will be able to help map them to OOTB
> >> features (Gap Analysis).
> >>
> >> Unless we get real business requirements documents coming from user
> >> community there is no way for us to fulfill them.
> >>
> >> I hope you understand I am not asking anybody to break NDA or whatever.
> >>
> >> Thanks and Regards
> >> Anil Patel
> >> HotWax Media Inc
> >> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
> >>
> >> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
> >>
> >> Hi devs,
> >>>
> >>> Here my opinion about the subject.
> >>> To make things clear, it makes about 3-4 month I am working with
> >>> OFBiz, using it to implement a project.
> >>>
> >>> I thing one way to have more people involved in the project is to
> >>> lower the "difficulty level" required to understand OFBiz.
> >>>
> >>> And for this there are several possbilities, and I will focus on two :
> >>> - modularize the project
> >>> - more functional documentation inside the source files
> >>>
> >>> Modularize the project
> >>>
> >>> I've seen this subject has already been discussed and I think it can
> >>> profit to the project in several points :
> >>> - more modules means less code in each module, which means modules are
> >>> eaiser to understand, which means more developer may be interesting to
> >>> participate to its development, test, ... There is at least one
> >>> obvious module which could be very interesting to externalize, it's
> >>> the entity engine. I don't know so much OFBiz architecture but I think
> >>> it should be possible to externalize this module and a lot of projects
> >>> totally different of OFBiz could be interesting in it, and so
> >>> potentially a lot more developers to maintain and enhance it.
> >>> - on another side, more modules would also make it easier to
> >>> distribute the issues, each developer specialized on a specific
> >>> module. Maybe it's already the case...
> >>>
> >>> More functional documentation inside the source files
> >>>
> >>> Here my feeling is that with OFBiz, you really requires both technical
> >>> and functional knowledge to understand how the project work. Some part
> >>> like the entity engine are purely technical, but the order module for
> >>> example is really functional, I mean, you need to know a lot about how
> >>> ordering works in a company to be able to use the module and even more
> >>> to custommize or propose enhancements to it. So, with more
> >>> documentation in the source files, like the XML entity files, and then
> >>> in the source code for example explaining what a method concretly does
> >>> may help a lot to understand OFBiz. It seems the link David sent about
> >>> UBML is about his.
> >>>
> >>> Here is my feeling about OFBiz as a fresh developers. I try to
> >>> participate to the project at least by providing bug reports, I still
> >>> feel for away from providing patches ! :-)
> >>>
> >>> Hope this will help you, devs, the project is already great, let's
> >>> make it more accessible !
> >>>
> >>> Cimballi
> >>>
> >>
> >>
> >>
> >
> >
--
Antwebsystems.com: Quality OFBiz services for competitive rates
Re: Bugs and open Jira issues
Posted by Pierre Smits <pi...@gmail.com>.
Hi all,
I have looked mainly into the SFA and Project Mgt components over the last
few months and am more than willing to help these components (for starters)
forward. Even in a greater role than just providing feedback.
Regards, Pierre.
2009/12/7 Jacques Le Roux <ja...@les7arts.com>
> Thi is all great,
>
> Put please ladies/gents don't get out of subject.
> I still think the 1st step is to fix the bugs we know exist, are documented
> in Jira and even ready to be fixed with patches for some.
>
>
> Jacques
> () ascii ribbon campaign against HTML e-mail
> /\ www.asciiribbon.org
>
>
> From: "Anil Patel" <an...@hotwaxmedia.com>
>
> We do see some great Ideas around what is needed. There was lot of
>> conversation on this topic in ApacheCon 2008 and then in 2009 (based on
>> messages on list).
>>
>> You will be surprised there is lot done. We have seen lot of activity in
>> documenting business processes and end user documentation.
>>
>> More recently David proposed a simple system derived from Ofbiz that will
>> address needs of small business.
>>
>> We have lot more Ofbiz technical contributors then Business process
>> knowledge contributors. It will be really nice if people in this part of
>> community will step up. It will be nice if business users or power business
>> users who are technical developers as well started to take part of
>> requirement documents and add to UBPL or EZBIZ effort.
>>
>> If users can document their business processes needs, give some wireframe
>> help then technical developers will be able to help map them to OOTB
>> features (Gap Analysis).
>>
>> Unless we get real business requirements documents coming from user
>> community there is no way for us to fulfill them.
>>
>> I hope you understand I am not asking anybody to break NDA or whatever.
>>
>> Thanks and Regards
>> Anil Patel
>> HotWax Media Inc
>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>>
>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>>
>> Hi devs,
>>>
>>> Here my opinion about the subject.
>>> To make things clear, it makes about 3-4 month I am working with
>>> OFBiz, using it to implement a project.
>>>
>>> I thing one way to have more people involved in the project is to
>>> lower the "difficulty level" required to understand OFBiz.
>>>
>>> And for this there are several possbilities, and I will focus on two :
>>> - modularize the project
>>> - more functional documentation inside the source files
>>>
>>> Modularize the project
>>>
>>> I've seen this subject has already been discussed and I think it can
>>> profit to the project in several points :
>>> - more modules means less code in each module, which means modules are
>>> eaiser to understand, which means more developer may be interesting to
>>> participate to its development, test, ... There is at least one
>>> obvious module which could be very interesting to externalize, it's
>>> the entity engine. I don't know so much OFBiz architecture but I think
>>> it should be possible to externalize this module and a lot of projects
>>> totally different of OFBiz could be interesting in it, and so
>>> potentially a lot more developers to maintain and enhance it.
>>> - on another side, more modules would also make it easier to
>>> distribute the issues, each developer specialized on a specific
>>> module. Maybe it's already the case...
>>>
>>> More functional documentation inside the source files
>>>
>>> Here my feeling is that with OFBiz, you really requires both technical
>>> and functional knowledge to understand how the project work. Some part
>>> like the entity engine are purely technical, but the order module for
>>> example is really functional, I mean, you need to know a lot about how
>>> ordering works in a company to be able to use the module and even more
>>> to custommize or propose enhancements to it. So, with more
>>> documentation in the source files, like the XML entity files, and then
>>> in the source code for example explaining what a method concretly does
>>> may help a lot to understand OFBiz. It seems the link David sent about
>>> UBML is about his.
>>>
>>> Here is my feeling about OFBiz as a fresh developers. I try to
>>> participate to the project at least by providing bug reports, I still
>>> feel for away from providing patches ! :-)
>>>
>>> Hope this will help you, devs, the project is already great, let's
>>> make it more accessible !
>>>
>>> Cimballi
>>>
>>
>>
>>
>
>
Re: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thi is all great,
Put please ladies/gents don't get out of subject.
I still think the 1st step is to fix the bugs we know exist, are documented in Jira and even ready to be fixed with patches for
some.
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
From: "Anil Patel" <an...@hotwaxmedia.com>
> We do see some great Ideas around what is needed. There was lot of conversation on this topic in ApacheCon 2008 and then in 2009
> (based on messages on list).
>
> You will be surprised there is lot done. We have seen lot of activity in documenting business processes and end user
> documentation.
>
> More recently David proposed a simple system derived from Ofbiz that will address needs of small business.
>
> We have lot more Ofbiz technical contributors then Business process knowledge contributors. It will be really nice if people in
> this part of community will step up. It will be nice if business users or power business users who are technical developers as
> well started to take part of requirement documents and add to UBPL or EZBIZ effort.
>
> If users can document their business processes needs, give some wireframe help then technical developers will be able to help map
> them to OOTB features (Gap Analysis).
>
> Unless we get real business requirements documents coming from user community there is no way for us to fulfill them.
>
> I hope you understand I am not asking anybody to break NDA or whatever.
>
> Thanks and Regards
> Anil Patel
> HotWax Media Inc
> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
>
> On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
>
>> Hi devs,
>>
>> Here my opinion about the subject.
>> To make things clear, it makes about 3-4 month I am working with
>> OFBiz, using it to implement a project.
>>
>> I thing one way to have more people involved in the project is to
>> lower the "difficulty level" required to understand OFBiz.
>>
>> And for this there are several possbilities, and I will focus on two :
>> - modularize the project
>> - more functional documentation inside the source files
>>
>> Modularize the project
>>
>> I've seen this subject has already been discussed and I think it can
>> profit to the project in several points :
>> - more modules means less code in each module, which means modules are
>> eaiser to understand, which means more developer may be interesting to
>> participate to its development, test, ... There is at least one
>> obvious module which could be very interesting to externalize, it's
>> the entity engine. I don't know so much OFBiz architecture but I think
>> it should be possible to externalize this module and a lot of projects
>> totally different of OFBiz could be interesting in it, and so
>> potentially a lot more developers to maintain and enhance it.
>> - on another side, more modules would also make it easier to
>> distribute the issues, each developer specialized on a specific
>> module. Maybe it's already the case...
>>
>> More functional documentation inside the source files
>>
>> Here my feeling is that with OFBiz, you really requires both technical
>> and functional knowledge to understand how the project work. Some part
>> like the entity engine are purely technical, but the order module for
>> example is really functional, I mean, you need to know a lot about how
>> ordering works in a company to be able to use the module and even more
>> to custommize or propose enhancements to it. So, with more
>> documentation in the source files, like the XML entity files, and then
>> in the source code for example explaining what a method concretly does
>> may help a lot to understand OFBiz. It seems the link David sent about
>> UBML is about his.
>>
>> Here is my feeling about OFBiz as a fresh developers. I try to
>> participate to the project at least by providing bug reports, I still
>> feel for away from providing patches ! :-)
>>
>> Hope this will help you, devs, the project is already great, let's
>> make it more accessible !
>>
>> Cimballi
>
>
Re: Bugs and open Jira issues
Posted by Anil Patel <an...@hotwaxmedia.com>.
We do see some great Ideas around what is needed. There was lot of conversation on this topic in ApacheCon 2008 and then in 2009 (based on messages on list).
You will be surprised there is lot done. We have seen lot of activity in documenting business processes and end user documentation.
More recently David proposed a simple system derived from Ofbiz that will address needs of small business.
We have lot more Ofbiz technical contributors then Business process knowledge contributors. It will be really nice if people in this part of community will step up. It will be nice if business users or power business users who are technical developers as well started to take part of requirement documents and add to UBPL or EZBIZ effort.
If users can document their business processes needs, give some wireframe help then technical developers will be able to help map them to OOTB features (Gap Analysis).
Unless we get real business requirements documents coming from user community there is no way for us to fulfill them.
I hope you understand I am not asking anybody to break NDA or whatever.
Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
On Dec 6, 2009, at 8:22 PM, Cimballi wrote:
> Hi devs,
>
> Here my opinion about the subject.
> To make things clear, it makes about 3-4 month I am working with
> OFBiz, using it to implement a project.
>
> I thing one way to have more people involved in the project is to
> lower the "difficulty level" required to understand OFBiz.
>
> And for this there are several possbilities, and I will focus on two :
> - modularize the project
> - more functional documentation inside the source files
>
> Modularize the project
>
> I've seen this subject has already been discussed and I think it can
> profit to the project in several points :
> - more modules means less code in each module, which means modules are
> eaiser to understand, which means more developer may be interesting to
> participate to its development, test, ... There is at least one
> obvious module which could be very interesting to externalize, it's
> the entity engine. I don't know so much OFBiz architecture but I think
> it should be possible to externalize this module and a lot of projects
> totally different of OFBiz could be interesting in it, and so
> potentially a lot more developers to maintain and enhance it.
> - on another side, more modules would also make it easier to
> distribute the issues, each developer specialized on a specific
> module. Maybe it's already the case...
>
> More functional documentation inside the source files
>
> Here my feeling is that with OFBiz, you really requires both technical
> and functional knowledge to understand how the project work. Some part
> like the entity engine are purely technical, but the order module for
> example is really functional, I mean, you need to know a lot about how
> ordering works in a company to be able to use the module and even more
> to custommize or propose enhancements to it. So, with more
> documentation in the source files, like the XML entity files, and then
> in the source code for example explaining what a method concretly does
> may help a lot to understand OFBiz. It seems the link David sent about
> UBML is about his.
>
> Here is my feeling about OFBiz as a fresh developers. I try to
> participate to the project at least by providing bug reports, I still
> feel for away from providing patches ! :-)
>
> Hope this will help you, devs, the project is already great, let's
> make it more accessible !
>
> Cimballi
Re: Bugs and open Jira issues
Posted by Cimballi <ci...@gmail.com>.
Hi devs,
Here my opinion about the subject.
To make things clear, it makes about 3-4 month I am working with
OFBiz, using it to implement a project.
I thing one way to have more people involved in the project is to
lower the "difficulty level" required to understand OFBiz.
And for this there are several possbilities, and I will focus on two :
- modularize the project
- more functional documentation inside the source files
Modularize the project
I've seen this subject has already been discussed and I think it can
profit to the project in several points :
- more modules means less code in each module, which means modules are
eaiser to understand, which means more developer may be interesting to
participate to its development, test, ... There is at least one
obvious module which could be very interesting to externalize, it's
the entity engine. I don't know so much OFBiz architecture but I think
it should be possible to externalize this module and a lot of projects
totally different of OFBiz could be interesting in it, and so
potentially a lot more developers to maintain and enhance it.
- on another side, more modules would also make it easier to
distribute the issues, each developer specialized on a specific
module. Maybe it's already the case...
More functional documentation inside the source files
Here my feeling is that with OFBiz, you really requires both technical
and functional knowledge to understand how the project work. Some part
like the entity engine are purely technical, but the order module for
example is really functional, I mean, you need to know a lot about how
ordering works in a company to be able to use the module and even more
to custommize or propose enhancements to it. So, with more
documentation in the source files, like the XML entity files, and then
in the source code for example explaining what a method concretly does
may help a lot to understand OFBiz. It seems the link David sent about
UBML is about his.
Here is my feeling about OFBiz as a fresh developers. I try to
participate to the project at least by providing bug reports, I still
feel for away from providing patches ! :-)
Hope this will help you, devs, the project is already great, let's
make it more accessible !
Cimballi
Re: Bugs and open Jira issues
Posted by David E Jones <de...@me.com>.
On Dec 6, 2009, at 5:57 PM, Ruth Hoffman wrote:
> You, David, have the power to give developer's commit access to the source code repository. You, David, can take it away. Or am I wrong about that? Who, BTW, gave all these people commit access to the source code repository initially?
That is not correct, I don't have the power to give commit access or to take it away. For more information, please see:
http://www.apache.org/foundation/how-it-works.html#structure
and
http://www.apache.org/foundation/how-it-works.html#meritocracy
and
http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+PMC+Members+and+Committers
Anyone can take on the role of "QA Manager", but chances are no one will ever be paid to do so. Yes, it's true that the PMC can vote to revoke commit privileges, but that is the only "force" available. And, if we went around removing a bunch of commit privileges do you really think that would get people to start testing better and doing analysis and design in a coordinated way before implementing so that they even know what to test? My guess is mostly that answer is no. People would get offended and simply stop contributing. In other words, trying force people to do something by not allowing them to do things is simply not very effective. You won't get more out of people, you'll get less.
Things are not done here by force, but by influence. This is a volunteer organization driven from the edge, not some sort of centralized managed and controlled organization.
Since there is no one around with power to force people to do things the best option is influence. For people committing stuff that breaks things, that means using peer pressure. Fortunately in recent months there has been a LOT more peer review and feedback among the committers (and in some rare cases other people, though there is nothing stopping anyone from doing so), and that should lead to significantly better code and commits over time.
Up until earlier this year I personally reviewed basically every commit, but I don't do that any more and only review a fraction of all commits. Fortunately, and perhaps partly because of that, others are stepping up and doing an excellent job of sharing that load, and I'm really happy about that. In spite of conflicts, mistakes, and people venting publicly now and again the community behind OFBiz is really coming together, and really acting as a community.
-David
Re: Bugs and open Jira issues
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi David:
I wasn't going to say anything about this, but my most recent experience
with the nightly trunk download has me fuming again...Just because an
organization is made up of volunteers, doesn't mean there is no need for
rules, respect for others and most importantly leadership.
Here's how I would start to "fix things". I'd say: No more commits until
the community gets the one or more processes in place necessary to
coordinate testing, builds and releases. Anyone who violates the rule,
looses the right to commit. When all the processes are in place and
agreed upon, then you can give all the violators back the right to commit.
You, David, have the power to give developer's commit access to the
source code repository. You, David, can take it away. Or am I wrong
about that? Who, BTW, gave all these people commit access to the source
code repository initially?
Regards,
Ruth
David E Jones wrote:
> To be clear, I'd like to hear from other people too. If anyone has any ideas about how we can get people to do this, by all means let's discuss it!
>
> This need and concern has come up in many places many times over the years of the project. I have some thoughts on good ways to go about this (like the UBPL stuff, automated testing which is going on now, etc, etc), but how to get people to do things, especially in a volunteer organization like this, is another question...
>
> -David
>
>
> On Dec 6, 2009, at 12:29 PM, Jacques Le Roux wrote:
>
>
>> Hi David,
>>
>> I have no answers yet, I must says I have not even thought about it...
>> For the moment I only propose to concentrate on existing known bugs repertoried in opened Jira issues.
>>
>> Thanks
>>
>> Jacques
>> () ascii ribbon campaign against HTML e-mail
>> /\ www.asciiribbon.org
>>
>>
>> ----- Original Message ----- From: "David E Jones" <de...@me.com>
>> To: <de...@ofbiz.apache.org>
>> Sent: Sunday, December 06, 2009 6:36 PM
>> Subject: Re: Bugs and open Jira issues
>>
>>
>>
>>> Jacques,
>>>
>>> I appreciate this feeling. In general OFBiz would benefit a lot from more testing, more definition of what to test against (ie what does a pass or fail look like, ie what is the design to test against), and in general more care about respecting others by not breaking things that already exist.
>>>
>>> The questions is, how do we get people to do this?
>>>
>>> -David
>>>
>>>
>>> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>>
>>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>>
>>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>>
>>
>
>
>
Re: Bugs and open Jira issues
Posted by David E Jones <de...@me.com>.
To be clear, I'd like to hear from other people too. If anyone has any ideas about how we can get people to do this, by all means let's discuss it!
This need and concern has come up in many places many times over the years of the project. I have some thoughts on good ways to go about this (like the UBPL stuff, automated testing which is going on now, etc, etc), but how to get people to do things, especially in a volunteer organization like this, is another question...
-David
On Dec 6, 2009, at 12:29 PM, Jacques Le Roux wrote:
> Hi David,
>
> I have no answers yet, I must says I have not even thought about it...
> For the moment I only propose to concentrate on existing known bugs repertoried in opened Jira issues.
>
> Thanks
>
> Jacques
> () ascii ribbon campaign against HTML e-mail
> /\ www.asciiribbon.org
>
>
> ----- Original Message ----- From: "David E Jones" <de...@me.com>
> To: <de...@ofbiz.apache.org>
> Sent: Sunday, December 06, 2009 6:36 PM
> Subject: Re: Bugs and open Jira issues
>
>
>>
>> Jacques,
>>
>> I appreciate this feeling. In general OFBiz would benefit a lot from more testing, more definition of what to test against (ie what does a pass or fail look like, ie what is the design to test against), and in general more care about respecting others by not breaking things that already exist.
>>
>> The questions is, how do we get people to do this?
>>
>> -David
>>
>>
>> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux wrote:
>>
>>> Hi,
>>>
>>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>>>
>>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>>
>>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>
>
>
Re: Bugs and open Jira issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi David,
I have no answers yet, I must says I have not even thought about it...
For the moment I only propose to concentrate on existing known bugs repertoried in opened Jira issues.
Thanks
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
----- Original Message -----
From: "David E Jones" <de...@me.com>
To: <de...@ofbiz.apache.org>
Sent: Sunday, December 06, 2009 6:36 PM
Subject: Re: Bugs and open Jira issues
>
> Jacques,
>
> I appreciate this feeling. In general OFBiz would benefit a lot from more testing, more definition of what to test against (ie
> what does a pass or fail look like, ie what is the design to test against), and in general more care about respecting others by
> not breaking things that already exist.
>
> The questions is, how do we get people to do this?
>
> -David
>
>
> On Dec 5, 2009, at 1:51 PM, Jacques Le Roux wrote:
>
>> Hi,
>>
>> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed
>> recently.
>>
>> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
>> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new
>> features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>>
>> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most
>> important ones (109 are considered as at least important) ?
>>
>> Thanks
>>
>> Jacques
>>
>>
>>
>
Re: Bugs and open Jira issues
Posted by David E Jones <de...@me.com>.
Jacques,
I appreciate this feeling. In general OFBiz would benefit a lot from more testing, more definition of what to test against (ie what does a pass or fail look like, ie what is the design to test against), and in general more care about respecting others by not breaking things that already exist.
The questions is, how do we get people to do this?
-David
On Dec 5, 2009, at 1:51 PM, Jacques Le Roux wrote:
> Hi,
>
> I'd like to express a feeling I have. Actually it's not only my own feeling but also something some users have expressed recently.
>
> I'm quite happy to see that these last times a lot of effort have been made in order to fix OFBiz (yes to fix OFBiz!)
> It's really great to see new features in OFBiz. But I really wonder if we should not slow down the pace in integrating new features for a short period of time and should not make and even greatest effort to have a more stable OFBiz.
>
> There are 180 bugs opened in Jira. Don't you think it's time for the community to have a look at them and to fix the most important ones (109 are considered as at least important) ?
>
> Thanks
>
> Jacques
>
>
>