David corrected me once and gave an overview of the beginning. I will search my emails to see if I can find it. it would be a good start.
Jacques Le Roux sent the following on 2/17/2010 2:28 AM: > BTW, It's a moment now that I want to write an history for OFBiz. Never > found the time yet :/ > Of course I'd need some help as I was interested by OFBiz only starting > in Sept. 2004 and not really involved before February 2005 > > Jacques > > From: "Jacques Le Roux" <[email protected]> >> Moreover it derives from Ingres which begins in 1977... >> >> Jacques >> >> From: "BJ Freeman" <[email protected]> >>> http://www.postgresql.org/about/history >>> you will notice is did not start as open source. >>> 1996 is when i started with it. >>> >>> here is an excerpt that ofbiz has yet to achieve. >>> >>> In 1996, Postgres95 departed from academia and started a new life in the >>> open source world when a group of dedicated developers outside of >>> Berkeley saw the promise of the system, and devoted themselves to its >>> continued development. Contributing enormous amounts of time, skill, >>> labor, and technical expertise, this global development group radically >>> transformed Postgres. Over the next eight years, they brought >>> consistency and uniformity to the code base, created detailed regression >>> tests for quality assurance, set up mailing lists for bug reports, fixed >>> innumerable bugs, added incredible new features, and rounded out the >>> system by filling various gaps such as documentation for developers and >>> users. >>> >>> ofbiz is just about 8+ yrs old. so by the time it is as old as >>> Postgresql from its inception I exspect it will be like Postgresql. >>> >>> >>> Ruth Hoffman sent the following on 2/16/2010 3:05 PM: >>>> Hi Anil: >>>> No disrespect intended to anyone on this list, but how is it I wonder >>>> that PostgreSQL is able to manage releases so well? Last I looked they >>>> are still totally community driven and you will find PostgreSQL >>>> installed in some pretty "high" places. >>>> >>>> Just wondering out loud. >>>> >>>> Regards, >>>> Ruth >>>> ---------------------------------------------------- >>>> Find me on the web at http://www.myofbiz.com or Google keyword >>>> "myofbiz" >>>> [email protected] >>>> >>>> Anil Patel wrote: >>>>> Chris, >>>>> Thanks for listing important tasks for managing product release. In >>>>> ofbiz community little less has been done on this front, I wish we >>>>> could be better. >>>>> >>>>> Very fundamental difference between professional open source projects >>>>> like you mentioned and Ofbiz is that, Ofbiz is community managed and >>>>> developed project. If you search mailing list archive, you can find >>>>> some good discussions on this topic. >>>>> Some people may consider it (that we don't get these professionally >>>>> managed releases) as drawback of Ofbiz, while others may see >>>>> opportunity. Somebody can build business around delivering services >>>>> like you mentioned. We still have huge untapped market. >>>>> >>>>> Thanks and Regards >>>>> Anil Patel >>>>> HotWax Media Inc >>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>>>> >>>>> On Feb 16, 2010, at 1:28 PM, Christopher Snow wrote: >>>>> >>>>> >>>>>> Hi Anil, >>>>>> >>>>>> Most of the stuff on this document appears to happen, so the question >>>>>> is do we need to be doing more? For example, there appears to be >>>>>> just two roles on this project, committers and contributors. Who is >>>>>> responsible for the following areas for each release: >>>>>> >>>>>> - migration from old to new releases >>>>>> - patch management >>>>>> - dependency management >>>>>> - quality management >>>>>> - documentation >>>>>> - etc.. >>>>>> >>>>>> I expect there would be many people who are not contributors who >>>>>> would be willing to head up some of the above areas (including >>>>>> myself). >>>>>> >>>>>> The more I think about it, the above areas are where others products >>>>>> are much better (adempiere, openerp, openbravo). They appear to have >>>>>> a much stronger release management process. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Chris >>>>>> >>>>>> Anil Patel wrote: >>>>>> >>>>>>> I know we used to have a release management document on old >>>>>>> confluence. Its matter of locating it. >>>>>>> >>>>>>> I request, Please don't draw conclusions so quickly. Thanks and >>>>>>> Regards >>>>>>> Anil Patel >>>>>>> HotWax Media Inc >>>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>>>>>> >>>>>>> On Feb 16, 2010, at 8:40 AM, Ruth Hoffman wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> It is ironic. >>>>>>>> Ruth >>>>>>>> >>>>>>>> Christopher Snow wrote: >>>>>>>> >>>>>>>>> It's kind of funny that ofbiz promotes the use of best practice in >>>>>>>>> many areas >>>>>>>>> (http://cwiki.apache.org/confluence/dosearchsite.action?queryString=ofbiz%20best%20practice) >>>>>>>>> >>>>>>>>> EXCEPT release management. >>>>>>>>> >>>>>>>>> Ruth Hoffman wrote: >>>>>>>>> >>>>>>>>>> Hi Jacopo: >>>>>>>>>> Its nice to see this kind of thought going into a release >>>>>>>>>> strategy. Thanks for the effort. Please see my comments inline. >>>>>>>>>> Note, this is just my opinion based on years of working with big >>>>>>>>>> complex IT organizations. These are the kind of "users" who >>>>>>>>>> ultimately would be implementing OFBiz (I hope...): >>>>>>>>>> >>>>>>>>>> Jacopo Cappellato wrote: >>>>>>>>>> >>>>>>>>>>> I know this subject has been already discussed several times in >>>>>>>>>>> the past, but I still would like to rethink our strategy for >>>>>>>>>>> releases in OFBiz. >>>>>>>>>>> I am under the impression that, considering the release branch >>>>>>>>>>> 9.04, that is our latest release branch: >>>>>>>>>>> * there are more users than maintainers >>>>>>>>>>> >>>>>>>>>> This is probably true. But to get a better understanding of who >>>>>>>>>> is using what, maybe we could look into getting download >>>>>>>>>> statistics? I have already put in a request to the infrastructure >>>>>>>>>> team for this, but have not heard anything back from them. Maybe >>>>>>>>>> a project committer has more clout and could get this >>>>>>>>>> implemented? Without that, we are just speculating about who is >>>>>>>>>> doing what with the code. >>>>>>>>>> >>>>>>>>>>> * because of this, no real maintenance plan, test strategy etc.. >>>>>>>>>>> has been created around it from the community of users and >>>>>>>>>>> interested parties (in fact we were not really able to >>>>>>>>>>> officially release it) >>>>>>>>>>> * a lot of new users start eveluating OFBiz from that instead of >>>>>>>>>>> the trunk >>>>>>>>>>> * it is rather old, several new features are missing and also >>>>>>>>>>> code improvements (that could fix bugs etc) >>>>>>>>>>> >>>>>>>>>> I thought all the bug fixes were retrofitted to the release? Is >>>>>>>>>> this not true? >>>>>>>>>> >>>>>>>>>>> * because of this, it tends to be less stable than the trunk >>>>>>>>>>> >>>>>>>>>> How could the release be less stable than the trunk if bug fixes >>>>>>>>>> are applied to the release and the trunk? >>>>>>>>>> >>>>>>>>>>> The main cons of this situations are the following: >>>>>>>>>>> 1) not real interest in maintaining a release branch means that >>>>>>>>>>> we will not be able to spend time on it and officially release >>>>>>>>>>> it: the OFBiz community will miss the advantage of using the >>>>>>>>>>> marketing channel represented by a new release >>>>>>>>>>> 2) new users will get the wrong impression that the project is >>>>>>>>>>> slowing improving if they just get the releases >>>>>>>>>>> >>>>>>>>>> Project committers should consider this behavior pattern: Most >>>>>>>>>> people evaluating code will not want the latest release. They >>>>>>>>>> will patiently wait until someone else has taken on the risk (and >>>>>>>>>> reward) of debugging it. Do not think that just because the >>>>>>>>>> project releases a new release of OFBiz, that everyone will >>>>>>>>>> stampede to get it. Far from it. Now if we had download >>>>>>>>>> statistics we could verify my claim, but I'd be willing to bet >>>>>>>>>> real money, that the only people who will jump to download this >>>>>>>>>> new release will be project committers. >>>>>>>>>> >>>>>>>>>>> 3) it is much easier for a user to stay up to date with the >>>>>>>>>>> trunk rather than with a release: I mean that there is no >>>>>>>>>>> guarantee that one day someone will build an upgrade plan from >>>>>>>>>>> the old release to the new one... users of the old release may >>>>>>>>>>> be left behind forever >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I think you mistake "user" with "committer". What "user" is >>>>>>>>>> actively trying to stay current with the trunk? Just some food >>>>>>>>>> for thought. >>>>>>>>>> >>>>>>>>>>> What I suggest is based on the following assumptions: >>>>>>>>>>> 1) community is not ready or interested in maintaining releases >>>>>>>>>>> >>>>>>>>>> Only the "committers" are not interested. Users out there may >>>>>>>>>> have a different story to tell. Personally, I'd like to see >>>>>>>>>> releases "maintained". >>>>>>>>>> >>>>>>>>>>> 2) new users prefer to start evaluating OFBiz with a release >>>>>>>>>>> instead of the trunk >>>>>>>>>>> 3) it is good for the project to announce new releases often >>>>>>>>>>> >>>>>>>>>> True. Very true. >>>>>>>>>> >>>>>>>>>>> 4) because our current policies (slowly increasing number of >>>>>>>>>>> committers, peer reviews, etc...) our trunk is (and will be) >>>>>>>>>>> more stable than older releases >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Again, why? I thought bug fixes are committed back to a release >>>>>>>>>> if appropriate. Is this not the case? >>>>>>>>>> >>>>>>>>>>> Here is what I suggest: >>>>>>>>>>> A) define an official release plan that says that we officially >>>>>>>>>>> issue a release every approx 6 months (just to give you an >>>>>>>>>>> idea): since there is no way to define a set of features that >>>>>>>>>>> will go in the next release, our releases will be based on dates >>>>>>>>>>> instead of features; but of course we can discuss the exact time >>>>>>>>>>> of a release based on what is going on 1-2 weeks before the >>>>>>>>>>> release date >>>>>>>>>>> >>>>>>>>>> Don't release every 6 months. That's crazy. Once a year is >>>>>>>>>> sufficient. Put in place a real release plan including features, >>>>>>>>>> fixes and upgrade instructions in advance and then work towards >>>>>>>>>> making OFBiz something more than just a developer's playground. >>>>>>>>>> Make it "stable" by setting out in advance what "stable" means. >>>>>>>>>> And then work towards making each release meet the "stability" >>>>>>>>>> requirements. Just releasing something every 6 months or a year >>>>>>>>>> does not a "stable" release make. >>>>>>>>>> >>>>>>>>>>> B) there is no guarantee that patches will be backported to >>>>>>>>>>> releases, that upgrade scripts will be created from release to >>>>>>>>>>> release >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> If so, then what is the point of even having releases? Just have >>>>>>>>>> nightly trunk builds and everyone is happy. >>>>>>>>>> >>>>>>>>>>> It is true that the ASF policies ask that a release, that >>>>>>>>>>> represents the code that is distributed by the ASF to the larger >>>>>>>>>>> audience of users, is a "stable" deliverable; but if we continue >>>>>>>>>>> with the current approach, even if it is intended to get a >>>>>>>>>>> stable and maintained release, what we are really doing is >>>>>>>>>>> distributing the code in the trunk (this is what we suggest our >>>>>>>>>>> users to use instead of the release), not the "stable" release. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> IMHO, one of the true benefits of going with the ASF is the >>>>>>>>>> structure and stability they enforce on umbrella projects. Why >>>>>>>>>> not use these "restrictions" to the project's advantage instead >>>>>>>>>> of trying to circumvent them. I think I'm agreeing with you in >>>>>>>>>> that maybe "we" should start pointing users to releases instead >>>>>>>>>> of trunk code. Just a thought. >>>>>>>>>> >>>>>>>>>> Ruth >>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> >>> > >
