Rethinking our release strategy
Locked
123
123
Re: Rethinking our release strategy
 
|
Hi Anil,
Thanks for the info. I see that opentaps have built their business around providing professional ofbiz based releases. 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > |
Re: Rethinking our release strategy
|
|
In reply to this post by Jacopo Cappellato-4
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" <[hidden email]> >> Moreover it derives from Ingres which begins in 1977... >> >> Jacques >> >> From: "BJ Freeman" <[hidden email]> >>> 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" >>>> [hidden email] >>>> >>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> >>> > > |
Re: Rethinking our release strategy
|
|
In reply to this post by Chris Snow-3
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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> >> > |
Re: Rethinking our release strategy
|
|
In reply to this post by Ruth Hoffman-2
Maybe Adempiere is a more comparable to ofbiz in the opensource
community. Adempiere community has nice features: migration - http://www.adempiere.com/index.php/Migration who's doing what - http://www.adempiere.com/index.php/Feature_Development_Collaboration The main difference with Adempiere IMHO is that the community seems to have leadership. Maybe that was lost when ofbiz moved to ASF? Ruth Hoffman wrote: > 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" > [hidden email] > > 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >> >> >> |
Re: Rethinking our release strategy
|
|
On Feb 17, 2010, at 11:47 AM, Christopher Snow wrote: > Maybe Adempiere is a more comparable to ofbiz in the opensource community. Adempiere community has nice features: > > migration - http://www.adempiere.com/index.php/Migration > who's doing what - http://www.adempiere.com/index.php/Feature_Development_Collaboration > > The main difference with Adempiere IMHO is that the community seems to have leadership. Maybe that was lost when ofbiz moved to ASF? > No. Christopher, I think that you still miss the important point: given the current nature of the community we - and with "we" I mean the members of the community - can define rules (and in fact we have plenty of them) but the only goal we can hope to achieve with them is to prevent people from doing something that is bad for the project. We will never be able to oblige someone to work on something they don't want to do... Of course this is quite different if you have employees: I can ask to my employees to work for what I think is good, and they have to if they want to be paid. But in the community we have only people that voluntarily offer their work. Our rules simply tend to protect the project from bad contributions, but we cannot decide on what the committers have to work; we can simply suggest this (and we are doing this) but there is no guarantee that this will happen. Do you agree on this point? Also, our rules must be properly balanced: if they are too light the project will be a mess, if they are too tight we will not get new contribution. For example: if we would impose a rule (let's say that we ask to sign an agreement) that says that, if a committer want to freely contribute his work (an enhancement, new feature, a bug fix etc...) he has to: 1) provide written documentation in English 2) assure that the feature will be maintained over the releases of the next 2 years 3) provide support or bug fixes if bugs are discovered I am sure that no one will ever contribute something, someone will check out our code and create another open source project with more realistic rules. Kind regards, Jacopo > > Ruth Hoffman wrote: >> 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" >> [hidden email] >> >> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >>> >>> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |