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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>> >>>> >>>> > >
smime.p7s
Description: S/MIME cryptographic signature
