You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2010/02/15 11:49:30 UTC
Rethinking our release strategy
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
* 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)
* because of this, it tends to be less stable than 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
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
What I suggest is based on the following assumptions:
1) community is not ready or interested in maintaining releases
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
4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
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
B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
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.
What do you think?
Jacopo
Re: Rethinking our release strategy
Posted by David E Jones <de...@me.com>.
One point of clarification: it seems like the word "stable" here should be replaced by "bug free", as in [release branch] tends to be less "bug free" than the trunk. The release branch is inherently more "stable" because it doesn't change as much (ie the definition of stable), and I think Jacopo is really referring to the idea that we've discussed before that stability is not the same as being "bug free".
About the six month release period, I'm not so sure about that. It sounds like the idea is to give up on high quality releases in order to increase marketing. There are two problems I see with this:
1. this may not have a positive effect on marketing, I don't know but it seems like a large number of less meaningful press releases will not be as helpful as a few significant ones (yes, I know large companies tend to do lots of less meaningful press releases, but many of these stories are just another form of paid advertisement and press organizations like to carry them because name-dropping increases ad views for ads from other companies, and ad purchases from the companies mentioned, and therefore revenue; unfortunately Apache OFBiz doesn't benefit from this sort of status, so the story really needs to _mean_ something to get attention
2. I still think quality releases are important, and there are certain people in the community who consider this important and are willing to invest in and contribute to such an effort; if we move to more frequent releases it makes it much more difficult for the people who want to work on high quality releases, and decreases the chances that the project will ever have a vetted binary release
-David
On Feb 15, 2010, at 3:49 AM, 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
> * 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)
> * because of this, it tends to be less stable than 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
> 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
>
> What I suggest is based on the following assumptions:
> 1) community is not ready or interested in maintaining releases
> 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
> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>
> 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
> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>
> 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.
>
> What do you think?
>
> Jacopo
>
>
>
Re: Rethinking our release strategy
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
A few misc comments in partial response to some of the interesting comments posted in this thread:
* I initially proposed a release every 6 months but a release every 12 (as many of you have proposed) is totally fine to me; the important aspect here is that we agree on a time based release (instead of a feature based one) and that we agree on the strategy of officially release every year (not just creating a candidate release)
* when I wrote that the trunk is more stable than an old release I meant to say that the project's code, the framework, and the application are enhanced and improved over time the new bugs introduced are usually fixed in a rather short period; for this reason, it is true that there is a chance that this week the trunk could be less stable than the last week, but the chances that the trunk is less stable than one year ago are lower; this is my impression btw and I could be wrong
* we will fail if we think that we can guarantee that a release will have (free of charge) services to upgrade from older releases, documentation etc... we have to be realistic and pragmatic and we cannot ask to the committers to do more than what they are doing
Kind regards,
Jacopo
On Feb 15, 2010, at 11:49 AM, 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
> * 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)
> * because of this, it tends to be less stable than 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
> 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
>
> What I suggest is based on the following assumptions:
> 1) community is not ready or interested in maintaining releases
> 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
> 4) because our current policies (slowly increasing number of committers, peer reviews, etc...) our trunk is (and will be) more stable than older releases
>
> 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
> B) there is no guarantee that patches will be backported to releases, that upgrade scripts will be created from release to release
>
> 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.
>
> What do you think?
>
> Jacopo
>
>
>
Re: Rethinking our release strategy
Posted by Adrian Crum <ad...@hlmksw.com>.
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
> * 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)
> * because of this, it tends to be less stable than the trunk
I thought the whole point of a release was to make it *more* stable than
the trunk. I'm puzzled by your conclusion.
> 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
> 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
There seems to be a lot of subjective opinion here. I'm interested in
maintaining the release branch, and I commit fixes to it regularly.
> 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
My preference would be yearly.
-Adrian
Re: Rethinking our release strategy
Posted by Anil Patel <an...@hotwaxmedia.com>.
Jacques,
Thanks for quick help.
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 11:18 AM, Jacques Le Roux wrote:
> http://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan
>
> Thanks for the reminder Anil!
>
> Jacques
>
> From: "Anil Patel" <an...@hotwaxmedia.com>
>> 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
http://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan
Thanks for the reminder Anil!
Jacques
From: "Anil Patel" <an...@hotwaxmedia.com>
>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
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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"
>> ruth.hoffman@myofbiz.com
>>
>> 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
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
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"
> ruth.hoffman@myofbiz.com
>
> 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
Posted by David E Jones <de...@me.com>.
There is a big difference between software that implements public specifications (like SQL, JDBC, etc) and that tend to stay mostly the same over time and software like OFBiz that implements business concepts that are not driven by a public specification. Also, with PostgreSQL in particular as an example, that software was driven by commercial interests for the majority of its life, and OFBiz never has been.
I did attempt to get an effort going to produce some sort of requirements and designs to drive what goes into OFBiz, but that "marketplace" that drives OFBiz doesn't seem to be oriented to that.
IMO Anil is right on. In order to get these things done, and get them maintained over time, the people involved MUST have a motive to do so. So far that hasn't happened, and I guarantee that once a sufficient structure of motivation has been setup then people will get involved and these things will happen.
In the project right now contributors and committers do have reasons to put things into the project, even if most users of the software clearly don't understand the reasons involved.
Is it possible that a volunteer community will form and work on a documented, tested, high quality release? Yes it's possible, and I've been pushing to leave that door open with the approach we're using with the release branches (ie a place to start for those interested in such a thing). Has it happened? Yes, but only a little bit. There are people that fix bugs specifically in the release branches, just not very many. There is some documentation specifically for certain release branches, just not very much and not much collaboration in it.
So yeah, it could happen as a community effort but in order to get people motivated to do a good job with it my guess is that a commercial effort has a better chance of being sustainable. That would basically be a commercial distribution of OFBiz that includes support (installation, development, and production support), documentation, migration from one version of the distribution to another, etc.
One effort that started this way ended up being a fork of OFBiz. They didn't focus on being a distribution and instead focused on differentiation and user lock-in by creating add-ons and other things that competed with the open source community. So there is another important part: the people involved have to understand how to work with the open source community and provide the things that are really only viable with some funding, which is (for those interested) mostly stuff that people customizing the software will not typically do (there's a hint).
-David
On Feb 16, 2010, at 4:05 PM, 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"
> ruth.hoffman@myofbiz.com
>
> 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
Posted by Ruth Hoffman <rh...@aesolves.com>.
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"
ruth.hoffman@myofbiz.com
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
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
Moreover it derives from Ingres which begins in 1977...
Jacques
From: "BJ Freeman" <bj...@free-man.net>
> 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"
>> ruth.hoffman@myofbiz.com
>>
>> 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
Posted by BJ Freeman <bj...@free-man.net>.
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"
> ruth.hoffman@myofbiz.com
>
> 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
Posted by BJ Freeman <bj...@free-man.net>.
Also not that it has had to major revision since 1996
and it took 4yrs between revisions.
BJ Freeman sent the following on 2/17/2010 12:03 AM:
> 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"
>> ruth.hoffman@myofbiz.com
>>
>> 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
Posted by Anil Patel <an...@hotwaxmedia.com>.
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
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
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
Posted by BJ Freeman <bj...@free-man.net>.
Like to see a page that someone can note what they are testing and the
date that they completed that.
it would allow those to see how it progressing and volunteer.
to bad we don't have a ofbiz instance we could use the project
management module to track.
Jacques Le Roux sent the following on 2/16/2010 8:18 AM:
> http://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan
>
> Thanks for the reminder Anil!
>
> Jacques
>
> From: "Anil Patel" <an...@hotwaxmedia.com>
>> 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
Posted by Anil Patel <an...@hotwaxmedia.com>.
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
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
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
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> Plus, some of the technical work being done in the framework is intended
> to make it easier for end-user-oriented contributors to write code.
>
> The conversion framework is a perfect example: I just wanted to be able
> to pass a TimeDuration instance around the framework, but couldn't
> because of limitations in the framework. Once the conversion framework
> is completely integrated, all developers will be able to pass
> user-defined Java types around the framework easily.
And, of course, the webslinger stuff I have started to commit won't
nescessarily be used until the final step. This means there will be a
window where ofbiz has to maintain the code, with no apparent use case
for it.
However, what is good, is that Adrian's conversion framework was a
more advanced version of a library that webslinger already had, and I
was able to convert over to it with relative ease.
Re: Rethinking our release strategy
Posted by Adrian Crum <ad...@hlmksw.com>.
Plus, some of the technical work being done in the framework is intended
to make it easier for end-user-oriented contributors to write code.
The conversion framework is a perfect example: I just wanted to be able
to pass a TimeDuration instance around the framework, but couldn't
because of limitations in the framework. Once the conversion framework
is completely integrated, all developers will be able to pass
user-defined Java types around the framework easily.
-Adrian
David E Jones wrote:
> I saw the comment below about OFBiz becoming a "developers playground." I'll admit I have been thinking for a while that many contributions do not meet business (ie end-user) needs nor do they make it easier to meet end-user needs, and in fact in some cases even make that more difficult. However, my opinion is that this is caused by end-user oriented contributors being less active than technically oriented contributors, in fact I would say FAR less active, and less active now than in years past.
>
> Still, all of this comes down to the same message: if you want something to be done, or to be a certain way, either you figure out how to get other people to do it or you do it yourself.
>
> -David
>
>
> On Feb 15, 2010, at 9:03 AM, Ruth Hoffman wrote:
>
>> 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
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi David:
First, sorry I'm not making myself clear. I'm not asking that anything
be done. I only wished to reply to Jacopo's query "What do you think?"
Regards,
Ruth
David E Jones wrote:
> I saw the comment below about OFBiz becoming a "developers playground." I'll admit I have been thinking for a while that many contributions do not meet business (ie end-user) needs nor do they make it easier to meet end-user needs, and in fact in some cases even make that more difficult. However, my opinion is that this is caused by end-user oriented contributors being less active than technically oriented contributors, in fact I would say FAR less active, and less active now than in years past.
>
> Still, all of this comes down to the same message: if you want something to be done, or to be a certain way, either you figure out how to get other people to do it or you do it yourself.
>
> -David
>
>
> On Feb 15, 2010, at 9:03 AM, Ruth Hoffman wrote:
>
>
>> 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
Posted by David E Jones <de...@me.com>.
I saw the comment below about OFBiz becoming a "developers playground." I'll admit I have been thinking for a while that many contributions do not meet business (ie end-user) needs nor do they make it easier to meet end-user needs, and in fact in some cases even make that more difficult. However, my opinion is that this is caused by end-user oriented contributors being less active than technically oriented contributors, in fact I would say FAR less active, and less active now than in years past.
Still, all of this comes down to the same message: if you want something to be done, or to be a certain way, either you figure out how to get other people to do it or you do it yourself.
-David
On Feb 15, 2010, at 9:03 AM, Ruth Hoffman wrote:
> 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
Posted by Ruth Hoffman <rh...@aesolves.com>.
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
Posted by Adam Heath <do...@brainfood.com>.
chris snow wrote:
> If migration from old releases to newer ones was more automated (e.g.
> providing db migration scripts, ensuring consistent apis between releases,
> etc), it would be more practical to have only one (maybe two) stable release
> (i.e. supported). I imagine the main reason for users wanting very old
> releases to be supported is because the manual upgrade process is very
> laborious.
I have a plan to support in-place database upgrades. Need to find
where I did that.
>
> Shouldn't we make is easy for uses to upgrade to the latest stable release
> to make it easier to phase out old releases?
Re: Rethinking our release strategy
Posted by chris snow <ch...@gmail.com>.
If migration from old releases to newer ones was more automated (e.g.
providing db migration scripts, ensuring consistent apis between releases,
etc), it would be more practical to have only one (maybe two) stable release
(i.e. supported). I imagine the main reason for users wanting very old
releases to be supported is because the manual upgrade process is very
laborious.
Shouldn't we make is easy for uses to upgrade to the latest stable release
to make it easier to phase out old releases?
--
View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556463.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Rethinking our release strategy
Posted by Dimitri Unruh <di...@lynx.de>.
Jacopo,
this is exactly my point of view. So:
+1
Viele Grüße
Best Regards
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
----------------------------------------------------------------------------------------------------
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
----------------------------------------------------------------------------------------------------
SAP Special Expertise Partner ERP Upgrade
Erfolg ist eine Folge. 20 Jahre Lynx
From: Jacopo Cappellato <ja...@hotwaxmedia.com>
To: dev@ofbiz.apache.org
Date: 15.02.2010 11:50
Subject: Rethinking our release strategy
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
* 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)
* because of this, it tends to be less stable than 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
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
What I suggest is based on the following assumptions:
1) community is not ready or interested in maintaining releases
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
4) because our current policies (slowly increasing number of committers,
peer reviews, etc...) our trunk is (and will be) more stable than older
releases
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
B) there is no guarantee that patches will be backported to releases, that
upgrade scripts will be created from release to release
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.
What do you think?
Jacopo
Re: Rethinking our release strategy
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
It's useful because end users can see that functionality they are using
actually has a person(s) that is commited to its quality. As has
already been mentioned, ofbiz feels like a "developers playground".
This makes me nervous building important business processes around ofbiz.
A key factor in me choosing ofbiz for my current government client was
that the area we were using (workeffort, iCalendar) had a committer who
was very interested in the quality of those areas.
Scott Gray wrote:
> On 16/02/2010, at 12:31 AM, Christopher Snow wrote:
>
>
>> Hi Scott,
>>
>> It would be very useful for an outsider to see who is "responsible" for what.
>>
>
> How would it be useful?
>
>
>> Scott Gray wrote:
>>
>>> What would we achieve by cataloging the pieces of the project we feel confident with? If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
>>>
>>>
>>>
>>>> Or even informal roles.
>>>>
>>>> For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
>>>>
>>>> I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
>>>>
>>>> The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
>>>>
>>>> W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
>>>>
>>>> -Adrian
>>>>
>>>>
>
>
Re: Rethinking our release strategy
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi Chris,
Our current strategy of using the dev list for discussions and creating design documents in confluence when deemed necessary achieves that quite nicely, the only potential point of failure for that process is a lack of participation and I don't see how assigning areas of responsibility would overcome that obstacle.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 16/02/2010, at 11:42 AM, Christopher Snow wrote:
> Hi Scott, from my perspective it would be a starting point in turning a bunch of independent committers into a well organised team.
>
> Scott Gray wrote:
>> That's makes it sounds more like a help directory for who to call upon when a user has a question. What benefit would a community member derive from knowing that you know that a French week starts on a Monday? If they have a question they can just post it to the user list and get a response, does it make a difference if they start the message with "Hi Adrian,"?
>>
>> What additional rights or responsibilities would come with declaring yourself an expert/overseer for a given area of functionality?
>>
>> I'm not coming out against the idea, I just still don't understand what we'll actually achieve by doing so.
>>
>> Regards
>> Scott
>>
>> On 16/02/2010, at 1:16 AM, Adrian Crum wrote:
>>
>>
>>> Scott,
>>>
>>> I can answer to that. My employer is located in the southwestern corner of the USA. We only do business in the southwest USA.
>>>
>>> As an OFBiz developer, I have taken on the cause for internationalization - not because it benefits my employer, but because it benefits the project.
>>>
>>> I speak very little French, but I know that a calendar week in France starts on Monday. How do I know that? Because it is something I chose to learn.
>>>
>>> How will others in the community know that I know that?
>>>
>>> *shrug*
>>>
>>> Maybe a Wiki page will tell them.
>>>
>>> -Adrian
>>>
>>> --- On Mon, 2/15/10, Scott Gray <sc...@hotwaxmedia.com> wrote:
>>>
>>>
>
Re: Rethinking our release strategy
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
Hi Scott, from my perspective it would be a starting point in turning a
bunch of independent committers into a well organised team.
Scott Gray wrote:
> That's makes it sounds more like a help directory for who to call upon when a user has a question. What benefit would a community member derive from knowing that you know that a French week starts on a Monday? If they have a question they can just post it to the user list and get a response, does it make a difference if they start the message with "Hi Adrian,"?
>
> What additional rights or responsibilities would come with declaring yourself an expert/overseer for a given area of functionality?
>
> I'm not coming out against the idea, I just still don't understand what we'll actually achieve by doing so.
>
> Regards
> Scott
>
> On 16/02/2010, at 1:16 AM, Adrian Crum wrote:
>
>
>> Scott,
>>
>> I can answer to that. My employer is located in the southwestern corner of the USA. We only do business in the southwest USA.
>>
>> As an OFBiz developer, I have taken on the cause for internationalization - not because it benefits my employer, but because it benefits the project.
>>
>> I speak very little French, but I know that a calendar week in France starts on Monday. How do I know that? Because it is something I chose to learn.
>>
>> How will others in the community know that I know that?
>>
>> *shrug*
>>
>> Maybe a Wiki page will tell them.
>>
>> -Adrian
>>
>> --- On Mon, 2/15/10, Scott Gray <sc...@hotwaxmedia.com> wrote:
>>
>>
Re: Rethinking our release strategy
Posted by Adam Heath <do...@brainfood.com>.
Scott Gray wrote:
> That's makes it sounds more like a help directory for who to call upon when a user has a question. What benefit would a community member derive from knowing that you know that a French week starts on a Monday? If they have a question they can just post it to the user list and get a response, does it make a difference if they start the message with "Hi Adrian,"?
>
> What additional rights or responsibilities would come with declaring yourself an expert/overseer for a given area of functionality?
>
> I'm not coming out against the idea, I just still don't understand what we'll actually achieve by doing so.
Additionally, if we list specific people as 'in charge' of certain
areas, they may end up getting private mails, which could get lost,
and might not even be answered quickly enough.
Mailing to any of the lists would get a faster response, from anyone
who just happens to know the answer.
Re: Rethinking our release strategy
Posted by Scott Gray <sc...@hotwaxmedia.com>.
That's makes it sounds more like a help directory for who to call upon when a user has a question. What benefit would a community member derive from knowing that you know that a French week starts on a Monday? If they have a question they can just post it to the user list and get a response, does it make a difference if they start the message with "Hi Adrian,"?
What additional rights or responsibilities would come with declaring yourself an expert/overseer for a given area of functionality?
I'm not coming out against the idea, I just still don't understand what we'll actually achieve by doing so.
Regards
Scott
On 16/02/2010, at 1:16 AM, Adrian Crum wrote:
> Scott,
>
> I can answer to that. My employer is located in the southwestern corner of the USA. We only do business in the southwest USA.
>
> As an OFBiz developer, I have taken on the cause for internationalization - not because it benefits my employer, but because it benefits the project.
>
> I speak very little French, but I know that a calendar week in France starts on Monday. How do I know that? Because it is something I chose to learn.
>
> How will others in the community know that I know that?
>
> *shrug*
>
> Maybe a Wiki page will tell them.
>
> -Adrian
>
> --- On Mon, 2/15/10, Scott Gray <sc...@hotwaxmedia.com> wrote:
>
>> From: Scott Gray <sc...@hotwaxmedia.com>
>> Subject: Re: Rethinking our release strategy
>> To: dev@ofbiz.apache.org
>> Date: Monday, February 15, 2010, 11:33 PM
>> On 16/02/2010, at 12:31 AM,
>> Christopher Snow wrote:
>>
>>> Hi Scott,
>>>
>>> It would be very useful for an outsider to see who is
>> "responsible" for what.
>>
>> How would it be useful?
>>
>>> Scott Gray wrote:
>>>> What would we achieve by cataloging the pieces of
>> the project we feel confident with? If it's not a
>> serious commitment then how would it differ from what we do
>> right now, aside from having an extra wiki page?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
>>>>
>>>>
>>>>> Or even informal roles.
>>>>>
>>>>> For example: My employer doesn't use
>> eCommerce, so I am not qualified to be responsible for that.
>> But, I will gladly take on responsibility for areas of the
>> project my employer uses - like Work Effort and Asset
>> Maintenance.
>>>>>
>>>>> I have been thinking about that lately - each
>> contributor or committer could list the areas they feel
>> comfortable with overseeing. It would be strictly voluntary
>> - not a serious commitment or anything.
>>>>>
>>>>> The reason I suggest it is because I recognize
>> my own limitations - I can't review and comment on
>> EVERYTHING. I have a feeling other committers are in the
>> same situation. So, why not catalog our strengths, and
>> assume responsibility for pieces of the project we feel
>> confident with - instead of (right or wrong) feeling
>> responsible for the whole project.
>>>>>
>>>>> W could use the service provider Wiki page as
>> a model - create a Wiki page where everyone advertises what
>> areas of the project they feel knowledgeable in.
>>>>>
>>>>> -Adrian
>>>>>
>>>
>>
>>
>
>
>
Re: Rethinking our release strategy
Posted by Adrian Crum <ad...@yahoo.com>.
Scott,
I can answer to that. My employer is located in the southwestern corner of the USA. We only do business in the southwest USA.
As an OFBiz developer, I have taken on the cause for internationalization - not because it benefits my employer, but because it benefits the project.
I speak very little French, but I know that a calendar week in France starts on Monday. How do I know that? Because it is something I chose to learn.
How will others in the community know that I know that?
*shrug*
Maybe a Wiki page will tell them.
-Adrian
--- On Mon, 2/15/10, Scott Gray <sc...@hotwaxmedia.com> wrote:
> From: Scott Gray <sc...@hotwaxmedia.com>
> Subject: Re: Rethinking our release strategy
> To: dev@ofbiz.apache.org
> Date: Monday, February 15, 2010, 11:33 PM
> On 16/02/2010, at 12:31 AM,
> Christopher Snow wrote:
>
> > Hi Scott,
> >
> > It would be very useful for an outsider to see who is
> "responsible" for what.
>
> How would it be useful?
>
> > Scott Gray wrote:
> >> What would we achieve by cataloging the pieces of
> the project we feel confident with? If it's not a
> serious commitment then how would it differ from what we do
> right now, aside from having an extra wiki page?
> >>
> >> Regards
> >> Scott
> >>
> >> HotWax Media
> >> http://www.hotwaxmedia.com
> >>
> >> On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
> >>
> >>
> >>> Or even informal roles.
> >>>
> >>> For example: My employer doesn't use
> eCommerce, so I am not qualified to be responsible for that.
> But, I will gladly take on responsibility for areas of the
> project my employer uses - like Work Effort and Asset
> Maintenance.
> >>>
> >>> I have been thinking about that lately - each
> contributor or committer could list the areas they feel
> comfortable with overseeing. It would be strictly voluntary
> - not a serious commitment or anything.
> >>>
> >>> The reason I suggest it is because I recognize
> my own limitations - I can't review and comment on
> EVERYTHING. I have a feeling other committers are in the
> same situation. So, why not catalog our strengths, and
> assume responsibility for pieces of the project we feel
> confident with - instead of (right or wrong) feeling
> responsible for the whole project.
> >>>
> >>> W could use the service provider Wiki page as
> a model - create a Wiki page where everyone advertises what
> areas of the project they feel knowledgeable in.
> >>>
> >>> -Adrian
> >>>
> >
>
>
Re: Rethinking our release strategy
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 16/02/2010, at 12:31 AM, Christopher Snow wrote:
> Hi Scott,
>
> It would be very useful for an outsider to see who is "responsible" for what.
How would it be useful?
> Scott Gray wrote:
>> What would we achieve by cataloging the pieces of the project we feel confident with? If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
>>
>>
>>> Or even informal roles.
>>>
>>> For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
>>>
>>> I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
>>>
>>> The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
>>>
>>> W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
>>>
>>> -Adrian
>>>
>
Re: Rethinking our release strategy
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
Hi Scott,
It would be very useful for an outsider to see who is "responsible" for
what.
Also, I think we need roles other than "committer" for proper release
management.
Other roles would be useful too, such as "dependency manager" whose goal
is to ensure dependencies are correctly managed.
Thanks,
Chris
Scott Gray wrote:
> What would we achieve by cataloging the pieces of the project we feel confident with? If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
>
>
>> Or even informal roles.
>>
>> For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
>>
>> I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
>>
>> The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
>>
>> W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
>>
>> -Adrian
>>
Re: Rethinking our release strategy
Posted by Scott Gray <sc...@hotwaxmedia.com>.
What would we achieve by cataloging the pieces of the project we feel confident with? If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 16/02/2010, at 12:04 AM, Adrian Crum wrote:
> Or even informal roles.
>
> For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
>
> I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
>
> The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
>
> W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
>
> -Adrian
>
>
> --- On Mon, 2/15/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:
>
>> From: Christopher Snow <sn...@snowconsulting.co.uk>
>> Subject: Re: Rethinking our release strategy
>> To: dev@ofbiz.apache.org
>> Date: Monday, February 15, 2010, 10:16 PM
>> As part of the release plan, could we
>> create some formal roles responsible for certain aspects for
>> each release? i.e. people responsible for:
>>
>> - migration from previous release
>> - documentation
>> - patch management
>> - etc
>>
>>
>> David E Jones wrote:
>>> A release plan would be great. How are we going to do
>> that, or what would it look like?
>>>
>>> -David
>>>
>>>
>>> On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:
>>>
>>>
>>>> Hi
>>>> It sounds like there 's some confusion as to
>> whether the release branches
>>>> are being updated with bug fixes or not. I thought
>> they were.
>>>>
>>>> My focus has been pretty much been on OFBiz
>> documentation and I find it
>>>> very, very hard to document things as they are
>> changing so fast. Features
>>>> seemed to be added with no hint of documentation
>> or even a spec. The only
>>>> way to find out how things work, is trial
>> and error and not everyone is
>>>> interested in (or capable of) looking at or
>> understanding the code.
>>>> Personally I'd like to see a yearly release plan
>> so that we could at least
>>>> ensure that we had enough time to make it truly
>> stable and that the right
>>>> documentation is in place to support the release.
>>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>> -- View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
>>>> Sent from the OFBiz - Dev mailing list archive at
>> Nabble.com.
>>>>
>>>
>>>
>>
>>
>
>
>
Re: Rethinking our release strategy
Posted by Adrian Crum <ad...@yahoo.com>.
Or even informal roles.
For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything.
The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project.
W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in.
-Adrian
--- On Mon, 2/15/10, Christopher Snow <sn...@snowconsulting.co.uk> wrote:
> From: Christopher Snow <sn...@snowconsulting.co.uk>
> Subject: Re: Rethinking our release strategy
> To: dev@ofbiz.apache.org
> Date: Monday, February 15, 2010, 10:16 PM
> As part of the release plan, could we
> create some formal roles responsible for certain aspects for
> each release? i.e. people responsible for:
>
> - migration from previous release
> - documentation
> - patch management
> - etc
>
>
> David E Jones wrote:
> > A release plan would be great. How are we going to do
> that, or what would it look like?
> >
> > -David
> >
> >
> > On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:
> >
> >
> >> Hi
> >> It sounds like there 's some confusion as to
> whether the release branches
> >> are being updated with bug fixes or not. I thought
> they were.
> >>
> >> My focus has been pretty much been on OFBiz
> documentation and I find it
> >> very, very hard to document things as they are
> changing so fast. Features
> >> seemed to be added with no hint of documentation
> or even a spec. The only
> >> way to find out how things work, is trial
> and error and not everyone is
> >> interested in (or capable of) looking at or
> understanding the code.
> >> Personally I'd like to see a yearly release plan
> so that we could at least
> >> ensure that we had enough time to make it truly
> stable and that the right
> >> documentation is in place to support the release.
> >>
> >> Thanks
> >> Sharan
> >>
> >> -- View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
> >> Sent from the OFBiz - Dev mailing list archive at
> Nabble.com.
> >>
> >
> >
>
>
Re: Rethinking our release strategy
Posted by Christopher Snow <sn...@snowconsulting.co.uk>.
As part of the release plan, could we create some formal roles
responsible for certain aspects for each release? i.e. people
responsible for:
- migration from previous release
- documentation
- patch management
- etc
David E Jones wrote:
> A release plan would be great. How are we going to do that, or what would it look like?
>
> -David
>
>
> On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:
>
>
>> Hi
>>
>> It sounds like there 's some confusion as to whether the release branches
>> are being updated with bug fixes or not. I thought they were.
>>
>> My focus has been pretty much been on OFBiz documentation and I find it
>> very, very hard to document things as they are changing so fast. Features
>> seemed to be added with no hint of documentation or even a spec. The only
>> way to find out how things work, is trial and error and not everyone is
>> interested in (or capable of) looking at or understanding the code.
>>
>> Personally I'd like to see a yearly release plan so that we could at least
>> ensure that we had enough time to make it truly stable and that the right
>> documentation is in place to support the release.
>>
>> Thanks
>> Sharan
>>
>> --
>> View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>
>
Re: Rethinking our release strategy
Posted by David E Jones <de...@me.com>.
A release plan would be great. How are we going to do that, or what would it look like?
-David
On Feb 15, 2010, at 1:20 PM, Sharan-F wrote:
> Hi
>
> It sounds like there 's some confusion as to whether the release branches
> are being updated with bug fixes or not. I thought they were.
>
> My focus has been pretty much been on OFBiz documentation and I find it
> very, very hard to document things as they are changing so fast. Features
> seemed to be added with no hint of documentation or even a spec. The only
> way to find out how things work, is trial and error and not everyone is
> interested in (or capable of) looking at or understanding the code.
>
> Personally I'd like to see a yearly release plan so that we could at least
> ensure that we had enough time to make it truly stable and that the right
> documentation is in place to support the release.
>
> Thanks
> Sharan
>
> --
> View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Rethinking our release strategy
Posted by Sharan-F <sh...@gmail.com>.
Hi
It sounds like there 's some confusion as to whether the release branches
are being updated with bug fixes or not. I thought they were.
My focus has been pretty much been on OFBiz documentation and I find it
very, very hard to document things as they are changing so fast. Features
seemed to be added with no hint of documentation or even a spec. The only
way to find out how things work, is trial and error and not everyone is
interested in (or capable of) looking at or understanding the code.
Personally I'd like to see a yearly release plan so that we could at least
ensure that we had enough time to make it truly stable and that the right
documentation is in place to support the release.
Thanks
Sharan
--
View this message in context: http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.