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" <jvander...@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 <rhoff...@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.hoff...@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 <rhoff...@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.hoff...@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
>>>>>>>>>>> <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
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to