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" <[email protected]> >>> 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 >>>>>>>>>> <[email protected]> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>> >>>>> >>>>> >> >> >
