You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <da...@hotwaxmedia.com> on 2008/11/12 17:59:26 UTC
My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ad...@hlmksw.com>
> 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
>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
On Nov 15, 2008, at 5:12 AM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@hlmksw.com>
>> 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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@hlmksw.com>
> 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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
On Nov 17, 2008, at 2:14 PM, Shi Yusen wrote:
>
> 在 2008-11-17一的 12:06 -0500，Joe Eckard写道：
>
>> Speaking to Shi Yusen's comment about a project / release manager, I
>> don't think it would be fair to push this onto any one person when
>> the
>> individual committers have all of the information available when they
>> make a commit. (Will the change break existing code, does the change
>> add a new feature that requires new seed data or a data model change,
>> etc.)
>
> I complained to David because he's the V.P. of Apache. He has to
> listen,
> has he? :)
>
> Everybody has the responsibility, nobody really has.
>
> Everybody maintains his own OFBiz, nobody cares about the common one.
> This makes me uneasy.
>
> Admire David mentioned the framework-only release plan, hope this come
> true soon. Personally, OFBiz = the framework, I don't have to care
> about
> the qualities of the add-ons if I won't use.
Would it be correct for me to say that you're really looking for
commercially developed software that you can get for free, and not for
community-driven software that you can participate in?
-David
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main
Theme: Organizing Ourselves
Posted by Shi Yusen <sh...@langhua.cn>.
在 2008-11-17一的 12:06 -0500，Joe Eckard写道：
> Speaking to Shi Yusen's comment about a project / release manager, I
> don't think it would be fair to push this onto any one person when the
> individual committers have all of the information available when they
> make a commit. (Will the change break existing code, does the change
> add a new feature that requires new seed data or a data model change,
> etc.)
I complained to David because he's the V.P. of Apache. He has to listen,
has he? :)
Everybody has the responsibility, nobody really has.
Everybody maintains his own OFBiz, nobody cares about the common one.
This makes me uneasy.
Admire David mentioned the framework-only release plan, hope this come
true soon. Personally, OFBiz = the framework, I don't have to care about
the qualities of the add-ons if I won't use.
Regards,
Shi Yusen/Beijing Langhua Ltd.
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
On Nov 17, 2008, at 12:06 PM, Joe Eckard wrote:
>
> On Nov 15, 2008, at 4:37 PM, David E Jones wrote:
>
>>> (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
>
> For me personally, nothing would really change... i.e. when a custom
> application is considered feature-complete and relatively stable and
> bug-free, then all OFBiz updates stop, and my involvement with the
> current trunk comes to an end (for that project). There are
> exceptions - when I encounter a bug I'll check the trunk first to
> see if it has been fixed, or when I am catching up on messages to
> the commits list I may notice an important bug fix that needs to be
> back-ported right away.
>
> This is unfortunate, because it can put me in the same position as
> Markus - improvements and fixes may need to be completely rewritten
> and re-tested before I can create patches for the current trunk.
> (This is the case for me right now - my main codebase is pre-4.0 and
> I have a few changes that I haven't had the time to rewrite and re-
> test.)
>
> Even if there were more testing in place, the main drawback to
> staying current is that with each update I may be taking on new
> features or applications that my business will never use, but I am
> now responsible for learning about and possibly debugging, just to
> maintain the (previously stable) features I have always used.
I may be biased on this, but isn't this the main argument for
contributing as much as possible back to the open source project and
staying in-sync with the community?
Really... I don't think I could have expressed this more directly
myself... you wrote very well the reasoning I use with clients to
convince them that working with the community is better than going it
alone.
-David
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Joe Eckard <jo...@redrocketcorp.com>.
On Nov 15, 2008, at 4:37 PM, David E Jones wrote:
>> (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
For me personally, nothing would really change... i.e. when a custom
application is considered feature-complete and relatively stable and
bug-free, then all OFBiz updates stop, and my involvement with the
current trunk comes to an end (for that project). There are exceptions
- when I encounter a bug I'll check the trunk first to see if it has
been fixed, or when I am catching up on messages to the commits list I
may notice an important bug fix that needs to be back-ported right away.
This is unfortunate, because it can put me in the same position as
Markus - improvements and fixes may need to be completely rewritten
and re-tested before I can create patches for the current trunk. (This
is the case for me right now - my main codebase is pre-4.0 and I have
a few changes that I haven't had the time to rewrite and re-test.)
Even if there were more testing in place, the main drawback to staying
current is that with each update I may be taking on new features or
applications that my business will never use, but I am now responsible
for learning about and possibly debugging, just to maintain the
(previously stable) features I have always used.
Speaking to Shi Yusen's comment about a project / release manager, I
don't think it would be fair to push this onto any one person when the
individual committers have all of the information available when they
make a commit. (Will the change break existing code, does the change
add a new feature that requires new seed data or a data model change,
etc.)
-Joe
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Bruno Busco <br...@gmail.com>.
Having a roadmap could simply mean having something like this:
https://issues.apache.org/jira/secure/BrowseProject.jspa?id=12310110&subset=-1
or
https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10600&subset=-1
or
https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220&subset=3
or
https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10560&subset=-1
If it is for sure true that OFBiz grows up thanks to contribution that
developers do because they need them with their customers, it is also true
that many efforts have been done, and will be, to have OFBiz more generic,
with a more reusability factor, with a better UI etc.
Those generally are not things requested by a developer's customer but are
things that OFBiz still needs to have something to base a marketing campain
on.
A clear and solid release number is something really needed.
How could we ever write on the site news "Released OFBiz x.y (see release
notes)" otherwise?
The release numbering, IMO, is at the top of the list in the marketing aware
factors.
-Bruno
2008/11/16 Shi Yusen <sh...@langhua.cn>
> I guess no War of Independence would happen. I can't remember Mel
> Gibson reported to anybody in Patriot.
>
> I can trust anyone in PMC. OFBiz itself is a brand like a commercial
> software.
>
> Why do we need a release version? What we really need is a predictable
> vision if OFBiz is our core platform of our business. For example, we
> also use OpenCms as our core platform. We developed an OpenCms-LDAP
> module and we don't want it to be a part of OpenCms as it's not perfect.
> But it's useful,
>
>
> 在 2008-11-15六的 16:36 -0500，David E Jones写道：
> > On Nov 15, 2008, at 4:27 PM, David E Jones wrote:
> > > 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 guess no War of Independence would happen. I can't remember Mel
> Gibson reported to anybody in Patriot.
>
> I can trust anyone in PMC. OFBiz itself is a brand like a commercial
> software and clients should be able to trust.
>
> People do trust open source now.
> (ad, you can skip this)
> We are offering technical support to T-Systems China on BMW Web Hosting,
> the website of BMW China and worldwide is built on Linux, OpenCms,
> Tomcat and Mysql, all are open source, except some functions developed
> by Interone.
>
> Open source is not a problem any more. Is community-driven model a
> problem? If yes, I would suggest CHANGE.
>
> > 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
> >
>
> Nobody would say OFBiz is not good. And it's not necessary to proof
> OFBiz is good. On the contrary, I think people (at least myself) need
> OFBiz promising. If you feel the project is hard to control (I know you
> don't like control, I believe you may not like out of control, then
> control it), it's a good idea to do the work as you said, narrow your
> efforts to framework-only, then the framework would play the role of
> tomcat project, OFBiz as the Jakarta, applications and specailpurposes
> as the subprojects (including the ex-subprojects) in Jakarta.
>
> In other words, if even you don't know what the next version of OFBiz
> would be, how could the others know?
>
> Versioning means promising, means roadmap, means you know, and then we
> know, everyone knows where we are going. Then the community can unit
> around you, and costomers will put resources into the real projects
> based on OFBiz (this is the key reason why I say too much here:)).
>
> Though my tone is not that kind. below are what we will open to the
> community for 2009 as a promising (all we promised for 2008 come to
> true):
> 1. Update OFBiz-jBPM component to jBPM 3.3.2 or later and OFBiz trunk.
> 2. Update OFBiz-LDAP-CAS to support LDAP membership and alias setting.
> 3. Develop OFBiz-SAML to support SAML(may not the latest SAML 2.0).
> 4. Develop OFBiz-OpenID
> 5. Update OFBiz-OpenOCES
> 6. Develop OFBiz-Lucene-SearchPipeline
> 7. Continue the OFBiz Chinese localization
>
> Regards,
>
> Shi Yusen/Beijing Langhua Ltd.
>
>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main
Theme: Organizing Ourselves
Posted by Shi Yusen <sh...@langhua.cn>.
I guess no War of Independence would happen. I can't remember Mel
Gibson reported to anybody in Patriot.
I can trust anyone in PMC. OFBiz itself is a brand like a commercial
software.
Why do we need a release version? What we really need is a predictable
vision if OFBiz is our core platform of our business. For example, we
also use OpenCms as our core platform. We developed an OpenCms-LDAP
module and we don't want it to be a part of OpenCms as it's not perfect.
But it's useful,
在 2008-11-15六的 16:36 -0500，David E Jones写道：
> On Nov 15, 2008, at 4:27 PM, David E Jones wrote:
> > 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 guess no War of Independence would happen. I can't remember Mel
Gibson reported to anybody in Patriot.
I can trust anyone in PMC. OFBiz itself is a brand like a commercial
software and clients should be able to trust.
People do trust open source now.
(ad, you can skip this)
We are offering technical support to T-Systems China on BMW Web Hosting,
the website of BMW China and worldwide is built on Linux, OpenCms,
Tomcat and Mysql, all are open source, except some functions developed
by Interone.
Open source is not a problem any more. Is community-driven model a
problem? If yes, I would suggest CHANGE.
> 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
>
Nobody would say OFBiz is not good. And it's not necessary to proof
OFBiz is good. On the contrary, I think people (at least myself) need
OFBiz promising. If you feel the project is hard to control (I know you
don't like control, I believe you may not like out of control, then
control it), it's a good idea to do the work as you said, narrow your
efforts to framework-only, then the framework would play the role of
tomcat project, OFBiz as the Jakarta, applications and specailpurposes
as the subprojects (including the ex-subprojects) in Jakarta.
In other words, if even you don't know what the next version of OFBiz
would be, how could the others know?
Versioning means promising, means roadmap, means you know, and then we
know, everyone knows where we are going. Then the community can unit
around you, and costomers will put resources into the real projects
based on OFBiz (this is the key reason why I say too much here:)).
Though my tone is not that kind. below are what we will open to the
community for 2009 as a promising (all we promised for 2008 come to
true):
1. Update OFBiz-jBPM component to jBPM 3.3.2 or later and OFBiz trunk.
2. Update OFBiz-LDAP-CAS to support LDAP membership and alias setting.
3. Develop OFBiz-SAML to support SAML(may not the latest SAML 2.0).
4. Develop OFBiz-OpenID
5. Update OFBiz-OpenOCES
6. Develop OFBiz-Lucene-SearchPipeline
7. Continue the OFBiz Chinese localization
Regards,
Shi Yusen/Beijing Langhua Ltd.
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sat, 11/15/08, David E Jones <da...@hotwaxmedia.com> wrote:
> 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!
I still want to help out with that, btw. Like you, I got busy with other things. I have some framework release related Jira issues out there that I still intend to work on.
-Adrian
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main
Theme: Organizing Ourselves
Posted by Shi Yusen <sh...@langhua.cn>.
+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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Joe Eckard" <jo...@redrocketcorp.com>
>
> 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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Joe Eckard <jo...@redrocketcorp.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <da...@hotwaxmedia.com>
>
>>
>> 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 <da...@hotwaxmedia.com>
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Bruno Busco <br...@gmail.com>.
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 <da...@hotwaxmedia.com>
>
> 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 <da...@hotwaxmedia.com>
>>
>>
>>> 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
>>>
>>>
>>>
>>>
>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
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 <da...@hotwaxmedia.com>
>
>>
>> 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
>>
>>
>>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Bruno Busco <br...@gmail.com>.
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 <da...@hotwaxmedia.com>
>
> 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
>
>
>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme:
Organizing Ourselves
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme:
Organizing Ourselves
Posted by BJ Freeman <bj...@free-man.net>.
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
>
>
>
>
>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme:
Organizing Ourselves
Posted by Adrian Crum <ad...@hlmksw.com>.
Markus Studer wrote:
> E.g. we translated some applications to german and wanted to give that
> back. Unfortunately, instead of .properties in Release 4.0 there are
> .xml files in trunk and no easy way to merge that somehow into the
> trunk. Currently, I'm redoing some of the translations that we already
> did to get that back into the trunk!
There is a Jira issue open on this very subject -
https://issues.apache.org/jira/browse/OFBIZ-2008. Perhaps you could help
contribute to it.
-Adrian
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
On Nov 18, 2008, at 3:34 AM, Markus Studer wrote:
>> This document has been around for a while, but pretty clearly
>> describes options available and which to take when:
>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>
> yes, that document was the base for our decisions.
>
>> This is a problem that goes back to the beginning of OFBiz, and is
>> fairly unique to community-driven enterprise software. You won't see
>> the same issue with "commercial open source" like SugarCRM or
>> Compiere or OpenBravo or the like, because they develop using a
>> commercial model, and not an open source model.
>
> yes, and I clearly prefer the community-driven approach. Just wanted
> to
> give you an idea why it is difficult (with limited ressources) for
> us to
> contribute back when all the work we do is based on older code (and
> giving things back is what community driven software is all about).
Yeah, understood. That's the reason for the recommendation to use the
trunk and stick with the community. Otherwise, you're going it alone.
With small resources it's difficult, and while larger numbers of
resources help in a way, they seem to just result in more distance
from the trunk which makes it more expensive (and less likely) to get
back in-sync with the community.
Regardless of the number of resources, it just has to become a way of
working, and it works well for teams small and large. Based on
experiences with dozens of clients over the last seven years the
pattern could not be more clear. Those that update frequently and
stick with the community have a much better experience and far fewer
issues than those that "go it alone". It's really that simple.
The same is true for release branches too, you're just dealing with a
smaller community and less changes. For customization efforts this
isn't so great though because new features can't go into a release
branch, so for those you're stuck and on your own since the main body
of the community has moved on.
It's a tough situation any way you look at it. If you want new
features, and you want to collaborate with others, then the only real
option is to use the trunk and stay up to date (at least during
development cycles, and during pre-production testing periods you
would stop updating temporarily).
That's the only solution I've seen that works, and with a little
explanation I've found that clients really go for it and at Hotwax
we've actually won many contracts over other service providers because
we do that as a general practice and are so involved with the
community (ie we don't "go it alone").
-David
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Jacques Le Roux <ja...@les7arts.com>.
Be sure that we all appreciate your help Markus (I mean nowhow in general) !
Jacques
From: "Markus Studer" <ma...@nowhow.ch>
>> This document has been around for a while, but pretty clearly
>> describes options available and which to take when:
>>
>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>
> yes, that document was the base for our decisions.
>
>>
>> This is a problem that goes back to the beginning of OFBiz, and is
>> fairly unique to community-driven enterprise software. You won't see
>> the same issue with "commercial open source" like SugarCRM or
>> Compiere or OpenBravo or the like, because they develop using a
>> commercial model, and not an open source model.
>>
>
> yes, and I clearly prefer the community-driven approach. Just wanted to
> give you an idea why it is difficult (with limited ressources) for us to
> contribute back when all the work we do is based on older code (and
> giving things back is what community driven software is all about).
>
> --
> nowhow solutions AG, Laupenstrasse 1, 3008 Bern
> Phone +41 (0)31 380 00 64, http://www.nowhow.ch
>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme:
Organizing Ourselves
Posted by Markus Studer <ma...@nowhow.ch>.
> This document has been around for a while, but pretty clearly
> describes options available and which to take when:
>
> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
yes, that document was the base for our decisions.
>
> This is a problem that goes back to the beginning of OFBiz, and is
> fairly unique to community-driven enterprise software. You won't see
> the same issue with "commercial open source" like SugarCRM or
> Compiere or OpenBravo or the like, because they develop using a
> commercial model, and not an open source model.
>
yes, and I clearly prefer the community-driven approach. Just wanted to
give you an idea why it is difficult (with limited ressources) for us to
contribute back when all the work we do is based on older code (and
giving things back is what community driven software is all about).
--
nowhow solutions AG, Laupenstrasse 1, 3008 Bern
Phone +41 (0)31 380 00 64, http://www.nowhow.ch
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
This document has been around for a while, but pretty clearly
describes options available and which to take when:
http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
This is a problem that goes back to the beginning of OFBiz, and is
fairly unique to community-driven enterprise software. You won't see
the same issue with "commercial open source" like SugarCRM or Compiere
or OpenBravo or the like, because they develop using a commercial
model, and not an open source model.
-David
On Nov 17, 2008, at 9:25 AM, Markus Studer 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.
>
> Release Handling is tricky and I'd like to give you some infos on the
> kind of problems we're facing with dealing with release 4.0, trunk,
> patches etc.
>
> We've successfully used OFBiz in multiple projects based on a pre 4.0
> release (~6 months before release 4.0). We minor changes to
> framework parts, bigger changes to applications and release 4.0 was
> helpfull for troubleshooting as it is a more stable reference than
> the trunk that moves fast.
>
> There were parts that we wanted to give back to the community and
> that's
> were problems start.
>
> E.g. we translated some applications to german and wanted to give that
> back. Unfortunately, instead of .properties in Release 4.0 there are
> .xml files in trunk and no easy way to merge that somehow into the
> trunk. Currently, I'm redoing some of the translations that we already
> did to get that back into the trunk!
>
> Next problem we face: Which version of OFBiz to use for future
> customer projects:
> - our internal adapted pre 4.0 version (more than 2 years old with our
> own internal bugfixes)
> - 4.0 release (2 years old with the bugfixes from the community)
> - trunk
>
>
> Option 1 -> our pre 4.0 code
>
> not really a nice option as were loosing all the optimizations and
> work the community did in the last years. Backporting new
> functionality will get more and more difficult
>
>
> Option 2 -> Release 4.0
>
> would give us a stable, proven base for development. Unfortunately,
> this
> release is 2 years old and newer functionality is missing. No idea,
> how
> to cope with release 4.0 in a few years. (we also thought about a
> migration of our code to release 4.0 but we're not sure if that is
> worth the effort)
>
>
> Option 3 -> trunk
>
> would give us all the new stuff. Difficult to estimate how risky that
> is, i.e. how stable the trunk is and what effort is needed to fix
> those little bugs in trunk. Once we start with trunk, we won't
> integrate newer code from trunk as those changes contain both
> bugfixes and new functionality (bugfixes are great, new
> functionality not as one needs a stable base to start custom
> development -> that way we're back with option 1 in a few years :) ).
>
>
>
> One thing you also need to consider is that not having releases has
> some subtle consequences. Everyone who checks out from trunk has
> his personal "release". Once you find bugs, you fix them locally but
> to give back such fixes becomes more and more difficult -> you need
> to check out the trunk, recreate the problem, apply the fix, submit
> a patch. As every user has his own "release" (snapshot of time x),
> working together becomes difficult (e.g. there is no usergroup using
> SVN 718108 that has similar problems that can help or other users
> that we can help).
>
>
> Suggestion:
>
> - Framework: Periodical Release (e.g. every 2 years), as the
> framework part is stable and mature and it should be possible to get
> the functionality defined
>
> - Applications: Is more a strategic decision as it defines more how
> OFBiz is used, i.e. more out-of-the Box or as a base for other
> products. There is lot of work involved to get releases done, i.e.
> release management, define functionality for a release, get
> concensus on new features, upgrade paths, documentation. But it
> would clearly help to promote OFBiz. Difficult question that remains
> is how often to release: release often to get new features in vs.
> release sparsely as OFBiz drives your business.
>
> Markus
>
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme:
Organizing Ourselves
Posted by Markus Studer <ma...@nowhow.ch>.
>> 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.
Release Handling is tricky and I'd like to give you some infos on the
kind of problems we're facing with dealing with release 4.0, trunk,
patches etc.
We've successfully used OFBiz in multiple projects based on a pre 4.0
release (~6 months before release 4.0). We minor changes to
framework parts, bigger changes to applications and release 4.0 was
helpfull for troubleshooting as it is a more stable reference than the
trunk that moves fast.
There were parts that we wanted to give back to the community and that's
were problems start.
E.g. we translated some applications to german and wanted to give that
back. Unfortunately, instead of .properties in Release 4.0 there are
.xml files in trunk and no easy way to merge that somehow into the
trunk. Currently, I'm redoing some of the translations that we already
did to get that back into the trunk!
Next problem we face: Which version of OFBiz to use for future
customer projects:
- our internal adapted pre 4.0 version (more than 2 years old with our
own internal bugfixes)
- 4.0 release (2 years old with the bugfixes from the community)
- trunk
Option 1 -> our pre 4.0 code
not really a nice option as were loosing all the optimizations and work
the community did in the last years. Backporting new functionality will
get more and more difficult
Option 2 -> Release 4.0
would give us a stable, proven base for development. Unfortunately, this
release is 2 years old and newer functionality is missing. No idea, how
to cope with release 4.0 in a few years. (we also thought about a
migration of our code to release 4.0 but we're not sure if that is worth
the effort)
Option 3 -> trunk
would give us all the new stuff. Difficult to estimate how risky that
is, i.e. how stable the trunk is and what effort is needed to fix
those little bugs in trunk. Once we start with trunk, we won't integrate
newer code from trunk as those changes contain both bugfixes and new
functionality (bugfixes are great, new functionality not as one needs a
stable base to start custom development -> that way we're back with
option 1 in a few years :) ).
One thing you also need to consider is that not having releases has some
subtle consequences. Everyone who checks out from trunk has his
personal "release". Once you find bugs, you fix them locally but to give
back such fixes becomes more and more difficult -> you need to check out
the trunk, recreate the problem, apply the fix, submit a patch. As every
user has his own "release" (snapshot of time x), working together
becomes difficult (e.g. there is no usergroup using SVN 718108 that has
similar problems that can help or other users that we can help).
Suggestion:
- Framework: Periodical Release (e.g. every 2 years), as the framework
part is stable and mature and it should be possible to get the
functionality defined
- Applications: Is more a strategic decision as it defines more how
OFBiz is used, i.e. more out-of-the Box or as a base for other products.
There is lot of work involved to get releases done, i.e. release
management, define functionality for a release, get concensus on new
features, upgrade paths, documentation. But it would clearly help to
promote OFBiz. Difficult question that remains is how often to release:
release often to get new features in vs. release sparsely as OFBiz
drives your business.
Markus
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by David E Jones <da...@hotwaxmedia.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme:
Organizing Ourselves
Posted by Adrian Crum <ad...@hlmksw.com>.
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
Re: My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves
Posted by Bruno Busco <br...@gmail.com>.
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 <da...@hotwaxmedia.com>
>
> 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
>
>
>
>