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.hoff...@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" <d...@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 >>>>>>>>>>> <jacques.le.r...@les7arts.com> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I'd like to express a feeling I have. Actually it's not only my >>>>>>>>>>>> own feeling but also something some users have expressed recently. >>>>>>>>>>>> >>>>>>>>>>>> I'm quite happy to see that these last times a lot of effort have >>>>>>>>>>>> been made in order to fix OFBiz (yes to fix OFBiz!) >>>>>>>>>>>> It's really great to see new features in OFBiz. But I really >>>>>>>>>>>> wonder if we should not slow down the pace in integrating new >>>>>>>>>>>> features for a short period of time and should not make and even >>>>>>>>>>>> greatest effort to have a more stable OFBiz. >>>>>>>>>>>> >>>>>>>>>>>> There are 180 bugs opened in Jira. Don't you think it's time for >>>>>>>>>>>> the community to have a look at them and to fix the most important >>>>>>>>>>>> ones (109 are considered as at least important) ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>>>> >>> >> >>
