On Feb 17, 2010, at 11:35 AM, Christopher Snow wrote: > Hi Anil, > > Thanks for the info. I see that opentaps have built their business around > providing professional ofbiz based releases.
Well, it is more accurate to say that the company OpenSourceStrategies has built its business around the product Opentaps (derived from OFBiz). Jacopo > > Cheers, > > Chris > > 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> >> >
