My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves

[David E Jones-3]

First off, the conference was great and thank you to everyone who  
participated. We actually has less attendance than the previous OFBiz  
User Conference at the sessions, but more OFBiz-related people were  
there overall. We had about 1/3 of the committers there, quite a few  
people who SHOULD be committers (ie using OFBiz a lot, doing neat  
things with it, but just not as involved in contributing back to the  
project as they could be... you know who you are! ;) ), and quite a  
few people who are interested in OFBiz that we spoke with outside of  
the OFBiz-specific sessions (including one of the keynote speakers).

On top of that, and one of the more valuable parts of this event, was  
the chance to meet so many of the people who make the Apache Software  
Foundation what it is. I've been amazed at how welcome they have made  
me feel, and others have made similar comments. The community-driven  
philosophy at the ASF is strong, and it is also one of the biggest  
differentiators between OFBiz and other "open source" enterprise  
systems, which are really corporate driven and are developed in a more  
commercial way rather than being community driven. People at the ASF  
really get the difference and why it makes a difference, and it's  
great to communicate and collaborate with them. Real quick, a special  
thanks to Shane, Lars, Delia, Cheryl, and others on the conference  
committee who helped make this happen.

BTW, on a side note there was major sponsorship from a few companies  
that do work based on OFBiz, including Hotwax, and Brainfood. On one  
notable evening (Thursday), thanks to Brainfood, we had a jazz funeral  
parade in honor of proprietary software. There was a marching band and  
police escort and we even marched down Canal Street for 3 blocks with  
the police closing it off for us (that's a major street in New  
Orleans, and it was pretty cool), and we had around 150 people marching.

In short, it was hugely valuable and for me it definitely helped to  
solidify parts of a vision of what we can do with in this next era of  
Apache OFBiz.

Before getting into my more complete notes, it seemed that most of the  
discussions at the conference focused around a couple of points:

1. more and better marketing of OFBiz
2. organize ourselves better:
2.a. now that base applications are fairly comprehensive, start  
refining and extending based on open standards and community effort to  
create a library of business process stories (like the universal data  
model OFBiz started with)
2.b. time to eat our own dog food (use OFBiz instead of Jira,  
Confluence, etc), and once we get there expand to the rest of the ASF  
to replace these tools

Some more detailed notes about things discussed:

Marketing
- new ofbiz home page - pretty and simple
- organize docs better
- docs with marketing/influence intent instead of informational
- promote community model and community-driven open source
- promote empowerment and software to fit the business, without all  
the spreadsheets and supplemental systems!
- OFBiz Alliance w/ advertising, required internal use of OFBiz, etc -  
We are Open For Business
- Viral marketing campaign, "I am Open For Business" on personal  
sites, funny videos on YouTube saying the catch phrase, link to  
ofbiz.apache.org
- OFBiz no longer on first page of google search for "open source  
erp" (near the top of the second page), and I don't see ofbiz in the  
first 10 pages of "open source crm", for "open source ecommerce" we're  
on the 4th page
- Google adwords and similar for "open for business", "I am open for  
business", "we are open for business", "open source erp" (not paid by  
"OFBiz", but rather by interested community members)

Community Organize
- OFBiz Universal Business Process Library
- Mobilize test contributors (testtools, selenium, etc), allow  
separate people to be involved in contributing tests and contributing  
features (don't require test submission, but if anyone wants something  
to work in a certain way, they should submit a test for it as our  
normal way of doing things)
- Links from tests to bus proc docs
- Pursuit of open standards - find and document desired standards,  
refer to in process library, change service defs to be close to,  
eventually implement messaging/etc according to (UBL, OAGIS, XBRL, etc)
   - TODO: add XBRL/etc write up to confluence, send email
- Component groups and hierarchy
   - TODO: upload diagrams of base apps dependencies, loosely enforced
   - TODO: propose goal of framework, base applications, and special  
purpose apps layers
   - avoid dependencies between specialpurpose apps, push things that  
others need to the base applications where cross-dependencies are  
natural
- Eat our own dog food
   - Content management (replace confluence)
   - Project management (issues/requests, tasks, upstream issues  
handled by system (ie users promote to OFBiz, OFBiz promotes to Tomcat/
Geronimo/FOP/etc with ASF, ASF projects promote to ?)
- Framework release
   - gather ideas from people in a confluence page (TODO: add my own)
   - complex UIs, GWT, DOJO, etc renderers for widgets
- Testing tools: seleniumxml -> testtools + demo (need to look into  
licensing problems)

The "TODO" items are notes to myself for things to do. I'll be sending  
out more messages soon about a few of these specific things.

For others who attended, please feel free to share your notes on this  
thread.

For those who did not attend, please feel free to ask questions and  
share your thoughts too.

-David

[Adrian Crum]

David E Jones wrote:
> - Framework release
>   - gather ideas from people in a confluence page (TODO: add my own)
>   - complex UIs, GWT, DOJO, etc renderers for widgets

I've been thinking about the framework release and our current Release
4. Release 4 will be two years old in a few months. A lot has been done
to the project since the R4 branch. How about making a Release 5 branch
(whole project) sometime around Spring?

I don't mean to dilute the framework release effort. But at the same
time, it seems to me issues are coming up in R4 that have been addressed
in the trunk.

-Adrian

[Bruno Busco]

In my opinion two key points to support the new and stronger OFBiz marketing
campains are:
1) Improve the OFBiz UI (we should at least reach this level:
http://www.compiere.com/products/product-demos/tour/web_ui_demo.htm)
2) Have OFBiz self hosting

There is no better marketing then the product itself.
-Bruno

2008/11/12 David E Jones <[hidden email]>

>
> First off, the conference was great and thank you to everyone who
> participated. We actually has less attendance than the previous OFBiz User
> Conference at the sessions, but more OFBiz-related people were there
> overall. We had about 1/3 of the committers there, quite a few people who
> SHOULD be committers (ie using OFBiz a lot, doing neat things with it, but
> just not as involved in contributing back to the project as they could be...
> you know who you are! ;) ), and quite a few people who are interested in
> OFBiz that we spoke with outside of the OFBiz-specific sessions (including
> one of the keynote speakers).
>
> On top of that, and one of the more valuable parts of this event, was the
> chance to meet so many of the people who make the Apache Software Foundation
> what it is. I've been amazed at how welcome they have made me feel, and
> others have made similar comments. The community-driven philosophy at the
> ASF is strong, and it is also one of the biggest differentiators between
> OFBiz and other "open source" enterprise systems, which are really corporate
> driven and are developed in a more commercial way rather than being
> community driven. People at the ASF really get the difference and why it
> makes a difference, and it's great to communicate and collaborate with them.
> Real quick, a special thanks to Shane, Lars, Delia, Cheryl, and others on
> the conference committee who helped make this happen.
>
> BTW, on a side note there was major sponsorship from a few companies that
> do work based on OFBiz, including Hotwax, and Brainfood. On one notable
> evening (Thursday), thanks to Brainfood, we had a jazz funeral parade in
> honor of proprietary software. There was a marching band and police escort
> and we even marched down Canal Street for 3 blocks with the police closing
> it off for us (that's a major street in New Orleans, and it was pretty
> cool), and we had around 150 people marching.
>
> In short, it was hugely valuable and for me it definitely helped to
> solidify parts of a vision of what we can do with in this next era of Apache
> OFBiz.
>
> Before getting into my more complete notes, it seemed that most of the
> discussions at the conference focused around a couple of points:
>
> 1. more and better marketing of OFBiz
> 2. organize ourselves better:
> 2.a. now that base applications are fairly comprehensive, start refining
> and extending based on open standards and community effort to create a
> library of business process stories (like the universal data model OFBiz
> started with)
> 2.b. time to eat our own dog food (use OFBiz instead of Jira, Confluence,
> etc), and once we get there expand to the rest of the ASF to replace these
> tools
>
> Some more detailed notes about things discussed:
>
> Marketing
> - new ofbiz home page - pretty and simple
> - organize docs better
> - docs with marketing/influence intent instead of informational
> - promote community model and community-driven open source
> - promote empowerment and software to fit the business, without all the
> spreadsheets and supplemental systems!
> - OFBiz Alliance w/ advertising, required internal use of OFBiz, etc - We
> are Open For Business
> - Viral marketing campaign, "I am Open For Business" on personal sites,
> funny videos on YouTube saying the catch phrase, link to ofbiz.apache.org
> - OFBiz no longer on first page of google search for "open source erp"
> (near the top of the second page), and I don't see ofbiz in the first 10
> pages of "open source crm", for "open source ecommerce" we're on the 4th
> page
> - Google adwords and similar for "open for business", "I am open for
> business", "we are open for business", "open source erp" (not paid by
> "OFBiz", but rather by interested community members)
>
> Community Organize
> - OFBiz Universal Business Process Library
> - Mobilize test contributors (testtools, selenium, etc), allow separate
> people to be involved in contributing tests and contributing features (don't
> require test submission, but if anyone wants something to work in a certain
> way, they should submit a test for it as our normal way of doing things)
> - Links from tests to bus proc docs
> - Pursuit of open standards - find and document desired standards, refer to
> in process library, change service defs to be close to, eventually implement
> messaging/etc according to (UBL, OAGIS, XBRL, etc)
>  - TODO: add XBRL/etc write up to confluence, send email
> - Component groups and hierarchy
>  - TODO: upload diagrams of base apps dependencies, loosely enforced
>  - TODO: propose goal of framework, base applications, and special purpose
> apps layers
>  - avoid dependencies between specialpurpose apps, push things that others
> need to the base applications where cross-dependencies are natural
> - Eat our own dog food
>  - Content management (replace confluence)
>  - Project management (issues/requests, tasks, upstream issues handled by
> system (ie users promote to OFBiz, OFBiz promotes to Tomcat/Geronimo/FOP/etc
> with ASF, ASF projects promote to ?)
> - Framework release
>  - gather ideas from people in a confluence page (TODO: add my own)
>  - complex UIs, GWT, DOJO, etc renderers for widgets
> - Testing tools: seleniumxml -> testtools + demo (need to look into
> licensing problems)
>
> The "TODO" items are notes to myself for things to do. I'll be sending out
> more messages soon about a few of these specific things.
>
> For others who attended, please feel free to share your notes on this
> thread.
>
> For those who did not attend, please feel free to ask questions and share
> your thoughts too.
>
> -David
>
>
>
>

[David E Jones-3]

On Nov 12, 2008, at 12:04 PM, Adrian Crum wrote:

> David E Jones wrote:
>> - Framework release
>>  - gather ideas from people in a confluence page (TODO: add my own)
>>  - complex UIs, GWT, DOJO, etc renderers for widgets
>
> I've been thinking about the framework release and our current  
> Release 4. Release 4 will be two years old in a few months. A lot  
> has been done to the project since the R4 branch. How about making a  
> Release 5 branch (whole project) sometime around Spring?

I think that's fine. Hopefully by then we'll have more framework  
things done.

What I'd really like to hear for releases is what people plan to do  
with the release branch. In general in order to facilitate  
collaboration and such it is best to use the trunk. Unless we have a  
lot of people using OFBiz OOTB then it may not make sense to do  
releases at all, even "lite" releases like these release branches.

Still, we can and should do them periodically, and they are of course  
very easy to do (just make a branch...) and then it is up to  
individuals to decide whether to use it and fix bugs in it or now.


> I don't mean to dilute the framework release effort. But at the same  
> time, it seems to me issues are coming up in R4 that have been  
> addressed in the trunk.

While to some extent this depends on the type of issue, in general  
issues in the 4.0.0 branch should be fixed in that branch by the "sub-
community" that has formed around the branch. If things are not  
getting fixed, to me that means the branch has not attracted enough of  
a user and contributor community. I don't know how to fix that  
problem...

-David

[Adrian Crum]

David E Jones wrote:
>> I don't mean to dilute the framework release effort. But at the same
>> time, it seems to me issues are coming up in R4 that have been
>> addressed in the trunk.
>
> While to some extent this depends on the type of issue, in general
> issues in the 4.0.0 branch should be fixed in that branch by the
> "sub-community" that has formed around the branch. If things are not
> getting fixed, to me that means the branch has not attracted enough of a
> user and contributor community. I don't know how to fix that problem...

It is true that most of the bugs discovered in R4 are fixed as they come
up. I was thinking more along the line of the kinds of things that were
corrected by refactorings and such.

I've run across a number of people using R4 and service providers who
are using R4 for their customer's deployments. In addition, Opentaps is
based on R4. So, there is a sizeable R4 community out there, even if
they aren't vocal on the mailing lists and such.

I guess the goal or purpose of a Release 5 would be the same as Release
4 - to provide the opportunity to build on a target that isn't moving.

I agree that there needs to be a community of people who want it and are
willing to support it. I was just tossing the idea out there, but at
this point in time there doesn't seem to be much interest.

-Adrian

[BJ Freeman]

I believe from comments on the mailing list that Rev 4.0 is used.
I also believe that it is stable enough that people are not entering
bugs, as such.
I only believe the trunk should be use as a release, like in the nightly
builds, once the testing and verification of every commit is done.
i do believe that is what is suppose to happen now from what I read
about committing. However I see signs from the commit logs of things
being entered and then corrected. This indicates to me that testing is
not done before commits.


David E Jones sent the following on 11/13/2008 10:45 PM:

>
> On Nov 12, 2008, at 12:04 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> - Framework release
>>>  - gather ideas from people in a confluence page (TODO: add my own)
>>>  - complex UIs, GWT, DOJO, etc renderers for widgets
>>
>> I've been thinking about the framework release and our current Release
>> 4. Release 4 will be two years old in a few months. A lot has been
>> done to the project since the R4 branch. How about making a Release 5
>> branch (whole project) sometime around Spring?
>
> I think that's fine. Hopefully by then we'll have more framework things
> done.
>
> What I'd really like to hear for releases is what people plan to do with
> the release branch. In general in order to facilitate collaboration and
> such it is best to use the trunk. Unless we have a lot of people using
> OFBiz OOTB then it may not make sense to do releases at all, even "lite"
> releases like these release branches.
>
> Still, we can and should do them periodically, and they are of course
> very easy to do (just make a branch...) and then it is up to individuals
> to decide whether to use it and fix bugs in it or now.
>
>
>> I don't mean to dilute the framework release effort. But at the same
>> time, it seems to me issues are coming up in R4 that have been
>> addressed in the trunk.
>
> While to some extent this depends on the type of issue, in general
> issues in the 4.0.0 branch should be fixed in that branch by the
> "sub-community" that has formed around the branch. If things are not
> getting fixed, to me that means the branch has not attracted enough of a
> user and contributor community. I don't know how to fix that problem...
>
> -David
>
>
>
>
>

[David E Jones-3]

On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:

> David E Jones wrote:
>>> I don't mean to dilute the framework release effort. But at the  
>>> same time, it seems to me issues are coming up in R4 that have  
>>> been addressed in the trunk.
>> While to some extent this depends on the type of issue, in general  
>> issues in the 4.0.0 branch should be fixed in that branch by the  
>> "sub-community" that has formed around the branch. If things are  
>> not getting fixed, to me that means the branch has not attracted  
>> enough of a user and contributor community. I don't know how to fix  
>> that problem...
>
> It is true that most of the bugs discovered in R4 are fixed as they  
> come up. I was thinking more along the line of the kinds of things  
> that were corrected by refactorings and such.
>
> I've run across a number of people using R4 and service providers  
> who are using R4 for their customer's deployments. In addition,  
> Opentaps is based on R4. So, there is a sizeable R4 community out  
> there, even if they aren't vocal on the mailing lists and such.
>
> I guess the goal or purpose of a Release 5 would be the same as  
> Release 4 - to provide the opportunity to build on a target that  
> isn't moving.
>
> I agree that there needs to be a community of people who want it and  
> are willing to support it. I was just tossing the idea out there,  
> but at this point in time there doesn't seem to be much interest.

These are good points Adrian. Don't let my "Devil's Advocate" approach  
scare you away or make you think there is no interest in doing these.  
I imagine there are many people who would like to see release branches  
happen.

Part of the reason I wrote some doubts about it is that there is an  
open source mantra of "release early, release often" and I was  
wondering about that... What if we took the opposite approach of  
"never release"? It's the total opposite extreme and I'm not  
completely sure I like the idea, but it has some really interesting  
points. For example it encourages:

1. community interaction, even for those who are just "users" and not  
sending things back
2. frequent upgrades by all users to resolve issues
3. community responsibility, rising the priority of things like  
automated testing, and giving people more reasons to get involved with  
that testing and contribute tests
4. base application design decision refinement to help people with  
regular updates and resolving issues while not creating new ones
5. something the press can write about that is very different from  
things done in other places
6. a social experiment in collaborative enterprise software that is  
yet unseen in the world

Of course, there are disadvantages, like:

1. a smaller user community because the prospect is scary

Maybe that's it. I really think that if as a community we work more on  
automated regression tests and such we'll have a higher quality of  
software in the trunk than is in the release branches, partially  
because of what Adrian mentioned (and I alluded to) where certain  
types of issues require a lot of refactoring and aren't simple fixes  
that can go into a release branch.

Anyway, something to think about. In a way doing release branches  
breaks important aspects of the "never release" approach because  
things like #1, #2 and certain of the others won't happen, or won't  
happen as much. Actually, it applies to more, maybe especially #3. If  
we never release, developers have no excuse of making things unstable,  
or committing without thinking about things, or throwing stuff out for  
they are designed well. There is no excuse of "if people want  
something stable, use the release branch, and leave us alone!"

I'm still for doing another release branch early next year (and  
continuing with 18-24 months between branches), unless a lot of people  
find the "never release" philosophy interesting.

-David

[Bruno Busco]

What about using a "release candidate branch" in place of a "release branch"
?

With this I mean:

1) the release candidate branch could be started at any time (even from the
trunk as it is right now)

2) the actually open JIRAs should be selected and the "fix version" field
should be changed to the new scheduled release candidate for what the
community agrees to be included in the release (even some new features).
This gives a clear idea to all the community of what needs to be done to get
the release done. And I guess all the active community will try to have them
done with a high priority. (The answer to the question "When will we have
the new release?" will be "When we will have all the scheduled issues
closed. Please give them a look and attach a (tested) patch."

3) when all the JIRAs scheduled on the release candidate are closed the
release can be done, a tag is created and the release (maintenance) branch
is started where only bug fix are committed.

4) in addition to this I would create a tag from the release maintenance
branch whenever a reasonable amount of fixes are done.

I think this approach is very standard, no extra efforts are requested that
we cannot do and gives a clear idea to everybody of where we are.

-Bruno

2008/11/14 David E Jones <[hidden email]>

>
> On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
>
>  David E Jones wrote:
>>
>>> I don't mean to dilute the framework release effort. But at the same
>>>> time, it seems to me issues are coming up in R4 that have been addressed in
>>>> the trunk.
>>>>
>>> While to some extent this depends on the type of issue, in general issues
>>> in the 4.0.0 branch should be fixed in that branch by the "sub-community"
>>> that has formed around the branch. If things are not getting fixed, to me
>>> that means the branch has not attracted enough of a user and contributor
>>> community. I don't know how to fix that problem...
>>>
>>
>> It is true that most of the bugs discovered in R4 are fixed as they come
>> up. I was thinking more along the line of the kinds of things that were
>> corrected by refactorings and such.
>>
>> I've run across a number of people using R4 and service providers who are
>> using R4 for their customer's deployments. In addition, Opentaps is based on
>> R4. So, there is a sizeable R4 community out there, even if they aren't
>> vocal on the mailing lists and such.
>>
>> I guess the goal or purpose of a Release 5 would be the same as Release 4
>> - to provide the opportunity to build on a target that isn't moving.
>>
>> I agree that there needs to be a community of people who want it and are
>> willing to support it. I was just tossing the idea out there, but at this
>> point in time there doesn't seem to be much interest.
>>
>
> These are good points Adrian. Don't let my "Devil's Advocate" approach
> scare you away or make you think there is no interest in doing these. I
> imagine there are many people who would like to see release branches happen.
>
> Part of the reason I wrote some doubts about it is that there is an open
> source mantra of "release early, release often" and I was wondering about
> that... What if we took the opposite approach of "never release"? It's the
> total opposite extreme and I'm not completely sure I like the idea, but it
> has some really interesting points. For example it encourages:
>
> 1. community interaction, even for those who are just "users" and not
> sending things back
> 2. frequent upgrades by all users to resolve issues
> 3. community responsibility, rising the priority of things like automated
> testing, and giving people more reasons to get involved with that testing
> and contribute tests
> 4. base application design decision refinement to help people with regular
> updates and resolving issues while not creating new ones
> 5. something the press can write about that is very different from things
> done in other places
> 6. a social experiment in collaborative enterprise software that is yet
> unseen in the world
>
> Of course, there are disadvantages, like:
>
> 1. a smaller user community because the prospect is scary
>
> Maybe that's it. I really think that if as a community we work more on
> automated regression tests and such we'll have a higher quality of software
> in the trunk than is in the release branches, partially because of what
> Adrian mentioned (and I alluded to) where certain types of issues require a
> lot of refactoring and aren't simple fixes that can go into a release
> branch.
>
> Anyway, something to think about. In a way doing release branches breaks
> important aspects of the "never release" approach because things like #1, #2
> and certain of the others won't happen, or won't happen as much. Actually,
> it applies to more, maybe especially #3. If we never release, developers
> have no excuse of making things unstable, or committing without thinking
> about things, or throwing stuff out for they are designed well. There is no
> excuse of "if people want something stable, use the release branch, and
> leave us alone!"
>
> I'm still for doing another release branch early next year (and continuing
> with 18-24 months between branches), unless a lot of people find the "never
> release" philosophy interesting.
>
> -David
>
>
>

[Jacques Le Roux]

I second Adrian request. Even if I know from release 4.0 experience that few persons are effectively supporting releases when a lot
more are using it.

Jacques

From: "Adrian Crum" <[hidden email]>

> David E Jones wrote:
>>> I don't mean to dilute the framework release effort. But at the same time, it seems to me issues are coming up in R4 that have
>>> been addressed in the trunk.
>>
>> While to some extent this depends on the type of issue, in general issues in the 4.0.0 branch should be fixed in that branch by
>> the "sub-community" that has formed around the branch. If things are not getting fixed, to me that means the branch has not
>> attracted enough of a user and contributor community. I don't know how to fix that problem...
>
> It is true that most of the bugs discovered in R4 are fixed as they come up. I was thinking more along the line of the kinds of
> things that were corrected by refactorings and such.
>
> I've run across a number of people using R4 and service providers who are using R4 for their customer's deployments. In addition,
> Opentaps is based on R4. So, there is a sizeable R4 community out there, even if they aren't vocal on the mailing lists and such.
>
> I guess the goal or purpose of a Release 5 would be the same as Release 4 - to provide the opportunity to build on a target that
> isn't moving.
>
> I agree that there needs to be a community of people who want it and are willing to support it. I was just tossing the idea out
> there, but at this point in time there doesn't seem to be much interest.
>
> -Adrian
>

[David E Jones-3]

Check out the "Release Plan" document on docs.ofbiz.org...

-David


On Nov 15, 2008, at 1:58 AM, Bruno Busco wrote:

> What about using a "release candidate branch" in place of a "release  
> branch"
> ?
>
> With this I mean:
>
> 1) the release candidate branch could be started at any time (even  
> from the
> trunk as it is right now)
>
> 2) the actually open JIRAs should be selected and the "fix version"  
> field
> should be changed to the new scheduled release candidate for what the
> community agrees to be included in the release (even some new  
> features).
> This gives a clear idea to all the community of what needs to be  
> done to get
> the release done. And I guess all the active community will try to  
> have them
> done with a high priority. (The answer to the question "When will we  
> have
> the new release?" will be "When we will have all the scheduled issues
> closed. Please give them a look and attach a (tested) patch."
>
> 3) when all the JIRAs scheduled on the release candidate are closed  
> the
> release can be done, a tag is created and the release (maintenance)  
> branch
> is started where only bug fix are committed.
>
> 4) in addition to this I would create a tag from the release  
> maintenance
> branch whenever a reasonable amount of fixes are done.
>
> I think this approach is very standard, no extra efforts are  
> requested that
> we cannot do and gives a clear idea to everybody of where we are.
>
> -Bruno
>
> 2008/11/14 David E Jones <[hidden email]>
>
>>
>> On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
>>
>> David E Jones wrote:
>>>
>>>> I don't mean to dilute the framework release effort. But at the  
>>>> same
>>>>> time, it seems to me issues are coming up in R4 that have been  
>>>>> addressed in
>>>>> the trunk.
>>>>>
>>>> While to some extent this depends on the type of issue, in  
>>>> general issues
>>>> in the 4.0.0 branch should be fixed in that branch by the "sub-
>>>> community"
>>>> that has formed around the branch. If things are not getting  
>>>> fixed, to me
>>>> that means the branch has not attracted enough of a user and  
>>>> contributor
>>>> community. I don't know how to fix that problem...
>>>>
>>>
>>> It is true that most of the bugs discovered in R4 are fixed as  
>>> they come
>>> up. I was thinking more along the line of the kinds of things that  
>>> were
>>> corrected by refactorings and such.
>>>
>>> I've run across a number of people using R4 and service providers  
>>> who are
>>> using R4 for their customer's deployments. In addition, Opentaps  
>>> is based on
>>> R4. So, there is a sizeable R4 community out there, even if they  
>>> aren't
>>> vocal on the mailing lists and such.
>>>
>>> I guess the goal or purpose of a Release 5 would be the same as  
>>> Release 4
>>> - to provide the opportunity to build on a target that isn't moving.
>>>
>>> I agree that there needs to be a community of people who want it  
>>> and are
>>> willing to support it. I was just tossing the idea out there, but  
>>> at this
>>> point in time there doesn't seem to be much interest.
>>>
>>
>> These are good points Adrian. Don't let my "Devil's Advocate"  
>> approach
>> scare you away or make you think there is no interest in doing  
>> these. I
>> imagine there are many people who would like to see release  
>> branches happen.
>>
>> Part of the reason I wrote some doubts about it is that there is an  
>> open
>> source mantra of "release early, release often" and I was wondering  
>> about
>> that... What if we took the opposite approach of "never release"?  
>> It's the
>> total opposite extreme and I'm not completely sure I like the idea,  
>> but it
>> has some really interesting points. For example it encourages:
>>
>> 1. community interaction, even for those who are just "users" and not
>> sending things back
>> 2. frequent upgrades by all users to resolve issues
>> 3. community responsibility, rising the priority of things like  
>> automated
>> testing, and giving people more reasons to get involved with that  
>> testing
>> and contribute tests
>> 4. base application design decision refinement to help people with  
>> regular
>> updates and resolving issues while not creating new ones
>> 5. something the press can write about that is very different from  
>> things
>> done in other places
>> 6. a social experiment in collaborative enterprise software that is  
>> yet
>> unseen in the world
>>
>> Of course, there are disadvantages, like:
>>
>> 1. a smaller user community because the prospect is scary
>>
>> Maybe that's it. I really think that if as a community we work more  
>> on
>> automated regression tests and such we'll have a higher quality of  
>> software
>> in the trunk than is in the release branches, partially because of  
>> what
>> Adrian mentioned (and I alluded to) where certain types of issues  
>> require a
>> lot of refactoring and aren't simple fixes that can go into a release
>> branch.
>>
>> Anyway, something to think about. In a way doing release branches  
>> breaks
>> important aspects of the "never release" approach because things  
>> like #1, #2
>> and certain of the others won't happen, or won't happen as much.  
>> Actually,
>> it applies to more, maybe especially #3. If we never release,  
>> developers
>> have no excuse of making things unstable, or committing without  
>> thinking
>> about things, or throwing stuff out for they are designed well.  
>> There is no
>> excuse of "if people want something stable, use the release branch,  
>> and
>> leave us alone!"
>>
>> I'm still for doing another release branch early next year (and  
>> continuing
>> with 18-24 months between branches), unless a lot of people find  
>> the "never
>> release" philosophy interesting.
>>
>> -David
>>
>>
>>

[Bruno Busco]

David,
I have read the "Release Plan" but it is hard for me to find a match to what
I see on the SVN.
In particular I do not see those key policies actuated:

   - An initial pre-built package will be created and made available to help
   get people started with the branch
   - Once a release branch stabilizes an initial "stable" release tag and
   pre-built package will be issued

Where are "pre-built packages" ?
I am sorry but I must say that the "Release Plan" seems to me 1) not
actuated and 2) not as standard as a "release candidate" would be.

My two cents,
- Bruno


2008/11/15 David E Jones <[hidden email]>

>
> Check out the "Release Plan" document on docs.ofbiz.org...
>
> -David
>
>
>
> On Nov 15, 2008, at 1:58 AM, Bruno Busco wrote:
>
>  What about using a "release candidate branch" in place of a "release
>> branch"
>> ?
>>
>> With this I mean:
>>
>> 1) the release candidate branch could be started at any time (even from
>> the
>> trunk as it is right now)
>>
>> 2) the actually open JIRAs should be selected and the "fix version" field
>> should be changed to the new scheduled release candidate for what the
>> community agrees to be included in the release (even some new features).
>> This gives a clear idea to all the community of what needs to be done to
>> get
>> the release done. And I guess all the active community will try to have
>> them
>> done with a high priority. (The answer to the question "When will we have
>> the new release?" will be "When we will have all the scheduled issues
>> closed. Please give them a look and attach a (tested) patch."
>>
>> 3) when all the JIRAs scheduled on the release candidate are closed the
>> release can be done, a tag is created and the release (maintenance) branch
>> is started where only bug fix are committed.
>>
>> 4) in addition to this I would create a tag from the release maintenance
>> branch whenever a reasonable amount of fixes are done.
>>
>> I think this approach is very standard, no extra efforts are requested
>> that
>> we cannot do and gives a clear idea to everybody of where we are.
>>
>> -Bruno
>>
>> 2008/11/14 David E Jones <[hidden email]>
>>
>>
>>> On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
>>>
>>> David E Jones wrote:
>>>
>>>>
>>>>  I don't mean to dilute the framework release effort. But at the same
>>>>>
>>>>>> time, it seems to me issues are coming up in R4 that have been
>>>>>> addressed in
>>>>>> the trunk.
>>>>>>
>>>>>>  While to some extent this depends on the type of issue, in general
>>>>> issues
>>>>> in the 4.0.0 branch should be fixed in that branch by the
>>>>> "sub-community"
>>>>> that has formed around the branch. If things are not getting fixed, to
>>>>> me
>>>>> that means the branch has not attracted enough of a user and
>>>>> contributor
>>>>> community. I don't know how to fix that problem...
>>>>>
>>>>>
>>>> It is true that most of the bugs discovered in R4 are fixed as they come
>>>> up. I was thinking more along the line of the kinds of things that were
>>>> corrected by refactorings and such.
>>>>
>>>> I've run across a number of people using R4 and service providers who
>>>> are
>>>> using R4 for their customer's deployments. In addition, Opentaps is
>>>> based on
>>>> R4. So, there is a sizeable R4 community out there, even if they aren't
>>>> vocal on the mailing lists and such.
>>>>
>>>> I guess the goal or purpose of a Release 5 would be the same as Release
>>>> 4
>>>> - to provide the opportunity to build on a target that isn't moving.
>>>>
>>>> I agree that there needs to be a community of people who want it and are
>>>> willing to support it. I was just tossing the idea out there, but at
>>>> this
>>>> point in time there doesn't seem to be much interest.
>>>>
>>>>
>>> These are good points Adrian. Don't let my "Devil's Advocate" approach
>>> scare you away or make you think there is no interest in doing these. I
>>> imagine there are many people who would like to see release branches
>>> happen.
>>>
>>> Part of the reason I wrote some doubts about it is that there is an open
>>> source mantra of "release early, release often" and I was wondering about
>>> that... What if we took the opposite approach of "never release"? It's
>>> the
>>> total opposite extreme and I'm not completely sure I like the idea, but
>>> it
>>> has some really interesting points. For example it encourages:
>>>
>>> 1. community interaction, even for those who are just "users" and not
>>> sending things back
>>> 2. frequent upgrades by all users to resolve issues
>>> 3. community responsibility, rising the priority of things like automated
>>> testing, and giving people more reasons to get involved with that testing
>>> and contribute tests
>>> 4. base application design decision refinement to help people with
>>> regular
>>> updates and resolving issues while not creating new ones
>>> 5. something the press can write about that is very different from things
>>> done in other places
>>> 6. a social experiment in collaborative enterprise software that is yet
>>> unseen in the world
>>>
>>> Of course, there are disadvantages, like:
>>>
>>> 1. a smaller user community because the prospect is scary
>>>
>>> Maybe that's it. I really think that if as a community we work more on
>>> automated regression tests and such we'll have a higher quality of
>>> software
>>> in the trunk than is in the release branches, partially because of what
>>> Adrian mentioned (and I alluded to) where certain types of issues require
>>> a
>>> lot of refactoring and aren't simple fixes that can go into a release
>>> branch.
>>>
>>> Anyway, something to think about. In a way doing release branches breaks
>>> important aspects of the "never release" approach because things like #1,
>>> #2
>>> and certain of the others won't happen, or won't happen as much.
>>> Actually,
>>> it applies to more, maybe especially #3. If we never release, developers
>>> have no excuse of making things unstable, or committing without thinking
>>> about things, or throwing stuff out for they are designed well. There is
>>> no
>>> excuse of "if people want something stable, use the release branch, and
>>> leave us alone!"
>>>
>>> I'm still for doing another release branch early next year (and
>>> continuing
>>> with 18-24 months between branches), unless a lot of people find the
>>> "never
>>> release" philosophy interesting.
>>>
>>> -David
>>>
>>>
>>>
>>>
>

[David E Jones-3]

It's just a plan... if no one cares enough about particular parts of  
it do actually do them, that's another issue altogether.

There are pre-built packages with the nightly builds.

However, it is true that no "stable" tag has been created, ie no one  
or group has defined "stable" or done testing according to the  
definition to declare that a certain revision of the branch is "stable".

On the other hand, I think those using it consider it at this point to  
be pretty "stable", though there are known issues, such as with Double  
versus BigDecimal, and with Minerva as the transaction manager.

-David


On Nov 15, 2008, at 4:21 AM, Bruno Busco wrote:

> David,
> I have read the "Release Plan" but it is hard for me to find a match  
> to what
> I see on the SVN.
> In particular I do not see those key policies actuated:
>
>   - An initial pre-built package will be created and made available  
> to help
>   get people started with the branch
>   - Once a release branch stabilizes an initial "stable" release tag  
> and
>   pre-built package will be issued
>
> Where are "pre-built packages" ?
> I am sorry but I must say that the "Release Plan" seems to me 1) not
> actuated and 2) not as standard as a "release candidate" would be.
>
> My two cents,
> - Bruno
>
>
> 2008/11/15 David E Jones <[hidden email]>
>
>>
>> Check out the "Release Plan" document on docs.ofbiz.org...
>>
>> -David
>>
>>
>>
>> On Nov 15, 2008, at 1:58 AM, Bruno Busco wrote:
>>
>> What about using a "release candidate branch" in place of a "release
>>> branch"
>>> ?
>>>
>>> With this I mean:
>>>
>>> 1) the release candidate branch could be started at any time (even  
>>> from
>>> the
>>> trunk as it is right now)
>>>
>>> 2) the actually open JIRAs should be selected and the "fix  
>>> version" field
>>> should be changed to the new scheduled release candidate for what  
>>> the
>>> community agrees to be included in the release (even some new  
>>> features).
>>> This gives a clear idea to all the community of what needs to be  
>>> done to
>>> get
>>> the release done. And I guess all the active community will try to  
>>> have
>>> them
>>> done with a high priority. (The answer to the question "When will  
>>> we have
>>> the new release?" will be "When we will have all the scheduled  
>>> issues
>>> closed. Please give them a look and attach a (tested) patch."
>>>
>>> 3) when all the JIRAs scheduled on the release candidate are  
>>> closed the
>>> release can be done, a tag is created and the release  
>>> (maintenance) branch
>>> is started where only bug fix are committed.
>>>
>>> 4) in addition to this I would create a tag from the release  
>>> maintenance
>>> branch whenever a reasonable amount of fixes are done.
>>>
>>> I think this approach is very standard, no extra efforts are  
>>> requested
>>> that
>>> we cannot do and gives a clear idea to everybody of where we are.
>>>
>>> -Bruno
>>>
>>> 2008/11/14 David E Jones <[hidden email]>
>>>
>>>
>>>> On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
>>>>
>>>> David E Jones wrote:
>>>>
>>>>>
>>>>> I don't mean to dilute the framework release effort. But at the  
>>>>> same
>>>>>>
>>>>>>> time, it seems to me issues are coming up in R4 that have been
>>>>>>> addressed in
>>>>>>> the trunk.
>>>>>>>
>>>>>>> While to some extent this depends on the type of issue, in  
>>>>>>> general
>>>>>> issues
>>>>>> in the 4.0.0 branch should be fixed in that branch by the
>>>>>> "sub-community"
>>>>>> that has formed around the branch. If things are not getting  
>>>>>> fixed, to
>>>>>> me
>>>>>> that means the branch has not attracted enough of a user and
>>>>>> contributor
>>>>>> community. I don't know how to fix that problem...
>>>>>>
>>>>>>
>>>>> It is true that most of the bugs discovered in R4 are fixed as  
>>>>> they come
>>>>> up. I was thinking more along the line of the kinds of things  
>>>>> that were
>>>>> corrected by refactorings and such.
>>>>>
>>>>> I've run across a number of people using R4 and service  
>>>>> providers who
>>>>> are
>>>>> using R4 for their customer's deployments. In addition, Opentaps  
>>>>> is
>>>>> based on
>>>>> R4. So, there is a sizeable R4 community out there, even if they  
>>>>> aren't
>>>>> vocal on the mailing lists and such.
>>>>>
>>>>> I guess the goal or purpose of a Release 5 would be the same as  
>>>>> Release
>>>>> 4
>>>>> - to provide the opportunity to build on a target that isn't  
>>>>> moving.
>>>>>
>>>>> I agree that there needs to be a community of people who want it  
>>>>> and are
>>>>> willing to support it. I was just tossing the idea out there,  
>>>>> but at
>>>>> this
>>>>> point in time there doesn't seem to be much interest.
>>>>>
>>>>>
>>>> These are good points Adrian. Don't let my "Devil's Advocate"  
>>>> approach
>>>> scare you away or make you think there is no interest in doing  
>>>> these. I
>>>> imagine there are many people who would like to see release  
>>>> branches
>>>> happen.
>>>>
>>>> Part of the reason I wrote some doubts about it is that there is  
>>>> an open
>>>> source mantra of "release early, release often" and I was  
>>>> wondering about
>>>> that... What if we took the opposite approach of "never release"?  
>>>> It's
>>>> the
>>>> total opposite extreme and I'm not completely sure I like the  
>>>> idea, but
>>>> it
>>>> has some really interesting points. For example it encourages:
>>>>
>>>> 1. community interaction, even for those who are just "users" and  
>>>> not
>>>> sending things back
>>>> 2. frequent upgrades by all users to resolve issues
>>>> 3. community responsibility, rising the priority of things like  
>>>> automated
>>>> testing, and giving people more reasons to get involved with that  
>>>> testing
>>>> and contribute tests
>>>> 4. base application design decision refinement to help people with
>>>> regular
>>>> updates and resolving issues while not creating new ones
>>>> 5. something the press can write about that is very different  
>>>> from things
>>>> done in other places
>>>> 6. a social experiment in collaborative enterprise software that  
>>>> is yet
>>>> unseen in the world
>>>>
>>>> Of course, there are disadvantages, like:
>>>>
>>>> 1. a smaller user community because the prospect is scary
>>>>
>>>> Maybe that's it. I really think that if as a community we work  
>>>> more on
>>>> automated regression tests and such we'll have a higher quality of
>>>> software
>>>> in the trunk than is in the release branches, partially because  
>>>> of what
>>>> Adrian mentioned (and I alluded to) where certain types of issues  
>>>> require
>>>> a
>>>> lot of refactoring and aren't simple fixes that can go into a  
>>>> release
>>>> branch.
>>>>
>>>> Anyway, something to think about. In a way doing release branches  
>>>> breaks
>>>> important aspects of the "never release" approach because things  
>>>> like #1,
>>>> #2
>>>> and certain of the others won't happen, or won't happen as much.
>>>> Actually,
>>>> it applies to more, maybe especially #3. If we never release,  
>>>> developers
>>>> have no excuse of making things unstable, or committing without  
>>>> thinking
>>>> about things, or throwing stuff out for they are designed well.  
>>>> There is
>>>> no
>>>> excuse of "if people want something stable, use the release  
>>>> branch, and
>>>> leave us alone!"
>>>>
>>>> I'm still for doing another release branch early next year (and
>>>> continuing
>>>> with 18-24 months between branches), unless a lot of people find  
>>>> the
>>>> "never
>>>> release" philosophy interesting.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>
>>

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> I've run across a number of people using R4 and service providers who are using R4 for their customer's deployments. In addition,
> Opentaps is based on R4. So, there is a sizeable R4 community out there, even if they aren't vocal on the mailing lists and such.

Looking at Opentaps backpatches.txt it seems that Opentaps is not using R4 as is but picks patches not necessarily coming from R4
(but I'm not sure how to understand this file).

For instance I did not backport 690644 (automatic merging issue, done by hand tosay in r714229) but in Opentaps they did. Maybe
there are more, I wil have a look (just found 618970 also). It's a pity they did not said that to us (ok it's also our fault not
their).

Jacques

[David E Jones-3]

On Nov 15, 2008, at 5:12 AM, Jacques Le Roux wrote:

> From: "Adrian Crum" <[hidden email]>
>> I've run across a number of people using R4 and service providers  
>> who are using R4 for their customer's deployments. In addition,  
>> Opentaps is based on R4. So, there is a sizeable R4 community out  
>> there, even if they aren't vocal on the mailing lists and such.
>
> Looking at Opentaps backpatches.txt it seems that Opentaps is not  
> using R4 as is but picks patches not necessarily coming from R4
> (but I'm not sure how to understand this file).
>
> For instance I did not backport 690644 (automatic merging issue,  
> done by hand tosay in r714229) but in Opentaps they did. Maybe there  
> are more, I wil have a look (just found 618970 also). It's a pity  
> they did not said that to us (ok it's also our fault not their).

OFBiz in general, and release branches as well, are maintained by the  
people who use them.

It's a shame that opentaps has chosen to use the release4 branch but  
not help maintain for the benefit of others. I guess that would  
conflict with their intent to get people to use opentaps _instead of_  
OFBiz.

-David

[Joe Eckard]

On Nov 14, 2008, at 3:41 PM, David E Jones wrote:

>
> On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>>> I don't mean to dilute the framework release effort. But at the  
>>>> same time, it seems to me issues are coming up in R4 that have  
>>>> been addressed in the trunk.
>>> While to some extent this depends on the type of issue, in general  
>>> issues in the 4.0.0 branch should be fixed in that branch by the  
>>> "sub-community" that has formed around the branch. If things are  
>>> not getting fixed, to me that means the branch has not attracted  
>>> enough of a user and contributor community. I don't know how to  
>>> fix that problem...
>>
>> It is true that most of the bugs discovered in R4 are fixed as they  
>> come up. I was thinking more along the line of the kinds of things  
>> that were corrected by refactorings and such.
>>
>> I've run across a number of people using R4 and service providers  
>> who are using R4 for their customer's deployments. In addition,  
>> Opentaps is based on R4. So, there is a sizeable R4 community out  
>> there, even if they aren't vocal on the mailing lists and such.
>>
>> I guess the goal or purpose of a Release 5 would be the same as  
>> Release 4 - to provide the opportunity to build on a target that  
>> isn't moving.
>>
>> I agree that there needs to be a community of people who want it  
>> and are willing to support it. I was just tossing the idea out  
>> there, but at this point in time there doesn't seem to be much  
>> interest.
>
> These are good points Adrian. Don't let my "Devil's Advocate"  
> approach scare you away or make you think there is no interest in  
> doing these. I imagine there are many people who would like to see  
> release branches happen.
>
> Part of the reason I wrote some doubts about it is that there is an  
> open source mantra of "release early, release often" and I was  
> wondering about that... What if we took the opposite approach of  
> "never release"? It's the total opposite extreme and I'm not  
> completely sure I like the idea, but it has some really interesting  
> points. For example it encourages:
>
> 1. community interaction, even for those who are just "users" and  
> not sending things back
> 2. frequent upgrades by all users to resolve issues
> 3. community responsibility, rising the priority of things like  
> automated testing, and giving people more reasons to get involved  
> with that testing and contribute tests
> 4. base application design decision refinement to help people with  
> regular updates and resolving issues while not creating new ones
> 5. something the press can write about that is very different from  
> things done in other places
> 6. a social experiment in collaborative enterprise software that is  
> yet unseen in the world
>
> Of course, there are disadvantages, like:
>
> 1. a smaller user community because the prospect is scary
>
> Maybe that's it. I really think that if as a community we work more  
> on automated regression tests and such we'll have a higher quality  
> of software in the trunk than is in the release branches, partially  
> because of what Adrian mentioned (and I alluded to) where certain  
> types of issues require a lot of refactoring and aren't simple fixes  
> that can go into a release branch.
>
> Anyway, something to think about. In a way doing release branches  
> breaks important aspects of the "never release" approach because  
> things like #1, #2 and certain of the others won't happen, or won't  
> happen as much. Actually, it applies to more, maybe especially #3.  
> If we never release, developers have no excuse of making things  
> unstable, or committing without thinking about things, or throwing  
> stuff out for they are designed well. There is no excuse of "if  
> people want something stable, use the release branch, and leave us  
> alone!"
>
> I'm still for doing another release branch early next year (and  
> continuing with 18-24 months between branches), unless a lot of  
> people find the "never release" philosophy interesting.
>
> -David
>

(disclaimer: one guy's opinion, grain of salt, etc.)

Speaking primarily as an end user, the "never release" approach that  
the project is currently taking encourages me to isolate my code as  
much as possible, and discourages frequent upgrades. It also  
encourages me to cherry-pick bug fixes, which can make it tedious to  
construct patches to send back when I find new bugs.

Sometimes I like to imagine a world where OFBiz has major, minor and  
point releases (with release notes) similar to what is described at http://commons.apache.org/releases/versioning.html 
  (with the compatibility types redefined in OFBiz terms). For  
example, any change that modifies a service's signature, or the data  
model might require a new point release to include any outstanding bug  
fixes, then a new minor release with a simple upgrade instruction for  
that change added to the release notes. (in other words,  
incompatibility would be the determining factor for minor & major  
revision number upgrades)

With something like that in place, I could feel confident upgrading  
from a theoretical version 4.0.19 to 4.0.23, knowing that nothing  
should break, and I don't need to install new seed data or worry about  
data model changes. If I wanted some new features in 4.1.x, I would  
need to check the release notes to see what incompatible change  
prompted the version increase and make adjustments and an upgrade plan.

Maybe this approach just isn't feasible for any number of reasons, but  
I have always wondered why there doesn't seem to be any discussion of  
something similar whenever the topic of releases are brought up.


-Joe

[Jacques Le Roux]

From: "Joe Eckard" <[hidden email]>

>
> On Nov 14, 2008, at 3:41 PM, David E Jones wrote:
>
>>
>> On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
>>
>>> David E Jones wrote:
>>>>> I don't mean to dilute the framework release effort. But at the  same time, it seems to me issues are coming up in R4 that
>>>>> have  been addressed in the trunk.
>>>> While to some extent this depends on the type of issue, in general  issues in the 4.0.0 branch should be fixed in that branch
>>>> by the  "sub-community" that has formed around the branch. If things are  not getting fixed, to me that means the branch has
>>>> not attracted  enough of a user and contributor community. I don't know how to  fix that problem...
>>>
>>> It is true that most of the bugs discovered in R4 are fixed as they  come up. I was thinking more along the line of the kinds of
>>> things  that were corrected by refactorings and such.
>>>
>>> I've run across a number of people using R4 and service providers  who are using R4 for their customer's deployments. In
>>> addition,  Opentaps is based on R4. So, there is a sizeable R4 community out  there, even if they aren't vocal on the mailing
>>> lists and such.
>>>
>>> I guess the goal or purpose of a Release 5 would be the same as  Release 4 - to provide the opportunity to build on a target
>>> that  isn't moving.
>>>
>>> I agree that there needs to be a community of people who want it  and are willing to support it. I was just tossing the idea out
>>> there, but at this point in time there doesn't seem to be much  interest.
>>
>> These are good points Adrian. Don't let my "Devil's Advocate"  approach scare you away or make you think there is no interest in
>> doing these. I imagine there are many people who would like to see  release branches happen.
>>
>> Part of the reason I wrote some doubts about it is that there is an  open source mantra of "release early, release often" and I
>> was  wondering about that... What if we took the opposite approach of  "never release"? It's the total opposite extreme and I'm
>> not  completely sure I like the idea, but it has some really interesting  points. For example it encourages:
>>
>> 1. community interaction, even for those who are just "users" and  not sending things back
>> 2. frequent upgrades by all users to resolve issues
>> 3. community responsibility, rising the priority of things like  automated testing, and giving people more reasons to get
>> involved  with that testing and contribute tests
>> 4. base application design decision refinement to help people with  regular updates and resolving issues while not creating new
>> ones
>> 5. something the press can write about that is very different from  things done in other places
>> 6. a social experiment in collaborative enterprise software that is  yet unseen in the world
>>
>> Of course, there are disadvantages, like:
>>
>> 1. a smaller user community because the prospect is scary
>>
>> Maybe that's it. I really think that if as a community we work more  on automated regression tests and such we'll have a higher
>> quality  of software in the trunk than is in the release branches, partially  because of what Adrian mentioned (and I alluded to)
>> where certain  types of issues require a lot of refactoring and aren't simple fixes  that can go into a release branch.
>>
>> Anyway, something to think about. In a way doing release branches  breaks important aspects of the "never release" approach
>> because  things like #1, #2 and certain of the others won't happen, or won't  happen as much. Actually, it applies to more, maybe
>> especially #3.  If we never release, developers have no excuse of making things  unstable, or committing without thinking about
>> things, or throwing  stuff out for they are designed well. There is no excuse of "if  people want something stable, use the
>> release branch, and leave us  alone!"
>>
>> I'm still for doing another release branch early next year (and  continuing with 18-24 months between branches), unless a lot of
>> people find the "never release" philosophy interesting.
>>
>> -David
>>
>
> (disclaimer: one guy's opinion, grain of salt, etc.)
>
> Speaking primarily as an end user, the "never release" approach that  the project is currently taking encourages me to isolate my
> code as  much as possible, and discourages frequent upgrades. It also  encourages me to cherry-pick bug fixes, which can make it
> tedious to  construct patches to send back when I find new bugs.
>
> Sometimes I like to imagine a world where OFBiz has major, minor and  point releases (with release notes) similar to what is
> described at http://commons.apache.org/releases/versioning.html (with the compatibility types redefined in OFBiz terms). For
> example, any change that modifies a service's signature, or the data  model might require a new point release to include any
> outstanding bug  fixes, then a new minor release with a simple upgrade instruction for  that change added to the release notes.
> (in other words,  incompatibility would be the determining factor for minor & major  revision number upgrades)
>
> With something like that in place, I could feel confident upgrading  from a theoretical version 4.0.19 to 4.0.23, knowing that
> nothing  should break, and I don't need to install new seed data or worry about  data model changes. If I wanted some new features
> in 4.1.x, I would  need to check the release notes to see what incompatible change  prompted the version increase and make
> adjustments and an upgrade plan.

I think we would all love to see a such plan working in OFBiz. But there are also drawbacks, it's obviously easier (from a commiter
POV) to have only one version rolling...

> Maybe this approach just isn't feasible for any number of reasons, but  I have always wondered why there doesn't seem to be any
> discussion of  something similar whenever the topic of releases are brought up.
>
> -Joe

Beyond the well known manpower problem, I guess because most of the time there are not much bugs introduced and it's not so hard to
maintain when some slip in.
But of course, when there are major refactorings, bugs are introduced and then it's hard to work (professionnaly) with the trunk,
yes !

Jacques

[Shi Yusen]

+1.

The reason is simple: nobody takes the role of project manager in OFBiz.

When Redhat aquired JBoss, I found almost every project had a new
project manager who really helped the projects released more and more
predictable.

At the beginning as TLP, Jacopo Cappellato looked like preparing the
release version. And when he joined HotwaxMedia, he's missing I guess.

Someone in the PMC should stand out. Jacques Le Roux or Scott Gray?

PMC, programmers meeting committee? If so, it's a quite pitty for an ERP
platform. :)

Kind Regards,

Shi Yusen/Beijing Langhua Ltd.


在 2008-11-15六的 13:46 -0500，Joe Eckard写道：

> On Nov 14, 2008, at 3:41 PM, David E Jones wrote:
>
> >
> > On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
> >
> >> David E Jones wrote:
> >>>> I don't mean to dilute the framework release effort. But at the  
> >>>> same time, it seems to me issues are coming up in R4 that have  
> >>>> been addressed in the trunk.
> >>> While to some extent this depends on the type of issue, in general  
> >>> issues in the 4.0.0 branch should be fixed in that branch by the  
> >>> "sub-community" that has formed around the branch. If things are  
> >>> not getting fixed, to me that means the branch has not attracted  
> >>> enough of a user and contributor community. I don't know how to  
> >>> fix that problem...
> >>
> >> It is true that most of the bugs discovered in R4 are fixed as they  
> >> come up. I was thinking more along the line of the kinds of things  
> >> that were corrected by refactorings and such.
> >>
> >> I've run across a number of people using R4 and service providers  
> >> who are using R4 for their customer's deployments. In addition,  
> >> Opentaps is based on R4. So, there is a sizeable R4 community out  
> >> there, even if they aren't vocal on the mailing lists and such.
> >>
> >> I guess the goal or purpose of a Release 5 would be the same as  
> >> Release 4 - to provide the opportunity to build on a target that  
> >> isn't moving.
> >>
> >> I agree that there needs to be a community of people who want it  
> >> and are willing to support it. I was just tossing the idea out  
> >> there, but at this point in time there doesn't seem to be much  
> >> interest.
> >
> > These are good points Adrian. Don't let my "Devil's Advocate"  
> > approach scare you away or make you think there is no interest in  
> > doing these. I imagine there are many people who would like to see  
> > release branches happen.
> >
> > Part of the reason I wrote some doubts about it is that there is an  
> > open source mantra of "release early, release often" and I was  
> > wondering about that... What if we took the opposite approach of  
> > "never release"? It's the total opposite extreme and I'm not  
> > completely sure I like the idea, but it has some really interesting  
> > points. For example it encourages:
> >
> > 1. community interaction, even for those who are just "users" and  
> > not sending things back
> > 2. frequent upgrades by all users to resolve issues
> > 3. community responsibility, rising the priority of things like  
> > automated testing, and giving people more reasons to get involved  
> > with that testing and contribute tests
> > 4. base application design decision refinement to help people with  
> > regular updates and resolving issues while not creating new ones
> > 5. something the press can write about that is very different from  
> > things done in other places
> > 6. a social experiment in collaborative enterprise software that is  
> > yet unseen in the world
> >
> > Of course, there are disadvantages, like:
> >
> > 1. a smaller user community because the prospect is scary
> >
> > Maybe that's it. I really think that if as a community we work more  
> > on automated regression tests and such we'll have a higher quality  
> > of software in the trunk than is in the release branches, partially  
> > because of what Adrian mentioned (and I alluded to) where certain  
> > types of issues require a lot of refactoring and aren't simple fixes  
> > that can go into a release branch.
> >
> > Anyway, something to think about. In a way doing release branches  
> > breaks important aspects of the "never release" approach because  
> > things like #1, #2 and certain of the others won't happen, or won't  
> > happen as much. Actually, it applies to more, maybe especially #3.  
> > If we never release, developers have no excuse of making things  
> > unstable, or committing without thinking about things, or throwing  
> > stuff out for they are designed well. There is no excuse of "if  
> > people want something stable, use the release branch, and leave us  
> > alone!"
> >
> > I'm still for doing another release branch early next year (and  
> > continuing with 18-24 months between branches), unless a lot of  
> > people find the "never release" philosophy interesting.
> >
> > -David
> >
>
> (disclaimer: one guy's opinion, grain of salt, etc.)
>
> Speaking primarily as an end user, the "never release" approach that  
> the project is currently taking encourages me to isolate my code as  
> much as possible, and discourages frequent upgrades. It also  
> encourages me to cherry-pick bug fixes, which can make it tedious to  
> construct patches to send back when I find new bugs.
>
> Sometimes I like to imagine a world where OFBiz has major, minor and  
> point releases (with release notes) similar to what is described at http://commons.apache.org/releases/versioning.html 
>   (with the compatibility types redefined in OFBiz terms). For  
> example, any change that modifies a service's signature, or the data  
> model might require a new point release to include any outstanding bug  
> fixes, then a new minor release with a simple upgrade instruction for  
> that change added to the release notes. (in other words,  
> incompatibility would be the determining factor for minor & major  
> revision number upgrades)
>
> With something like that in place, I could feel confident upgrading  
> from a theoretical version 4.0.19 to 4.0.23, knowing that nothing  
> should break, and I don't need to install new seed data or worry about  
> data model changes. If I wanted some new features in 4.1.x, I would  
> need to check the release notes to see what incompatible change  
> prompted the version increase and make adjustments and an upgrade plan.
>
> Maybe this approach just isn't feasible for any number of reasons, but  
> I have always wondered why there doesn't seem to be any discussion of  
> something similar whenever the topic of releases are brought up.
>
>
> -Joe

[David E Jones-3]

On Nov 15, 2008, at 3:09 PM, Shi Yusen wrote:

> +1.
>
> The reason is simple: nobody takes the role of project manager in  
> OFBiz.
>
> When Redhat aquired JBoss, I found almost every project had a new
> project manager who really helped the projects released more and more
> predictable.
>
> At the beginning as TLP, Jacopo Cappellato looked like preparing the
> release version. And when he joined HotwaxMedia, he's missing I guess.
>
> Someone in the PMC should stand out. Jacques Le Roux or Scott Gray?
>
> PMC, programmers meeting committee? If so, it's a quite pitty for an  
> ERP
> platform. :)
>
> Kind Regards,
>
> Shi Yusen/Beijing Langhua Ltd.

OFBiz is not commercial software with paid developers. JBoss may be  
available under an open source license, but it is developed under a  
commercial model, not a community-driven model like OFBiz.

In the case of a community-driven software project, what would a  
project manager do? Who would he/she boss around? Who would be  
accountable for delivery and how would that accountability be enforced?

-David

[David E Jones-3]

On Nov 15, 2008, at 4:27 PM, David E Jones wrote:

>
> On Nov 15, 2008, at 3:09 PM, Shi Yusen wrote:
>
>> +1.
>>
>> The reason is simple: nobody takes the role of project manager in  
>> OFBiz.
>>
>> When Redhat aquired JBoss, I found almost every project had a new
>> project manager who really helped the projects released more and more
>> predictable.
>>
>> At the beginning as TLP, Jacopo Cappellato looked like preparing the
>> release version. And when he joined HotwaxMedia, he's missing I  
>> guess.
>>
>> Someone in the PMC should stand out. Jacques Le Roux or Scott Gray?
>>
>> PMC, programmers meeting committee? If so, it's a quite pitty for  
>> an ERP
>> platform. :)
>>
>> Kind Regards,
>>
>> Shi Yusen/Beijing Langhua Ltd.
>
> OFBiz is not commercial software with paid developers. JBoss may be  
> available under an open source license, but it is developed under a  
> commercial model, not a community-driven model like OFBiz.
>
> In the case of a community-driven software project, what would a  
> project manager do? Who would he/she boss around? Who would be  
> accountable for delivery and how would that accountability be  
> enforced?

I clicked on "Send" too quickly...

I hope I'm not getting into revisionist history, but my experience  
with community-driven software so far is that if someone does propose  
something and try to recruit others to work on it then it usually  
fails. Generally the champion of the effort has to work on it  
themselves, and keep working on it until others start _using_ it, and  
then they will get involved with improving and extending it. It's just  
that simple.

Personally I know I've left a wake of unfinished projects where I  
tried to recruit others and identify a goal to work towards, like the  
framework improvements and framework-only release (a starting point  
for higher level releases, something easier). As soon as I got  
involved in increased workload, moving, and organizing and preparing  
for ApacheCon and such I stopped working on it... and so did everyone  
else!

With new things I'm trying to push, like adoption of open standards  
and building some requirements and designs that we can base future  
enhancements and extensions of OFBiz on, my plan is to work on them  
personally as much as I can and do so until others join in.

That's how things get done in community-driven projects: by  
leadership. That's how everything in OFBiz has been done. Someone lead  
the way, and others joined in... hundreds of times in the last 7.5  
years on hundreds of parts of OFBiz. There is a big difference between  
leaders and manager, and what self-organizing communities need is  
leadership, not management. That's the meritocracy way.

-David

[David E Jones-3]

On Nov 15, 2008, at 1:46 PM, Joe Eckard wrote:

>
> On Nov 14, 2008, at 3:41 PM, David E Jones wrote:
>
>>
>> On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
>>
>>> David E Jones wrote:
>>>>> I don't mean to dilute the framework release effort. But at the  
>>>>> same time, it seems to me issues are coming up in R4 that have  
>>>>> been addressed in the trunk.
>>>> While to some extent this depends on the type of issue, in  
>>>> general issues in the 4.0.0 branch should be fixed in that branch  
>>>> by the "sub-community" that has formed around the branch. If  
>>>> things are not getting fixed, to me that means the branch has not  
>>>> attracted enough of a user and contributor community. I don't  
>>>> know how to fix that problem...
>>>
>>> It is true that most of the bugs discovered in R4 are fixed as  
>>> they come up. I was thinking more along the line of the kinds of  
>>> things that were corrected by refactorings and such.
>>>
>>> I've run across a number of people using R4 and service providers  
>>> who are using R4 for their customer's deployments. In addition,  
>>> Opentaps is based on R4. So, there is a sizeable R4 community out  
>>> there, even if they aren't vocal on the mailing lists and such.
>>>
>>> I guess the goal or purpose of a Release 5 would be the same as  
>>> Release 4 - to provide the opportunity to build on a target that  
>>> isn't moving.
>>>
>>> I agree that there needs to be a community of people who want it  
>>> and are willing to support it. I was just tossing the idea out  
>>> there, but at this point in time there doesn't seem to be much  
>>> interest.
>>
>> These are good points Adrian. Don't let my "Devil's Advocate"  
>> approach scare you away or make you think there is no interest in  
>> doing these. I imagine there are many people who would like to see  
>> release branches happen.
>>
>> Part of the reason I wrote some doubts about it is that there is an  
>> open source mantra of "release early, release often" and I was  
>> wondering about that... What if we took the opposite approach of  
>> "never release"? It's the total opposite extreme and I'm not  
>> completely sure I like the idea, but it has some really interesting  
>> points. For example it encourages:
>>
>> 1. community interaction, even for those who are just "users" and  
>> not sending things back
>> 2. frequent upgrades by all users to resolve issues
>> 3. community responsibility, rising the priority of things like  
>> automated testing, and giving people more reasons to get involved  
>> with that testing and contribute tests
>> 4. base application design decision refinement to help people with  
>> regular updates and resolving issues while not creating new ones
>> 5. something the press can write about that is very different from  
>> things done in other places
>> 6. a social experiment in collaborative enterprise software that is  
>> yet unseen in the world
>>
>> Of course, there are disadvantages, like:
>>
>> 1. a smaller user community because the prospect is scary
>>
>> Maybe that's it. I really think that if as a community we work more  
>> on automated regression tests and such we'll have a higher quality  
>> of software in the trunk than is in the release branches, partially  
>> because of what Adrian mentioned (and I alluded to) where certain  
>> types of issues require a lot of refactoring and aren't simple  
>> fixes that can go into a release branch.
>>
>> Anyway, something to think about. In a way doing release branches  
>> breaks important aspects of the "never release" approach because  
>> things like #1, #2 and certain of the others won't happen, or won't  
>> happen as much. Actually, it applies to more, maybe especially #3.  
>> If we never release, developers have no excuse of making things  
>> unstable, or committing without thinking about things, or throwing  
>> stuff out for they are designed well. There is no excuse of "if  
>> people want something stable, use the release branch, and leave us  
>> alone!"
>>
>> I'm still for doing another release branch early next year (and  
>> continuing with 18-24 months between branches), unless a lot of  
>> people find the "never release" philosophy interesting.
>>
>> -David
>>
>
> (disclaimer: one guy's opinion, grain of salt, etc.)
>
> Speaking primarily as an end user, the "never release" approach that  
> the project is currently taking encourages me to isolate my code as  
> much as possible, and discourages frequent upgrades. It also  
> encourages me to cherry-pick bug fixes, which can make it tedious to  
> construct patches to send back when I find new bugs.
>
> Sometimes I like to imagine a world where OFBiz has major, minor and  
> point releases (with release notes) similar to what is described at http://commons.apache.org/releases/versioning.html 
>  (with the compatibility types redefined in OFBiz terms). For  
> example, any change that modifies a service's signature, or the data  
> model might require a new point release to include any outstanding  
> bug fixes, then a new minor release with a simple upgrade  
> instruction for that change added to the release notes. (in other  
> words, incompatibility would be the determining factor for minor &  
> major revision number upgrades)
>
> With something like that in place, I could feel confident upgrading  
> from a theoretical version 4.0.19 to 4.0.23, knowing that nothing  
> should break, and I don't need to install new seed data or worry  
> about data model changes. If I wanted some new features in 4.1.x, I  
> would need to check the release notes to see what incompatible  
> change prompted the version increase and make adjustments and an  
> upgrade plan.
>
> Maybe this approach just isn't feasible for any number of reasons,  
> but I have always wondered why there doesn't seem to be any  
> discussion of something similar whenever the topic of releases are  
> brought up.

Again just testing the idea, and not saying we should adopt it...

How would you behave if you knew there was NEVER going to be a  
release, just ongoing community responsibility?

What would your involvement with the project look like? How would you  
run your efforts that are separate from  the project?

-David