Fwd: locale error in simple method

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>

>
> On Jan 16, 2009, at 12:37 AM, Bruno Busco wrote:
>
>>> How we want to do this is a good question. I suppose defining a  release
>>> target is the way to go, and we can use that for bug reporting  after the
>>> branch is created as well.
>>>
>>
>> Yes, this is the way JIRA is supposed to be used.
>
> True, but is it useful to us to use it that way?
>
>>> If we do that this next release could simply be "release2009", or  if we
>>> want to be more specific and perhaps use the Ubuntu model (and  assuming
>>> we're planning for a release in March) we could use something like
>>> "release9.3". I think I like the simple release2009 better...
>>>
>>> Any other opinions?
>>>
>>
>> I would prefer the "release9.3" scheme, since it will allow us to  have more
>> that one release in a year (just in case). It will give very soon a  more
>> precise indication of the time in which the release was done.
>>
>> The version string can be created in JIRA as release9.3, than, if  for any
>> reason we miss the month (or if we finish earlier) we will rename it.
>>
>> If there are no objections I will create a "release 9.3" version  scheduled
>> for march 2009.
>
> I'll acknowledge that more than one release per year could happen, but  I'd be really surprised to see it happen. When a release
> branch is  done it seems to take many months to back-port enough bug fixes from  the trunk and get fixes in from other sources to
> actually make it  fairly solid and functional.
>
> We also have the issue of update paths and scripts or whatever. If we  have too many releases it causes a lot more confusion for
> prospective  users about which release to use, and also causes more effort to  maintain more update paths between releases. If we
> only release every  1-2 years then it is generally pretty clear which one to use.
>
> Actually, I've spelled a lot of this out a long time ago here and as  far as general concepts and issues go I don't think much has
> changed:
>
> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan

I still prefer the Ubuntu way (than old Windows) because there are more information in. Like 9.1 and 9.12 are not the same thing
actually, and I can't see anything annoying in having more information (even if I agree it's not so much important :o)

My 2cts

Jacques

> -David
>

[Pierre Smits]

Getting together at the Apachecon 2009 in Amsterdam would be a good
opportunity to announce the new release (policy) to the public.

Who is visiting that event?

2009/1/16 Jacques Le Roux <[hidden email]>

> +1 (for Ubuntu like)
>
> Jacques
>
> From: "Bruno Busco" <[hidden email]>
>
>> >
>>
>>> How we want to do this is a good question. I suppose defining a release
>>>
>>> target is the way to go, and we can use that for bug reporting after the
>>> branch is created as well.
>>>
>>>
>> Yes, this is the way JIRA is supposed to be used.
>>
>>
>>  If we do that this next release could simply be "release2009", or if we
>>> want to be more specific and perhaps use the Ubuntu model (and assuming
>>> we're planning for a release in March) we could use something like
>>> "release9.3". I think I like the simple release2009 better...
>>>
>>> Any other opinions?
>>>
>>>
>> I would prefer the "release9.3" scheme, since it will allow us to have
>> more
>> that one release in a year (just in case). It will give very soon a more
>> precise indication of the time in which the release was done.
>>
>> The version string can be created in JIRA as release9.3, than, if for any
>> reason we miss the month (or if we finish earlier) we will rename it.
>>
>> If there are no objections I will create a "release 9.3" version scheduled
>> for march 2009.
>>
>> -Bruno
>>
>>
>>> -David
>>>
>>>
>>>
>>> On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>
>>>  David,
>>>
>>>> could you create the new version in JIRA so that we can schedule these
>>>> issues on it and have them displayed in the Road Map?
>>>>
>>>>
>>>>
>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>
>>>> Thanks,
>>>> -Bruno
>>>>
>>>> 2009/1/16 David E Jones <[hidden email]>
>>>>
>>>>
>>>>  On Jan 15, 2009, at 3:33 PM, Adrian Crum wrote:
>>>>>
>>>>> David E Jones wrote:
>>>>>
>>>>>
>>>>>>  What do we still have that is up in the air for refactoring,
>>>>>> cleanups,
>>>>>>
>>>>>>> and enhancements? I know quite a few have been worked on recently but
>>>>>>> I'm
>>>>>>> not sure of their exact status, but here are some that come to mind:
>>>>>>>
>>>>>>>
>>>>>>>  https://issues.apache.org/jira/browse/OFBIZ-1868
>>>>>>
>>>>>>
>>>>>>  Yes, that would be a good one to get done.
>>>>>
>>>>> There may also be other framework versus apps issues that need to be
>>>>> resolved, actually I know there are (Bruno brought one up today in
>>>>> fact).
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>

[Jacques Le Roux]

I will do some more for point 3, but I'm not sure when since I have to merge the CommonEntityLabels with changes Marco did (the next
time I will commit changes - done by a 3rd person - as is before commiting any other changes, and will review later in a RTC way,
lesson learned !)

Jacques

From: "David E Jones" <[hidden email]>

>
> What do we still have that is up in the air for refactoring, cleanups,  and enhancements? I know quite a few have been worked on
> recently but  I'm not sure of their exact status, but here are some that come to mind:
>
> 1. UI label cleanups: Marco/Jacques, mostly done except for a couple  of specialpurpose components?
> 2. Double -> BigDecimal: Scott/David, good chunk done but not the  whole project yet
> 3. simple-method, widget attribute consistency: David/Jacques, all  XSDs and Java updated, still a few app files that need
> cleaning up but  the framework is mostly done
> 4. portal framework and my portal: Bruno/Hans, this seems to be pretty  far along but some refinement and decisions about how to
> work with  framework versus apps needs to be done including the possibility of  having a MyPortal webapp that is part of the
> framework and that  applications, specialpurpose, and hot-deploy components can make  portlets available for, plus pre-build
> portlet sets by role too, so  that end-users can pick and choose based on what is deployed with  inherent support in the framework
> (by the way, I think this is cool,  it is kind of like a new framework feature with a common tool  applications can use, kind of
> like many of the nicer OS X features  where there is a clear line between the OS and apps but the OS  provides many things to
> allow a consistent user experience between  multiples apps, etc)
> 5. visual themes in manager apps and ecommerce: Bruno/Adrian/others,  pretty far along, basics done yet? this is another cool
> feature and I  like the UI enhancement experiments that are starting to go along with  this and will hopefully lead is do a very
> nice default theme at some  point in the near future
>
> Other things? I know I must be missing a few...
>
> On a side note, below is a running wish list I've been keeping and  slowly working on for the last year or so. We don't need to
> wait for  these for a framework release, and most of the ones related to  cleanups are complete now and so off the list
> (GenericDelegator stuff,  simple-method/widget stuff, etc). Just some food for thought that I  suppose is on this topic. Still,
> these are just ideas and things I'd  like to work on (because I'd like to have them for use in day-to-day  work or I think they
> are important in some way) and without actual  work going on they are fairly meaningless (ideas are cheap and easy to  come by,
> actualization of them is not).
>
> That said... we may want to work on some security issues before  another release branch...
>
> -David
>
> =========================================
> - ETL tool for mapping relational and Map/List/etc data, probably as  operations in simple-methods (it is already pretty good for
> this, but  more need to more in abstract and then apply to simple-methods and see  if/what changes are needed)
>
> - XML consume operations for simple-method (and possibly XML produce  too, though perhaps not because data prep can be done in
> simple-method  and then FTL is a great way to template out the XML to produce)
>
> - Drools support
>
> - XSS prevention tools:
> https://issues.apache.org/jira/browse/OFBIZ-260
> http://jira.undersunconsulting.com/browse/OFBIZ-559
> https://issues.apache.org/jira/browse/OFBIZ-1193
> https://issues.apache.org/jira/browse/OFBIZ-1476
> Perhaps use service engine filters for ALL incoming data and by  default do not allow HTML; all service in fields that should
> allow  HTML will have to disable this filter manually, so it will require a  bit of work.
>
> - other security issues:
> https://issues.apache.org/jira/browse/OFBIZ-1959
>
> - IDE plugin for eclipse that uses artifact info stuff
>
> - artifact info stuff for ftl files, groovy scripts
>
> - AJAX form/etc widget stuff, especially a dynamic tree for the tree  widget and better dynamic widgets in the form widget for
> various things
>
> - docs: reference (based on training videos), "support", training,  example narration
> =========================================
>
>
> On Jan 15, 2009, at 7:51 AM, Adrian Crum wrote:
>
>> I agree with much of what David said.
>>
>> Personally, I feel the R4 branch timing was too early. There were  some major refactorings going on at the time, and those
>> refactorings  were completed shortly after the R4 branch - which made R4 obsolete  almost immediately. At the time I didn't have
>> much interest in  maintaining the R4 branch.
>>
>> Things are different this time around. As David mentioned, there has  been a lot of commit activity lately. Much of the work I've
>> done in  the last few months has been making preparations for a new release  branch. From my perspective, if we hold off a bit on
>> new major  changes and let the dust settle a little, the current trunk would be  ready for another release branch. This time
>> around I'm committed to  help maintain it.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Thanks for your comments Scott. I was going to write something  almost as fatalistic. The reality really is that there were very
>>> few fixes that went directly into the release4.0 branch, and I  don't think any of those made it into the trunk. There were lots
>>> of  fixes from the trunk that went into the release branch thanks to  (as Scott mentioned) a few committers who kept an eye on
>>> that.  Those who are interested in a release branch seem to have different  motives and intents than those using the trunk,
>>> which is fine, but  is not very self-sustaining, hence my comments here:
>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>> So, let's get real: release branches attract users but don't  attract committers or contributions. Some of those users may
>>> eventually become committers or contributors and move to the trunk  in order to do so. So, really (to use a cliche: I've said it
>>> before  and I'll say it again) doing releases in any form is mostly a  marketing activity.
>>> Releases are certainly of value to the project, and of course to  the people and organizations who use the releases, and those
>>> who  get an introduction to OFBiz and are attracted to it because of a  release of some form. Back to reality though, in a
>>> community driven  project there is no central organization to fund the effort, and  most OFBiz contributors and committers
>>> contribute based on what  clients request or on issues they want to help with.
>>> Not to say that it is impossible, there are certainly many open  source projects that do so on a regular basis. As I've thought
>>> about this over the years the only feeble conclusion I can come up  with is that those projects have defined functionality sets
>>> that  they can target and plan for. This is something that is easier to  do with framework level tools, which is one of the
>>> reasons I've  been trying to push for a focus on the framework. However, even  there it has been tough to get people to propose
>>> things and plan...  however significant cleanups and enhancements have happened and it  actually is getting into pretty good
>>> shape for release so it can  stand on its own.
>>> For the applications and such it's a bit tougher... the scope is  large and difficult to agree on, especially given the variety
>>> of  organizations and individuals that use OFBiz and contribute back  and by doing so make OFBiz what it is. To help everyone
>>> get on the  same page I've started an effort to define some business processes  that can drive more requirements and designs to
>>> help the refine  OFBiz and give us some targets to shoot for:
>>> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index Now, stepping back a little, we don't HAVE to
>>> do this in order to  do a release. And again being honest with ourselves, without such a  thing it doesn't matter too much
>>> _when_ we create the release  branch... it's really quite arbitrary.
>>> So yes, a lot of thought and planning and numerous attempts (many  just going very slowly...) to move in this direction are
>>> happening.
>>> For the next release branch, there was recent discussion about it  and a decision to do it as I recall, it's now a question of
>>> when  and not if. And the when (also from memory, sorry) was intended to  be about 2 years from the date of the release4.0
>>> branch, and that  is just a few weeks from now. There are lots of great cleanup  efforts going on and unless something serious
>>> is up in the air in a  few weeks, the release branch will happen.
>>> I only hope it will be of value to a number of people and that good  will come from it.
>>> This is one aspect of OFBiz that I don't think is terribly  successful, and past trends are somewhat frustrating, but I still
>>> think it is a good thing and so we work for it and keep trying.  Someday I'm hoping various people from the community will rally
>>> and  create a really great stable release that shines and works like  it's supposed to.
>>> Comments from volunteers and pundits (ie the peanut gallery) welcome.
>>> -David
>>> On Jan 14, 2009, at 8:12 PM, Scott Gray wrote:
>>>> Hi Bruno
>>>> It sounds reasonable in theory but the reality is that merging bug  fixes
>>>> into a branch takes a great deal of time on an ongoing basis.  I  don't
>>>> recall seeing a single bug fixing patch being contributed by any  of the
>>>> community at large, the work was maintained by a couple of  committers and NO
>>>> ONE else.
>>>>
>>>> The whole reason IMO that the v4 release branch never became an  actual
>>>> release was because virtually no one in the community showed any  real
>>>> interest in it.
>>>>
>>>> Personally I think the best thing for the project right now would  be remove
>>>> any mention of the v4 branch from the main page and any other  docs, so that
>>>> people don't mistakenly get the impression that it is the best  path for them
>>>> to take.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> 2009/1/14 Bruno Busco <[hidden email]>
>>>>
>>>>> oops,
>>>>> sorry to have posted this to the USER ML, I apologize, it was
>>>>> intended, of course, as a DEV discussion.
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Bruno Busco <[hidden email]>
>>>>> Date: 2009/1/14
>>>>> Subject: Re: locale error in simple method
>>>>> To: [hidden email]
>>>>>
>>>>>
>>>>> I think that Vince's situation is very common.
>>>>>
>>>>> Whenever you get your ofbiz put in production (or a sort of) you  get
>>>>> really "apprensive" and try to not update your working box.
>>>>> This makes hard also to get bug fixes only from the trunk.
>>>>>
>>>>> Could we think to try to have a new release branch?
>>>>> I mean a branch where only bug fix are merged from the trunk?
>>>>> I know that this has been discussed many times but we should give  it a
>>>>> try. The framework-only release could be still something in the  agenda
>>>>> and should not be affected by the existence of the new complete
>>>>> release branch.
>>>>>
>>>>> The last release branch (4.0) seems now too far from the trunk head
>>>>> and we often suggest not to use it any more. This is fine because  we
>>>>> want people on the "living edge" of the code but then we will get  them
>>>>> in the "should I update or not?" situation.
>>>>>
>>>>> Having a new release branch we will have most people living there  and
>>>>> contributing back bug-fix patch or bug reports that will still be  used
>>>>> in the trunk.
>>>>>
>>>>> I see many new features coming into the trunk and this is really  great
>>>>> but, may be, many more would come if who is going to commit them  knows
>>>>> that the community could always rely on an unaffetced "stable"  branch.
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2009/1/14 Vince M. Clark <[hidden email]>:
>>>>>> I don't waste my time with 4.0.
>>>>>>
>>>>>> Preaching doesn't bother me. I'm used to it and have done a bit  myself.
>>>>>>
>>>>>> But to be clear, I'm very collaborative, and am not holding  anything back
>>>>> from the community. This particular instance I have not upgraded  because it
>>>>> is production (sort of) and I have had difficulty upgrading other  instances
>>>>> recently because of some seed data issues, and possibly other  reasons.
>>>>> Basically related to some of the new stuff like visual themes.
>>>>>>
>>>>>> I will try my custom service against a current download of trunk  to
>>>>> verify that it isn't just a version issue.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "David E Jones" <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> Sent: Tuesday, January 13, 2009 6:06:06 PM (GMT-0700) America/ Denver
>>>>>> Subject: Re: locale error in simple method
>>>>>>
>>>>>>
>>>>>> Is that the trunk rev or in the release4.0 branch?
>>>>>>
>>>>>> Either way it's a few months old (looks like 23 Jul 2008)... it  would
>>>>>> take a fair amount of time for someone to go back and try to  reproduce
>>>>>> the error on that revision. Have you considered updating to a  newer
>>>>>> version of OFBiz?
>>>>>>
>>>>>> Just as an FYI, I usually recommend that people working from the  trunk
>>>>>> really collaborate with the community, an that usually means  needing
>>>>>> to update at least once per day (or at the _very_ least a couple  of
>>>>>> times per week) until the development part of each cycle is done  (ie
>>>>>> before doing integration or business level testing, if that means
>>>>>> anything for your process).
>>>>>>
>>>>>> There are lots of reasons for this, and what you're running into  is
>>>>>> perhaps the most important: by sticking with that revision you're
>>>>>> basically going it alone and choosing not to collaborate with the
>>>>>> community, which makes it hard for others in the community to
>>>>>> collaborate with you. The same is true for the practice of  changing
>>>>>> things in the OFBiz framework or core parts of different  applications
>>>>>> and not contributing it back to the project. The project suffers a
>>>>>> little, but the project will do fine as there are LOTS of people
>>>>>> contributing back. Who really suffers is the end-user organization
>>>>>> that has to foot the bill of maintaining these things instead of
>>>>>> sharing that with the community.
>>>>>>
>>>>>> Sorry for the preaching, but on the other hand thanks for the  soap box
>>>>>> to stand on for a little sermon.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 13, 2009, at 4:34 PM, Vince M. Clark wrote:
>>>>>>
>>>>>>> Thanks David. Rev is 679168
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> Sent: Tuesday, January 13, 2009 5:36:35 PM (GMT-0700) America/ Denver
>>>>>>> Subject: Re: locale error in simple method
>>>>>>>
>>>>>>>
>>>>>>> Stepping back even more... which version/revision of OFBiz are  you
>>>>>>> using?
>>>>>>>
>>>>>>> Based on what you wrote, with the browser submitting a form to  the
>>>>>>> OFBiz web server, as long as it is going through the  ControlServlet
>>>>>>> and you are calling the service you described through a request- map ->
>>>>>>> event tag, then it should work the same way as anything else in  OFBiz.
>>>>>>>
>>>>>>> Unless something is broken somewhere then OFBiz should be  getting a
>>>>>>> locale no matter what, even if it is the system default locale.  It
>>>>>>> looks like somehow that isn't making it into the service call  (you
>>>>>>> could verify that by adding a log tag in your simple-method to  print
>>>>>>> the ${locale} string). That's part of the reason I'm about the
>>>>>>> revision you are using... it could be a real issue that most of  us
>>>>>>> aren't seeing if you're not using a recent trunk revision.
>>>>>>>
>>>>>>> Of, if the assumptions in the 2nd paragraph above are not  correct (ie
>>>>>>> you are calling things differently) then there could be issues  there
>>>>>>> as well.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jan 13, 2009, at 3:59 PM, Vince M. Clark wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> First a disclaimer (plea for mercy). I am an ERP person, not a  web
>>>>>>>> or UI person. So all this http, session, context stuff is rather
>>>>>>>> confusing to me.
>>>>>>>>
>>>>>>>> I've been digging on this issue and want to make sure  something is
>>>>>>>> very clear because I think it may have something to do with the
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> OfBiz is NOT rendering any screens for me. I'm using it as  kind of a
>>>>>>>> "cheap" web service. I have a static html web form served by  Apache
>>>>>>>> web server. The form action calls OfBiz, and then I redirect  back to
>>>>>>>> a static html page. So OfBiz just accepts the request,  processes it,
>>>>>>>> and redirects. No screen rendering whatsoever by OfBiz.
>>>>>>>>
>>>>>>>> I'm pointing this out because of one of the comments I found  in a
>>>>>>>> java class (which of course I cannot find now) that said  something
>>>>>>>> about if locale was not in the context then the browser (or  maybe
>>>>>>>> session) default would be used.
>>>>>>>>
>>>>>>>> So to simplify (or maybe over simplify) my question, is there
>>>>>>>> something I should be doing in my simple method to put locale  in the
>>>>>>>> context before I call createLead. Also, can someone give me a  tip on
>>>>>>>> how to iterate through whatever is in the context and write it  out
>>>>>>>> to the log so I can see it.
>>>>>>>>
>

[Jacques Le Roux]

Also I'd like to commit https://issues.apache.org/jira/browse/OFBIZ-1825 I have still to (re)review and test...

Jacques

From: "David E Jones" <[hidden email]>

>
> What do we still have that is up in the air for refactoring, cleanups,  
> and enhancements? I know quite a few have been worked on recently but  
> I'm not sure of their exact status, but here are some that come to mind:
>
> 1. UI label cleanups: Marco/Jacques, mostly done except for a couple  
> of specialpurpose components?
> 2. Double -> BigDecimal: Scott/David, good chunk done but not the  
> whole project yet
> 3. simple-method, widget attribute consistency: David/Jacques, all  
> XSDs and Java updated, still a few app files that need cleaning up but  
> the framework is mostly done
> 4. portal framework and my portal: Bruno/Hans, this seems to be pretty  
> far along but some refinement and decisions about how to work with  
> framework versus apps needs to be done including the possibility of  
> having a MyPortal webapp that is part of the framework and that  
> applications, specialpurpose, and hot-deploy components can make  
> portlets available for, plus pre-build portlet sets by role too, so  
> that end-users can pick and choose based on what is deployed with  
> inherent support in the framework (by the way, I think this is cool,  
> it is kind of like a new framework feature with a common tool  
> applications can use, kind of like many of the nicer OS X features  
> where there is a clear line between the OS and apps but the OS  
> provides many things to allow a consistent user experience between  
> multiples apps, etc)
> 5. visual themes in manager apps and ecommerce: Bruno/Adrian/others,  
> pretty far along, basics done yet? this is another cool feature and I  
> like the UI enhancement experiments that are starting to go along with  
> this and will hopefully lead is do a very nice default theme at some  
> point in the near future
>
> Other things? I know I must be missing a few...
>
> On a side note, below is a running wish list I've been keeping and  
> slowly working on for the last year or so. We don't need to wait for  
> these for a framework release, and most of the ones related to  
> cleanups are complete now and so off the list (GenericDelegator stuff,  
> simple-method/widget stuff, etc). Just some food for thought that I  
> suppose is on this topic. Still, these are just ideas and things I'd  
> like to work on (because I'd like to have them for use in day-to-day  
> work or I think they are important in some way) and without actual  
> work going on they are fairly meaningless (ideas are cheap and easy to  
> come by, actualization of them is not).
>
> That said... we may want to work on some security issues before  
> another release branch...
>
> -David
>
> =========================================
> - ETL tool for mapping relational and Map/List/etc data, probably as  
> operations in simple-methods (it is already pretty good for this, but  
> more need to more in abstract and then apply to simple-methods and see  
> if/what changes are needed)
>
> - XML consume operations for simple-method (and possibly XML produce  
> too, though perhaps not because data prep can be done in simple-method  
> and then FTL is a great way to template out the XML to produce)
>
> - Drools support
>
> - XSS prevention tools:
> https://issues.apache.org/jira/browse/OFBIZ-260
> http://jira.undersunconsulting.com/browse/OFBIZ-559
> https://issues.apache.org/jira/browse/OFBIZ-1193
> https://issues.apache.org/jira/browse/OFBIZ-1476
> Perhaps use service engine filters for ALL incoming data and by  
> default do not allow HTML; all service in fields that should allow  
> HTML will have to disable this filter manually, so it will require a  
> bit of work.
>
> - other security issues:
> https://issues.apache.org/jira/browse/OFBIZ-1959
>
> - IDE plugin for eclipse that uses artifact info stuff
>
> - artifact info stuff for ftl files, groovy scripts
>
> - AJAX form/etc widget stuff, especially a dynamic tree for the tree  
> widget and better dynamic widgets in the form widget for various things
>
> - docs: reference (based on training videos), "support", training,  
> example narration
> =========================================
>
>
> On Jan 15, 2009, at 7:51 AM, Adrian Crum wrote:
>
>> I agree with much of what David said.
>>
>> Personally, I feel the R4 branch timing was too early. There were  
>> some major refactorings going on at the time, and those refactorings  
>> were completed shortly after the R4 branch - which made R4 obsolete  
>> almost immediately. At the time I didn't have much interest in  
>> maintaining the R4 branch.
>>
>> Things are different this time around. As David mentioned, there has  
>> been a lot of commit activity lately. Much of the work I've done in  
>> the last few months has been making preparations for a new release  
>> branch. From my perspective, if we hold off a bit on new major  
>> changes and let the dust settle a little, the current trunk would be  
>> ready for another release branch. This time around I'm committed to  
>> help maintain it.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Thanks for your comments Scott. I was going to write something  
>>> almost as fatalistic. The reality really is that there were very  
>>> few fixes that went directly into the release4.0 branch, and I  
>>> don't think any of those made it into the trunk. There were lots of  
>>> fixes from the trunk that went into the release branch thanks to  
>>> (as Scott mentioned) a few committers who kept an eye on that.  
>>> Those who are interested in a release branch seem to have different  
>>> motives and intents than those using the trunk, which is fine, but  
>>> is not very self-sustaining, hence my comments here:
>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>> So, let's get real: release branches attract users but don't  
>>> attract committers or contributions. Some of those users may  
>>> eventually become committers or contributors and move to the trunk  
>>> in order to do so. So, really (to use a cliche: I've said it before  
>>> and I'll say it again) doing releases in any form is mostly a  
>>> marketing activity.
>>> Releases are certainly of value to the project, and of course to  
>>> the people and organizations who use the releases, and those who  
>>> get an introduction to OFBiz and are attracted to it because of a  
>>> release of some form. Back to reality though, in a community driven  
>>> project there is no central organization to fund the effort, and  
>>> most OFBiz contributors and committers contribute based on what  
>>> clients request or on issues they want to help with.
>>> Not to say that it is impossible, there are certainly many open  
>>> source projects that do so on a regular basis. As I've thought  
>>> about this over the years the only feeble conclusion I can come up  
>>> with is that those projects have defined functionality sets that  
>>> they can target and plan for. This is something that is easier to  
>>> do with framework level tools, which is one of the reasons I've  
>>> been trying to push for a focus on the framework. However, even  
>>> there it has been tough to get people to propose things and plan...  
>>> however significant cleanups and enhancements have happened and it  
>>> actually is getting into pretty good shape for release so it can  
>>> stand on its own.
>>> For the applications and such it's a bit tougher... the scope is  
>>> large and difficult to agree on, especially given the variety of  
>>> organizations and individuals that use OFBiz and contribute back  
>>> and by doing so make OFBiz what it is. To help everyone get on the  
>>> same page I've started an effort to define some business processes  
>>> that can drive more requirements and designs to help the refine  
>>> OFBiz and give us some targets to shoot for:
>>> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index 
>>>  Now, stepping back a little, we don't HAVE to do this in order to  
>>> do a release. And again being honest with ourselves, without such a  
>>> thing it doesn't matter too much _when_ we create the release  
>>> branch... it's really quite arbitrary.
>>> So yes, a lot of thought and planning and numerous attempts (many  
>>> just going very slowly...) to move in this direction are happening.
>>> For the next release branch, there was recent discussion about it  
>>> and a decision to do it as I recall, it's now a question of when  
>>> and not if. And the when (also from memory, sorry) was intended to  
>>> be about 2 years from the date of the release4.0 branch, and that  
>>> is just a few weeks from now. There are lots of great cleanup  
>>> efforts going on and unless something serious is up in the air in a  
>>> few weeks, the release branch will happen.
>>> I only hope it will be of value to a number of people and that good  
>>> will come from it.
>>> This is one aspect of OFBiz that I don't think is terribly  
>>> successful, and past trends are somewhat frustrating, but I still  
>>> think it is a good thing and so we work for it and keep trying.  
>>> Someday I'm hoping various people from the community will rally and  
>>> create a really great stable release that shines and works like  
>>> it's supposed to.
>>> Comments from volunteers and pundits (ie the peanut gallery) welcome.
>>> -David
>>> On Jan 14, 2009, at 8:12 PM, Scott Gray wrote:
>>>> Hi Bruno
>>>> It sounds reasonable in theory but the reality is that merging bug  
>>>> fixes
>>>> into a branch takes a great deal of time on an ongoing basis.  I  
>>>> don't
>>>> recall seeing a single bug fixing patch being contributed by any  
>>>> of the
>>>> community at large, the work was maintained by a couple of  
>>>> committers and NO
>>>> ONE else.
>>>>
>>>> The whole reason IMO that the v4 release branch never became an  
>>>> actual
>>>> release was because virtually no one in the community showed any  
>>>> real
>>>> interest in it.
>>>>
>>>> Personally I think the best thing for the project right now would  
>>>> be remove
>>>> any mention of the v4 branch from the main page and any other  
>>>> docs, so that
>>>> people don't mistakenly get the impression that it is the best  
>>>> path for them
>>>> to take.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> 2009/1/14 Bruno Busco <[hidden email]>
>>>>
>>>>> oops,
>>>>> sorry to have posted this to the USER ML, I apologize, it was
>>>>> intended, of course, as a DEV discussion.
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Bruno Busco <[hidden email]>
>>>>> Date: 2009/1/14
>>>>> Subject: Re: locale error in simple method
>>>>> To: [hidden email]
>>>>>
>>>>>
>>>>> I think that Vince's situation is very common.
>>>>>
>>>>> Whenever you get your ofbiz put in production (or a sort of) you  
>>>>> get
>>>>> really "apprensive" and try to not update your working box.
>>>>> This makes hard also to get bug fixes only from the trunk.
>>>>>
>>>>> Could we think to try to have a new release branch?
>>>>> I mean a branch where only bug fix are merged from the trunk?
>>>>> I know that this has been discussed many times but we should give  
>>>>> it a
>>>>> try. The framework-only release could be still something in the  
>>>>> agenda
>>>>> and should not be affected by the existence of the new complete
>>>>> release branch.
>>>>>
>>>>> The last release branch (4.0) seems now too far from the trunk head
>>>>> and we often suggest not to use it any more. This is fine because  
>>>>> we
>>>>> want people on the "living edge" of the code but then we will get  
>>>>> them
>>>>> in the "should I update or not?" situation.
>>>>>
>>>>> Having a new release branch we will have most people living there  
>>>>> and
>>>>> contributing back bug-fix patch or bug reports that will still be  
>>>>> used
>>>>> in the trunk.
>>>>>
>>>>> I see many new features coming into the trunk and this is really  
>>>>> great
>>>>> but, may be, many more would come if who is going to commit them  
>>>>> knows
>>>>> that the community could always rely on an unaffetced "stable"  
>>>>> branch.
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2009/1/14 Vince M. Clark <[hidden email]>:
>>>>>> I don't waste my time with 4.0.
>>>>>>
>>>>>> Preaching doesn't bother me. I'm used to it and have done a bit  
>>>>>> myself.
>>>>>>
>>>>>> But to be clear, I'm very collaborative, and am not holding  
>>>>>> anything back
>>>>> from the community. This particular instance I have not upgraded  
>>>>> because it
>>>>> is production (sort of) and I have had difficulty upgrading other  
>>>>> instances
>>>>> recently because of some seed data issues, and possibly other  
>>>>> reasons.
>>>>> Basically related to some of the new stuff like visual themes.
>>>>>>
>>>>>> I will try my custom service against a current download of trunk  
>>>>>> to
>>>>> verify that it isn't just a version issue.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "David E Jones" <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> Sent: Tuesday, January 13, 2009 6:06:06 PM (GMT-0700) America/
>>>>>> Denver
>>>>>> Subject: Re: locale error in simple method
>>>>>>
>>>>>>
>>>>>> Is that the trunk rev or in the release4.0 branch?
>>>>>>
>>>>>> Either way it's a few months old (looks like 23 Jul 2008)... it  
>>>>>> would
>>>>>> take a fair amount of time for someone to go back and try to  
>>>>>> reproduce
>>>>>> the error on that revision. Have you considered updating to a  
>>>>>> newer
>>>>>> version of OFBiz?
>>>>>>
>>>>>> Just as an FYI, I usually recommend that people working from the  
>>>>>> trunk
>>>>>> really collaborate with the community, an that usually means  
>>>>>> needing
>>>>>> to update at least once per day (or at the _very_ least a couple  
>>>>>> of
>>>>>> times per week) until the development part of each cycle is done  
>>>>>> (ie
>>>>>> before doing integration or business level testing, if that means
>>>>>> anything for your process).
>>>>>>
>>>>>> There are lots of reasons for this, and what you're running into  
>>>>>> is
>>>>>> perhaps the most important: by sticking with that revision you're
>>>>>> basically going it alone and choosing not to collaborate with the
>>>>>> community, which makes it hard for others in the community to
>>>>>> collaborate with you. The same is true for the practice of  
>>>>>> changing
>>>>>> things in the OFBiz framework or core parts of different  
>>>>>> applications
>>>>>> and not contributing it back to the project. The project suffers a
>>>>>> little, but the project will do fine as there are LOTS of people
>>>>>> contributing back. Who really suffers is the end-user organization
>>>>>> that has to foot the bill of maintaining these things instead of
>>>>>> sharing that with the community.
>>>>>>
>>>>>> Sorry for the preaching, but on the other hand thanks for the  
>>>>>> soap box
>>>>>> to stand on for a little sermon.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 13, 2009, at 4:34 PM, Vince M. Clark wrote:
>>>>>>
>>>>>>> Thanks David. Rev is 679168
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> Sent: Tuesday, January 13, 2009 5:36:35 PM (GMT-0700) America/
>>>>>>> Denver
>>>>>>> Subject: Re: locale error in simple method
>>>>>>>
>>>>>>>
>>>>>>> Stepping back even more... which version/revision of OFBiz are  
>>>>>>> you
>>>>>>> using?
>>>>>>>
>>>>>>> Based on what you wrote, with the browser submitting a form to  
>>>>>>> the
>>>>>>> OFBiz web server, as long as it is going through the  
>>>>>>> ControlServlet
>>>>>>> and you are calling the service you described through a request-
>>>>>>> map ->
>>>>>>> event tag, then it should work the same way as anything else in  
>>>>>>> OFBiz.
>>>>>>>
>>>>>>> Unless something is broken somewhere then OFBiz should be  
>>>>>>> getting a
>>>>>>> locale no matter what, even if it is the system default locale.  
>>>>>>> It
>>>>>>> looks like somehow that isn't making it into the service call  
>>>>>>> (you
>>>>>>> could verify that by adding a log tag in your simple-method to  
>>>>>>> print
>>>>>>> the ${locale} string). That's part of the reason I'm about the
>>>>>>> revision you are using... it could be a real issue that most of  
>>>>>>> us
>>>>>>> aren't seeing if you're not using a recent trunk revision.
>>>>>>>
>>>>>>> Of, if the assumptions in the 2nd paragraph above are not  
>>>>>>> correct (ie
>>>>>>> you are calling things differently) then there could be issues  
>>>>>>> there
>>>>>>> as well.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jan 13, 2009, at 3:59 PM, Vince M. Clark wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> First a disclaimer (plea for mercy). I am an ERP person, not a  
>>>>>>>> web
>>>>>>>> or UI person. So all this http, session, context stuff is rather
>>>>>>>> confusing to me.
>>>>>>>>
>>>>>>>> I've been digging on this issue and want to make sure  
>>>>>>>> something is
>>>>>>>> very clear because I think it may have something to do with the
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> OfBiz is NOT rendering any screens for me. I'm using it as  
>>>>>>>> kind of a
>>>>>>>> "cheap" web service. I have a static html web form served by  
>>>>>>>> Apache
>>>>>>>> web server. The form action calls OfBiz, and then I redirect  
>>>>>>>> back to
>>>>>>>> a static html page. So OfBiz just accepts the request,  
>>>>>>>> processes it,
>>>>>>>> and redirects. No screen rendering whatsoever by OfBiz.
>>>>>>>>
>>>>>>>> I'm pointing this out because of one of the comments I found  
>>>>>>>> in a
>>>>>>>> java class (which of course I cannot find now) that said  
>>>>>>>> something
>>>>>>>> about if locale was not in the context then the browser (or  
>>>>>>>> maybe
>>>>>>>> session) default would be used.
>>>>>>>>
>>>>>>>> So to simplify (or maybe over simplify) my question, is there
>>>>>>>> something I should be doing in my simple method to put locale  
>>>>>>>> in the
>>>>>>>> context before I call createLead. Also, can someone give me a  
>>>>>>>> tip on
>>>>>>>> how to iterate through whatever is in the context and write it  
>>>>>>>> out
>>>>>>>> to the log so I can see it.
>>>>>>>>
>

[Jacques Le Roux]

For security we should better refer to https://issues.apache.org/jira/browse/OFBIZ-1525 where all is centralized
I will also finish and commit https://issues.apache.org/jira/browse/OFBIZ-1923 soon

Jacques

From: "David E Jones" <[hidden email]>

>
> What do we still have that is up in the air for refactoring, cleanups,  
> and enhancements? I know quite a few have been worked on recently but  
> I'm not sure of their exact status, but here are some that come to mind:
>
> 1. UI label cleanups: Marco/Jacques, mostly done except for a couple  
> of specialpurpose components?
> 2. Double -> BigDecimal: Scott/David, good chunk done but not the  
> whole project yet
> 3. simple-method, widget attribute consistency: David/Jacques, all  
> XSDs and Java updated, still a few app files that need cleaning up but  
> the framework is mostly done
> 4. portal framework and my portal: Bruno/Hans, this seems to be pretty  
> far along but some refinement and decisions about how to work with  
> framework versus apps needs to be done including the possibility of  
> having a MyPortal webapp that is part of the framework and that  
> applications, specialpurpose, and hot-deploy components can make  
> portlets available for, plus pre-build portlet sets by role too, so  
> that end-users can pick and choose based on what is deployed with  
> inherent support in the framework (by the way, I think this is cool,  
> it is kind of like a new framework feature with a common tool  
> applications can use, kind of like many of the nicer OS X features  
> where there is a clear line between the OS and apps but the OS  
> provides many things to allow a consistent user experience between  
> multiples apps, etc)
> 5. visual themes in manager apps and ecommerce: Bruno/Adrian/others,  
> pretty far along, basics done yet? this is another cool feature and I  
> like the UI enhancement experiments that are starting to go along with  
> this and will hopefully lead is do a very nice default theme at some  
> point in the near future
>
> Other things? I know I must be missing a few...
>
> On a side note, below is a running wish list I've been keeping and  
> slowly working on for the last year or so. We don't need to wait for  
> these for a framework release, and most of the ones related to  
> cleanups are complete now and so off the list (GenericDelegator stuff,  
> simple-method/widget stuff, etc). Just some food for thought that I  
> suppose is on this topic. Still, these are just ideas and things I'd  
> like to work on (because I'd like to have them for use in day-to-day  
> work or I think they are important in some way) and without actual  
> work going on they are fairly meaningless (ideas are cheap and easy to  
> come by, actualization of them is not).
>
> That said... we may want to work on some security issues before  
> another release branch...
>
> -David
>
> =========================================
> - ETL tool for mapping relational and Map/List/etc data, probably as  
> operations in simple-methods (it is already pretty good for this, but  
> more need to more in abstract and then apply to simple-methods and see  
> if/what changes are needed)
>
> - XML consume operations for simple-method (and possibly XML produce  
> too, though perhaps not because data prep can be done in simple-method  
> and then FTL is a great way to template out the XML to produce)
>
> - Drools support
>
> - XSS prevention tools:
> https://issues.apache.org/jira/browse/OFBIZ-260
> http://jira.undersunconsulting.com/browse/OFBIZ-559
> https://issues.apache.org/jira/browse/OFBIZ-1193
> https://issues.apache.org/jira/browse/OFBIZ-1476
> Perhaps use service engine filters for ALL incoming data and by  
> default do not allow HTML; all service in fields that should allow  
> HTML will have to disable this filter manually, so it will require a  
> bit of work.
>
> - other security issues:
> https://issues.apache.org/jira/browse/OFBIZ-1959
>
> - IDE plugin for eclipse that uses artifact info stuff
>
> - artifact info stuff for ftl files, groovy scripts
>
> - AJAX form/etc widget stuff, especially a dynamic tree for the tree  
> widget and better dynamic widgets in the form widget for various things
>
> - docs: reference (based on training videos), "support", training,  
> example narration
> =========================================
>
>
> On Jan 15, 2009, at 7:51 AM, Adrian Crum wrote:
>
>> I agree with much of what David said.
>>
>> Personally, I feel the R4 branch timing was too early. There were  
>> some major refactorings going on at the time, and those refactorings  
>> were completed shortly after the R4 branch - which made R4 obsolete  
>> almost immediately. At the time I didn't have much interest in  
>> maintaining the R4 branch.
>>
>> Things are different this time around. As David mentioned, there has  
>> been a lot of commit activity lately. Much of the work I've done in  
>> the last few months has been making preparations for a new release  
>> branch. From my perspective, if we hold off a bit on new major  
>> changes and let the dust settle a little, the current trunk would be  
>> ready for another release branch. This time around I'm committed to  
>> help maintain it.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Thanks for your comments Scott. I was going to write something  
>>> almost as fatalistic. The reality really is that there were very  
>>> few fixes that went directly into the release4.0 branch, and I  
>>> don't think any of those made it into the trunk. There were lots of  
>>> fixes from the trunk that went into the release branch thanks to  
>>> (as Scott mentioned) a few committers who kept an eye on that.  
>>> Those who are interested in a release branch seem to have different  
>>> motives and intents than those using the trunk, which is fine, but  
>>> is not very self-sustaining, hence my comments here:
>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>> So, let's get real: release branches attract users but don't  
>>> attract committers or contributions. Some of those users may  
>>> eventually become committers or contributors and move to the trunk  
>>> in order to do so. So, really (to use a cliche: I've said it before  
>>> and I'll say it again) doing releases in any form is mostly a  
>>> marketing activity.
>>> Releases are certainly of value to the project, and of course to  
>>> the people and organizations who use the releases, and those who  
>>> get an introduction to OFBiz and are attracted to it because of a  
>>> release of some form. Back to reality though, in a community driven  
>>> project there is no central organization to fund the effort, and  
>>> most OFBiz contributors and committers contribute based on what  
>>> clients request or on issues they want to help with.
>>> Not to say that it is impossible, there are certainly many open  
>>> source projects that do so on a regular basis. As I've thought  
>>> about this over the years the only feeble conclusion I can come up  
>>> with is that those projects have defined functionality sets that  
>>> they can target and plan for. This is something that is easier to  
>>> do with framework level tools, which is one of the reasons I've  
>>> been trying to push for a focus on the framework. However, even  
>>> there it has been tough to get people to propose things and plan...  
>>> however significant cleanups and enhancements have happened and it  
>>> actually is getting into pretty good shape for release so it can  
>>> stand on its own.
>>> For the applications and such it's a bit tougher... the scope is  
>>> large and difficult to agree on, especially given the variety of  
>>> organizations and individuals that use OFBiz and contribute back  
>>> and by doing so make OFBiz what it is. To help everyone get on the  
>>> same page I've started an effort to define some business processes  
>>> that can drive more requirements and designs to help the refine  
>>> OFBiz and give us some targets to shoot for:
>>> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index 
>>>  Now, stepping back a little, we don't HAVE to do this in order to  
>>> do a release. And again being honest with ourselves, without such a  
>>> thing it doesn't matter too much _when_ we create the release  
>>> branch... it's really quite arbitrary.
>>> So yes, a lot of thought and planning and numerous attempts (many  
>>> just going very slowly...) to move in this direction are happening.
>>> For the next release branch, there was recent discussion about it  
>>> and a decision to do it as I recall, it's now a question of when  
>>> and not if. And the when (also from memory, sorry) was intended to  
>>> be about 2 years from the date of the release4.0 branch, and that  
>>> is just a few weeks from now. There are lots of great cleanup  
>>> efforts going on and unless something serious is up in the air in a  
>>> few weeks, the release branch will happen.
>>> I only hope it will be of value to a number of people and that good  
>>> will come from it.
>>> This is one aspect of OFBiz that I don't think is terribly  
>>> successful, and past trends are somewhat frustrating, but I still  
>>> think it is a good thing and so we work for it and keep trying.  
>>> Someday I'm hoping various people from the community will rally and  
>>> create a really great stable release that shines and works like  
>>> it's supposed to.
>>> Comments from volunteers and pundits (ie the peanut gallery) welcome.
>>> -David
>>> On Jan 14, 2009, at 8:12 PM, Scott Gray wrote:
>>>> Hi Bruno
>>>> It sounds reasonable in theory but the reality is that merging bug  
>>>> fixes
>>>> into a branch takes a great deal of time on an ongoing basis.  I  
>>>> don't
>>>> recall seeing a single bug fixing patch being contributed by any  
>>>> of the
>>>> community at large, the work was maintained by a couple of  
>>>> committers and NO
>>>> ONE else.
>>>>
>>>> The whole reason IMO that the v4 release branch never became an  
>>>> actual
>>>> release was because virtually no one in the community showed any  
>>>> real
>>>> interest in it.
>>>>
>>>> Personally I think the best thing for the project right now would  
>>>> be remove
>>>> any mention of the v4 branch from the main page and any other  
>>>> docs, so that
>>>> people don't mistakenly get the impression that it is the best  
>>>> path for them
>>>> to take.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> 2009/1/14 Bruno Busco <[hidden email]>
>>>>
>>>>> oops,
>>>>> sorry to have posted this to the USER ML, I apologize, it was
>>>>> intended, of course, as a DEV discussion.
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Bruno Busco <[hidden email]>
>>>>> Date: 2009/1/14
>>>>> Subject: Re: locale error in simple method
>>>>> To: [hidden email]
>>>>>
>>>>>
>>>>> I think that Vince's situation is very common.
>>>>>
>>>>> Whenever you get your ofbiz put in production (or a sort of) you  
>>>>> get
>>>>> really "apprensive" and try to not update your working box.
>>>>> This makes hard also to get bug fixes only from the trunk.
>>>>>
>>>>> Could we think to try to have a new release branch?
>>>>> I mean a branch where only bug fix are merged from the trunk?
>>>>> I know that this has been discussed many times but we should give  
>>>>> it a
>>>>> try. The framework-only release could be still something in the  
>>>>> agenda
>>>>> and should not be affected by the existence of the new complete
>>>>> release branch.
>>>>>
>>>>> The last release branch (4.0) seems now too far from the trunk head
>>>>> and we often suggest not to use it any more. This is fine because  
>>>>> we
>>>>> want people on the "living edge" of the code but then we will get  
>>>>> them
>>>>> in the "should I update or not?" situation.
>>>>>
>>>>> Having a new release branch we will have most people living there  
>>>>> and
>>>>> contributing back bug-fix patch or bug reports that will still be  
>>>>> used
>>>>> in the trunk.
>>>>>
>>>>> I see many new features coming into the trunk and this is really  
>>>>> great
>>>>> but, may be, many more would come if who is going to commit them  
>>>>> knows
>>>>> that the community could always rely on an unaffetced "stable"  
>>>>> branch.
>>>>>
>>>>> -Bruno
>>>>>
>>>>>
>>>>> 2009/1/14 Vince M. Clark <[hidden email]>:
>>>>>> I don't waste my time with 4.0.
>>>>>>
>>>>>> Preaching doesn't bother me. I'm used to it and have done a bit  
>>>>>> myself.
>>>>>>
>>>>>> But to be clear, I'm very collaborative, and am not holding  
>>>>>> anything back
>>>>> from the community. This particular instance I have not upgraded  
>>>>> because it
>>>>> is production (sort of) and I have had difficulty upgrading other  
>>>>> instances
>>>>> recently because of some seed data issues, and possibly other  
>>>>> reasons.
>>>>> Basically related to some of the new stuff like visual themes.
>>>>>>
>>>>>> I will try my custom service against a current download of trunk  
>>>>>> to
>>>>> verify that it isn't just a version issue.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "David E Jones" <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> Sent: Tuesday, January 13, 2009 6:06:06 PM (GMT-0700) America/
>>>>>> Denver
>>>>>> Subject: Re: locale error in simple method
>>>>>>
>>>>>>
>>>>>> Is that the trunk rev or in the release4.0 branch?
>>>>>>
>>>>>> Either way it's a few months old (looks like 23 Jul 2008)... it  
>>>>>> would
>>>>>> take a fair amount of time for someone to go back and try to  
>>>>>> reproduce
>>>>>> the error on that revision. Have you considered updating to a  
>>>>>> newer
>>>>>> version of OFBiz?
>>>>>>
>>>>>> Just as an FYI, I usually recommend that people working from the  
>>>>>> trunk
>>>>>> really collaborate with the community, an that usually means  
>>>>>> needing
>>>>>> to update at least once per day (or at the _very_ least a couple  
>>>>>> of
>>>>>> times per week) until the development part of each cycle is done  
>>>>>> (ie
>>>>>> before doing integration or business level testing, if that means
>>>>>> anything for your process).
>>>>>>
>>>>>> There are lots of reasons for this, and what you're running into  
>>>>>> is
>>>>>> perhaps the most important: by sticking with that revision you're
>>>>>> basically going it alone and choosing not to collaborate with the
>>>>>> community, which makes it hard for others in the community to
>>>>>> collaborate with you. The same is true for the practice of  
>>>>>> changing
>>>>>> things in the OFBiz framework or core parts of different  
>>>>>> applications
>>>>>> and not contributing it back to the project. The project suffers a
>>>>>> little, but the project will do fine as there are LOTS of people
>>>>>> contributing back. Who really suffers is the end-user organization
>>>>>> that has to foot the bill of maintaining these things instead of
>>>>>> sharing that with the community.
>>>>>>
>>>>>> Sorry for the preaching, but on the other hand thanks for the  
>>>>>> soap box
>>>>>> to stand on for a little sermon.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 13, 2009, at 4:34 PM, Vince M. Clark wrote:
>>>>>>
>>>>>>> Thanks David. Rev is 679168
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> Sent: Tuesday, January 13, 2009 5:36:35 PM (GMT-0700) America/
>>>>>>> Denver
>>>>>>> Subject: Re: locale error in simple method
>>>>>>>
>>>>>>>
>>>>>>> Stepping back even more... which version/revision of OFBiz are  
>>>>>>> you
>>>>>>> using?
>>>>>>>
>>>>>>> Based on what you wrote, with the browser submitting a form to  
>>>>>>> the
>>>>>>> OFBiz web server, as long as it is going through the  
>>>>>>> ControlServlet
>>>>>>> and you are calling the service you described through a request-
>>>>>>> map ->
>>>>>>> event tag, then it should work the same way as anything else in  
>>>>>>> OFBiz.
>>>>>>>
>>>>>>> Unless something is broken somewhere then OFBiz should be  
>>>>>>> getting a
>>>>>>> locale no matter what, even if it is the system default locale.  
>>>>>>> It
>>>>>>> looks like somehow that isn't making it into the service call  
>>>>>>> (you
>>>>>>> could verify that by adding a log tag in your simple-method to  
>>>>>>> print
>>>>>>> the ${locale} string). That's part of the reason I'm about the
>>>>>>> revision you are using... it could be a real issue that most of  
>>>>>>> us
>>>>>>> aren't seeing if you're not using a recent trunk revision.
>>>>>>>
>>>>>>> Of, if the assumptions in the 2nd paragraph above are not  
>>>>>>> correct (ie
>>>>>>> you are calling things differently) then there could be issues  
>>>>>>> there
>>>>>>> as well.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jan 13, 2009, at 3:59 PM, Vince M. Clark wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> First a disclaimer (plea for mercy). I am an ERP person, not a  
>>>>>>>> web
>>>>>>>> or UI person. So all this http, session, context stuff is rather
>>>>>>>> confusing to me.
>>>>>>>>
>>>>>>>> I've been digging on this issue and want to make sure  
>>>>>>>> something is
>>>>>>>> very clear because I think it may have something to do with the
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> OfBiz is NOT rendering any screens for me. I'm using it as  
>>>>>>>> kind of a
>>>>>>>> "cheap" web service. I have a static html web form served by  
>>>>>>>> Apache
>>>>>>>> web server. The form action calls OfBiz, and then I redirect  
>>>>>>>> back to
>>>>>>>> a static html page. So OfBiz just accepts the request,  
>>>>>>>> processes it,
>>>>>>>> and redirects. No screen rendering whatsoever by OfBiz.
>>>>>>>>
>>>>>>>> I'm pointing this out because of one of the comments I found  
>>>>>>>> in a
>>>>>>>> java class (which of course I cannot find now) that said  
>>>>>>>> something
>>>>>>>> about if locale was not in the context then the browser (or  
>>>>>>>> maybe
>>>>>>>> session) default would be used.
>>>>>>>>
>>>>>>>> So to simplify (or maybe over simplify) my question, is there
>>>>>>>> something I should be doing in my simple method to put locale  
>>>>>>>> in the
>>>>>>>> context before I call createLead. Also, can someone give me a  
>>>>>>>> tip on
>>>>>>>> how to iterate through whatever is in the context and write it  
>>>>>>>> out
>>>>>>>> to the log so I can see it.
>>>>>>>>
>

[Bruno Busco]

I have created the label version "OFBIZ 9.3" and scheduled on that all
mentioned issues.
Using the prefix "OFBIZ" we could distinguish it from the framework only
releases that we should decide how to identify.

For a better use of the roadmap panel:
https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
it may be the case of removing the release SVN trunk because it lists too
many issues on it and the page is really huge.

Could we assume that NO VERSION specified means SVN Trunk ?

Please schedule any other issue you think should be included in the 9.3
release using the "Fix version" field.

Thank you,
-Bruno



2009/1/16 Jacques Le Roux <[hidden email]>

> For security we should better refer to
> https://issues.apache.org/jira/browse/OFBIZ-1525 where all is centralized
> I will also finish and commit
> https://issues.apache.org/jira/browse/OFBIZ-1923 soon
>
> Jacques
>
>
> From: "David E Jones" <[hidden email]>
>
>>
>> What do we still have that is up in the air for refactoring, cleanups,
>>  and enhancements? I know quite a few have been worked on recently but  I'm
>> not sure of their exact status, but here are some that come to mind:
>>
>> 1. UI label cleanups: Marco/Jacques, mostly done except for a couple  of
>> specialpurpose components?
>> 2. Double -> BigDecimal: Scott/David, good chunk done but not the  whole
>> project yet
>> 3. simple-method, widget attribute consistency: David/Jacques, all  XSDs
>> and Java updated, still a few app files that need cleaning up but  the
>> framework is mostly done
>> 4. portal framework and my portal: Bruno/Hans, this seems to be pretty
>>  far along but some refinement and decisions about how to work with
>>  framework versus apps needs to be done including the possibility of  having
>> a MyPortal webapp that is part of the framework and that  applications,
>> specialpurpose, and hot-deploy components can make  portlets available for,
>> plus pre-build portlet sets by role too, so  that end-users can pick and
>> choose based on what is deployed with  inherent support in the framework (by
>> the way, I think this is cool,  it is kind of like a new framework feature
>> with a common tool  applications can use, kind of like many of the nicer OS
>> X features  where there is a clear line between the OS and apps but the OS
>>  provides many things to allow a consistent user experience between
>>  multiples apps, etc)
>> 5. visual themes in manager apps and ecommerce: Bruno/Adrian/others,
>>  pretty far along, basics done yet? this is another cool feature and I  like
>> the UI enhancement experiments that are starting to go along with  this and
>> will hopefully lead is do a very nice default theme at some  point in the
>> near future
>>
>> Other things? I know I must be missing a few...
>>
>> On a side note, below is a running wish list I've been keeping and  slowly
>> working on for the last year or so. We don't need to wait for  these for a
>> framework release, and most of the ones related to  cleanups are complete
>> now and so off the list (GenericDelegator stuff,  simple-method/widget
>> stuff, etc). Just some food for thought that I  suppose is on this topic.
>> Still, these are just ideas and things I'd  like to work on (because I'd
>> like to have them for use in day-to-day  work or I think they are important
>> in some way) and without actual  work going on they are fairly meaningless
>> (ideas are cheap and easy to  come by, actualization of them is not).
>>
>> That said... we may want to work on some security issues before  another
>> release branch...
>>
>> -David
>>
>> =========================================
>> - ETL tool for mapping relational and Map/List/etc data, probably as
>>  operations in simple-methods (it is already pretty good for this, but  more
>> need to more in abstract and then apply to simple-methods and see  if/what
>> changes are needed)
>>
>> - XML consume operations for simple-method (and possibly XML produce  too,
>> though perhaps not because data prep can be done in simple-method  and then
>> FTL is a great way to template out the XML to produce)
>>
>> - Drools support
>>
>> - XSS prevention tools:
>> https://issues.apache.org/jira/browse/OFBIZ-260
>> http://jira.undersunconsulting.com/browse/OFBIZ-559
>> https://issues.apache.org/jira/browse/OFBIZ-1193
>> https://issues.apache.org/jira/browse/OFBIZ-1476
>> Perhaps use service engine filters for ALL incoming data and by  default
>> do not allow HTML; all service in fields that should allow  HTML will have
>> to disable this filter manually, so it will require a  bit of work.
>>
>> - other security issues:
>> https://issues.apache.org/jira/browse/OFBIZ-1959
>>
>> - IDE plugin for eclipse that uses artifact info stuff
>>
>> - artifact info stuff for ftl files, groovy scripts
>>
>> - AJAX form/etc widget stuff, especially a dynamic tree for the tree
>>  widget and better dynamic widgets in the form widget for various things
>>
>> - docs: reference (based on training videos), "support", training,
>>  example narration
>> =========================================
>>
>>
>> On Jan 15, 2009, at 7:51 AM, Adrian Crum wrote:
>>
>>  I agree with much of what David said.
>>>
>>> Personally, I feel the R4 branch timing was too early. There were  some
>>> major refactorings going on at the time, and those refactorings  were
>>> completed shortly after the R4 branch - which made R4 obsolete  almost
>>> immediately. At the time I didn't have much interest in  maintaining the R4
>>> branch.
>>>
>>> Things are different this time around. As David mentioned, there has
>>>  been a lot of commit activity lately. Much of the work I've done in  the
>>> last few months has been making preparations for a new release  branch. From
>>> my perspective, if we hold off a bit on new major  changes and let the dust
>>> settle a little, the current trunk would be  ready for another release
>>> branch. This time around I'm committed to  help maintain it.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>
>>>> Thanks for your comments Scott. I was going to write something  almost
>>>> as fatalistic. The reality really is that there were very  few fixes that
>>>> went directly into the release4.0 branch, and I  don't think any of those
>>>> made it into the trunk. There were lots of  fixes from the trunk that went
>>>> into the release branch thanks to  (as Scott mentioned) a few committers who
>>>> kept an eye on that.  Those who are interested in a release branch seem to
>>>> have different  motives and intents than those using the trunk, which is
>>>> fine, but  is not very self-sustaining, hence my comments here:
>>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>> So, let's get real: release branches attract users but don't  attract
>>>> committers or contributions. Some of those users may  eventually become
>>>> committers or contributors and move to the trunk  in order to do so. So,
>>>> really (to use a cliche: I've said it before  and I'll say it again) doing
>>>> releases in any form is mostly a  marketing activity.
>>>> Releases are certainly of value to the project, and of course to  the
>>>> people and organizations who use the releases, and those who  get an
>>>> introduction to OFBiz and are attracted to it because of a  release of some
>>>> form. Back to reality though, in a community driven  project there is no
>>>> central organization to fund the effort, and  most OFBiz contributors and
>>>> committers contribute based on what  clients request or on issues they want
>>>> to help with.
>>>> Not to say that it is impossible, there are certainly many open  source
>>>> projects that do so on a regular basis. As I've thought  about this over the
>>>> years the only feeble conclusion I can come up  with is that those projects
>>>> have defined functionality sets that  they can target and plan for. This is
>>>> something that is easier to  do with framework level tools, which is one of
>>>> the reasons I've  been trying to push for a focus on the framework. However,
>>>> even  there it has been tough to get people to propose things and plan...
>>>>  however significant cleanups and enhancements have happened and it
>>>>  actually is getting into pretty good shape for release so it can  stand on
>>>> its own.
>>>> For the applications and such it's a bit tougher... the scope is  large
>>>> and difficult to agree on, especially given the variety of  organizations
>>>> and individuals that use OFBiz and contribute back  and by doing so make
>>>> OFBiz what it is. To help everyone get on the  same page I've started an
>>>> effort to define some business processes  that can drive more requirements
>>>> and designs to help the refine  OFBiz and give us some targets to shoot for:
>>>>
>>>> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index Now, stepping back a little, we don't HAVE to do this in order to  do a
>>>> release. And again being honest with ourselves, without such a  thing it
>>>> doesn't matter too much _when_ we create the release  branch... it's really
>>>> quite arbitrary.
>>>> So yes, a lot of thought and planning and numerous attempts (many  just
>>>> going very slowly...) to move in this direction are happening.
>>>> For the next release branch, there was recent discussion about it  and a
>>>> decision to do it as I recall, it's now a question of when  and not if. And
>>>> the when (also from memory, sorry) was intended to  be about 2 years from
>>>> the date of the release4.0 branch, and that  is just a few weeks from now.
>>>> There are lots of great cleanup  efforts going on and unless something
>>>> serious is up in the air in a  few weeks, the release branch will happen.
>>>> I only hope it will be of value to a number of people and that good
>>>>  will come from it.
>>>> This is one aspect of OFBiz that I don't think is terribly  successful,
>>>> and past trends are somewhat frustrating, but I still  think it is a good
>>>> thing and so we work for it and keep trying.  Someday I'm hoping various
>>>> people from the community will rally and  create a really great stable
>>>> release that shines and works like  it's supposed to.
>>>> Comments from volunteers and pundits (ie the peanut gallery) welcome.
>>>> -David
>>>> On Jan 14, 2009, at 8:12 PM, Scott Gray wrote:
>>>>
>>>>> Hi Bruno
>>>>> It sounds reasonable in theory but the reality is that merging bug
>>>>>  fixes
>>>>> into a branch takes a great deal of time on an ongoing basis.  I  don't
>>>>> recall seeing a single bug fixing patch being contributed by any  of
>>>>> the
>>>>> community at large, the work was maintained by a couple of  committers
>>>>> and NO
>>>>> ONE else.
>>>>>
>>>>> The whole reason IMO that the v4 release branch never became an  actual
>>>>> release was because virtually no one in the community showed any  real
>>>>> interest in it.
>>>>>
>>>>> Personally I think the best thing for the project right now would  be
>>>>> remove
>>>>> any mention of the v4 branch from the main page and any other  docs, so
>>>>> that
>>>>> people don't mistakenly get the impression that it is the best  path
>>>>> for them
>>>>> to take.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> 2009/1/14 Bruno Busco <[hidden email]>
>>>>>
>>>>>  oops,
>>>>>> sorry to have posted this to the USER ML, I apologize, it was
>>>>>> intended, of course, as a DEV discussion.
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Bruno Busco <[hidden email]>
>>>>>> Date: 2009/1/14
>>>>>> Subject: Re: locale error in simple method
>>>>>> To: [hidden email]
>>>>>>
>>>>>>
>>>>>> I think that Vince's situation is very common.
>>>>>>
>>>>>> Whenever you get your ofbiz put in production (or a sort of) you  get
>>>>>> really "apprensive" and try to not update your working box.
>>>>>> This makes hard also to get bug fixes only from the trunk.
>>>>>>
>>>>>> Could we think to try to have a new release branch?
>>>>>> I mean a branch where only bug fix are merged from the trunk?
>>>>>> I know that this has been discussed many times but we should give  it
>>>>>> a
>>>>>> try. The framework-only release could be still something in the
>>>>>>  agenda
>>>>>> and should not be affected by the existence of the new complete
>>>>>> release branch.
>>>>>>
>>>>>> The last release branch (4.0) seems now too far from the trunk head
>>>>>> and we often suggest not to use it any more. This is fine because  we
>>>>>> want people on the "living edge" of the code but then we will get
>>>>>>  them
>>>>>> in the "should I update or not?" situation.
>>>>>>
>>>>>> Having a new release branch we will have most people living there  and
>>>>>> contributing back bug-fix patch or bug reports that will still be
>>>>>>  used
>>>>>> in the trunk.
>>>>>>
>>>>>> I see many new features coming into the trunk and this is really
>>>>>>  great
>>>>>> but, may be, many more would come if who is going to commit them
>>>>>>  knows
>>>>>> that the community could always rely on an unaffetced "stable"
>>>>>>  branch.
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> 2009/1/14 Vince M. Clark <[hidden email]>:
>>>>>>
>>>>>>> I don't waste my time with 4.0.
>>>>>>>
>>>>>>> Preaching doesn't bother me. I'm used to it and have done a bit
>>>>>>>  myself.
>>>>>>>
>>>>>>> But to be clear, I'm very collaborative, and am not holding  anything
>>>>>>> back
>>>>>>>
>>>>>> from the community. This particular instance I have not upgraded
>>>>>>  because it
>>>>>> is production (sort of) and I have had difficulty upgrading other
>>>>>>  instances
>>>>>> recently because of some seed data issues, and possibly other
>>>>>>  reasons.
>>>>>> Basically related to some of the new stuff like visual themes.
>>>>>>
>>>>>>>
>>>>>>> I will try my custom service against a current download of trunk  to
>>>>>>>
>>>>>> verify that it isn't just a version issue.
>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> Sent: Tuesday, January 13, 2009 6:06:06 PM (GMT-0700) America/ Denver
>>>>>>> Subject: Re: locale error in simple method
>>>>>>>
>>>>>>>
>>>>>>> Is that the trunk rev or in the release4.0 branch?
>>>>>>>
>>>>>>> Either way it's a few months old (looks like 23 Jul 2008)... it
>>>>>>>  would
>>>>>>> take a fair amount of time for someone to go back and try to
>>>>>>>  reproduce
>>>>>>> the error on that revision. Have you considered updating to a  newer
>>>>>>> version of OFBiz?
>>>>>>>
>>>>>>> Just as an FYI, I usually recommend that people working from the
>>>>>>>  trunk
>>>>>>> really collaborate with the community, an that usually means  needing
>>>>>>> to update at least once per day (or at the _very_ least a couple  of
>>>>>>> times per week) until the development part of each cycle is done  (ie
>>>>>>> before doing integration or business level testing, if that means
>>>>>>> anything for your process).
>>>>>>>
>>>>>>> There are lots of reasons for this, and what you're running into  is
>>>>>>> perhaps the most important: by sticking with that revision you're
>>>>>>> basically going it alone and choosing not to collaborate with the
>>>>>>> community, which makes it hard for others in the community to
>>>>>>> collaborate with you. The same is true for the practice of  changing
>>>>>>> things in the OFBiz framework or core parts of different
>>>>>>>  applications
>>>>>>> and not contributing it back to the project. The project suffers a
>>>>>>> little, but the project will do fine as there are LOTS of people
>>>>>>> contributing back. Who really suffers is the end-user organization
>>>>>>> that has to foot the bill of maintaining these things instead of
>>>>>>> sharing that with the community.
>>>>>>>
>>>>>>> Sorry for the preaching, but on the other hand thanks for the  soap
>>>>>>> box
>>>>>>> to stand on for a little sermon.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jan 13, 2009, at 4:34 PM, Vince M. Clark wrote:
>>>>>>>
>>>>>>>  Thanks David. Rev is 679168
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> Sent: Tuesday, January 13, 2009 5:36:35 PM (GMT-0700) America/
>>>>>>>> Denver
>>>>>>>> Subject: Re: locale error in simple method
>>>>>>>>
>>>>>>>>
>>>>>>>> Stepping back even more... which version/revision of OFBiz are  you
>>>>>>>> using?
>>>>>>>>
>>>>>>>> Based on what you wrote, with the browser submitting a form to  the
>>>>>>>> OFBiz web server, as long as it is going through the  ControlServlet
>>>>>>>> and you are calling the service you described through a request- map
>>>>>>>> ->
>>>>>>>> event tag, then it should work the same way as anything else in
>>>>>>>>  OFBiz.
>>>>>>>>
>>>>>>>> Unless something is broken somewhere then OFBiz should be  getting a
>>>>>>>> locale no matter what, even if it is the system default locale.  It
>>>>>>>> looks like somehow that isn't making it into the service call  (you
>>>>>>>> could verify that by adding a log tag in your simple-method to
>>>>>>>>  print
>>>>>>>> the ${locale} string). That's part of the reason I'm about the
>>>>>>>> revision you are using... it could be a real issue that most of  us
>>>>>>>> aren't seeing if you're not using a recent trunk revision.
>>>>>>>>
>>>>>>>> Of, if the assumptions in the 2nd paragraph above are not  correct
>>>>>>>> (ie
>>>>>>>> you are calling things differently) then there could be issues
>>>>>>>>  there
>>>>>>>> as well.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 13, 2009, at 3:59 PM, Vince M. Clark wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> First a disclaimer (plea for mercy). I am an ERP person, not a  web
>>>>>>>>> or UI person. So all this http, session, context stuff is rather
>>>>>>>>> confusing to me.
>>>>>>>>>
>>>>>>>>> I've been digging on this issue and want to make sure  something is
>>>>>>>>> very clear because I think it may have something to do with the
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> OfBiz is NOT rendering any screens for me. I'm using it as  kind of
>>>>>>>>> a
>>>>>>>>> "cheap" web service. I have a static html web form served by
>>>>>>>>>  Apache
>>>>>>>>> web server. The form action calls OfBiz, and then I redirect  back
>>>>>>>>> to
>>>>>>>>> a static html page. So OfBiz just accepts the request,  processes
>>>>>>>>> it,
>>>>>>>>> and redirects. No screen rendering whatsoever by OfBiz.
>>>>>>>>>
>>>>>>>>> I'm pointing this out because of one of the comments I found  in a
>>>>>>>>> java class (which of course I cannot find now) that said  something
>>>>>>>>> about if locale was not in the context then the browser (or  maybe
>>>>>>>>> session) default would be used.
>>>>>>>>>
>>>>>>>>> So to simplify (or maybe over simplify) my question, is there
>>>>>>>>> something I should be doing in my simple method to put locale  in
>>>>>>>>> the
>>>>>>>>> context before I call createLead. Also, can someone give me a  tip
>>>>>>>>> on
>>>>>>>>> how to iterate through whatever is in the context and write it  out
>>>>>>>>> to the log so I can see it.
>>>>>>>>>
>>>>>>>>>
>>

[hans_bakker]

I think this is good proposal.
it should be automatically scheduled.... and update script is a good
idea...

so please (re)read this proposal.

Hans

ps. the attachment not really get trough?

On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:

> Here is another proposal for release branches.  Rather than doing a
> release branch every 1 - 2 years how about doing it by calendar and
> releasing a new branch more frequently (e.g. every 3 months).  The
> objective would be to stay as close to the trunk as possible while
> still providing stability for production releases.  
>
> All appropriate fixes for the release branch would go back into the
> trunk.  Then after 3 months we would create another release branch and
> start the process all over again.  The community could also provide
> update scripts to help production deployments move from one release
> branch to another.  This is currently a pain now and is one of the
> reason I think people don't update their production deployments.
>
> I'm attaching a graphic that shows how this proposal would work.
>
> I'll also put in another plug for community driven test cases.  The
> test cases would be used to determine when the release branch was
> stable enough for a recommended general release.
>
>
> Brett
>
>
> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
> <[hidden email]> wrote:
>        
>         I just setup your jira permissions Bruno (sorry for forgetting
>         that earlier) and you should be able to do this now.
>        
>         How we want to do this is a good question. I suppose defining
>         a release target is the way to go, and we can use that for bug
>         reporting after the branch is created as well.
>        
>         As for the version name of the release we should talk about
>         it. Thinking about it now we have discussed doing a release
>         branch once per year, and perhaps once every 2 years. Perhaps
>         we should version the release with the year? I've never liked
>         that approach a whole lot, because in many cases it is less
>         meaningful that a major/minor version number, but for OFBiz
>         the release branches are time based so perhaps a year makes
>         sense.
>        
>         If we do that this next release could simply be "release2009",
>         or if we want to be more specific and perhaps use the Ubuntu
>         model (and assuming we're planning for a release in March) we
>         could use something like "release9.3". I think I like the
>         simple release2009 better...
>        
>         Any other opinions?
>        
>         -David
>        
>        
>        
>        
>         On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>        
>                 David,
>                 could you create the new version in JIRA so that we
>                 can schedule these
>                 issues on it and have them displayed in the Road Map?
>                
>                 https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>                
>                 Thanks,
>                 -Bruno
>                
>                 2009/1/16 David E Jones <[hidden email]>
>                
>                        
>                         On Jan 15, 2009, at 3:33 PM, Adrian Crum
>                         wrote:
>                        
>                         David E Jones wrote:
>                                
>                                         What do we still have that is
>                                         up in the air for refactoring,
>                                         cleanups,
>                                         and enhancements? I know quite
>                                         a few have been worked on
>                                         recently but I'm
>                                         not sure of their exact
>                                         status, but here are some that
>                                         come to mind:
>                                        
>                                
>                                 https://issues.apache.org/jira/browse/OFBIZ-1868
>                                
>                        
>                         Yes, that would be a good one to get done.
>                        
>                         There may also be other framework versus apps
>                         issues that need to be
>                         resolved, actually I know there are (Bruno
>                         brought one up today in fact).
>                        
>                         -David
>                        
>                        
>        
>        
>

--
Antwebsystems.com: Quality OFBiz services for competitive prices

[Sven Wesley]

Very good, I like this change a lot.

Regards,
Sven

2009/1/16 Bruno Busco <[hidden email]>

> I have created the label version "OFBIZ 9.3" and scheduled on that all
> mentioned issues.
> Using the prefix "OFBIZ" we could distinguish it from the framework only
> releases that we should decide how to identify.
>
> For a better use of the roadmap panel:
>
> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> it may be the case of removing the release SVN trunk because it lists too
> many issues on it and the page is really huge.
>

[David E Jones-3]

On Jan 16, 2009, at 5:03 AM, Bruno Busco wrote:

> I have created the label version "OFBIZ 9.3" and scheduled on that all
> mentioned issues.
> Using the prefix "OFBIZ" we could distinguish it from the framework  
> only
> releases that we should decide how to identify.

I have changed this to be called "Release Branch 9.3" to be consistent.

There is no need to have a separate version for the framework only  
release. The intent is to pull it from the standard release branch  
unless a need to make it separate comes up in the future. The  
framework-only distribution will be as much the same as the normal  
release with the exception of removing the applications and  
specialpurpose directories (and the main build.xml file is setup to  
handle that without modification).

> Could we assume that NO VERSION specified means SVN Trunk ?

There is an explicit version for "SVN Trunk", so are you referring to  
issues that are not using that or any other version? If so,  
unfortunately we'd have to review the submissions on a case-by-case  
basis as the originator of the issue really should say what the issue  
is intended for (ie it's there to help with communication as it can be  
hard to guess). But yes, most issues that don't say a version are  
probably for the trunk... it's just not safe to assume that is always  
the case.

-David

[David E Jones-3]

My reply to another message seems to fit this exactly:

============================================
I'll acknowledge that more than one release per year could happen, but  
I'd be really surprised to see it happen. When a release branch is  
done it seems to take many months to back-port enough bug fixes from  
the trunk and get fixes in from other sources to actually make it  
fairly solid and functional.

We also have the issue of update paths and scripts or whatever. If we  
have too many releases it causes a lot more confusion for prospective  
users about which release to use, and also causes more effort to  
maintain more update paths between releases. If we only release every  
1-2 years then it is generally pretty clear which one to use.

Actually, I've spelled a lot of this out a long time ago here and as  
far as general concepts and issues go I don't think much has changed:

http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
============================================

To sum up: we could certainly try it (I'm up for trying anything), but  
I think with the lack of resources that a single release branch was  
able to rally it would be even more distracting and dispersing of  
resources to have multiple release branches close together. My guess  
was 3 months to get bugs worked out of a release branch, and I think  
it really took more like 6-9 months for release4.0. If we do releases  
closer together I don't think they will EVER get cleaned up with the  
bugs worked out.

-David


On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:

> I think this is good proposal.
> it should be automatically scheduled.... and update script is a good
> idea...
>
> so please (re)read this proposal.
>
> Hans
>
> ps. the attachment not really get trough?
>
> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>> Here is another proposal for release branches.  Rather than doing a
>> release branch every 1 - 2 years how about doing it by calendar and
>> releasing a new branch more frequently (e.g. every 3 months).  The
>> objective would be to stay as close to the trunk as possible while
>> still providing stability for production releases.
>>
>> All appropriate fixes for the release branch would go back into the
>> trunk.  Then after 3 months we would create another release branch  
>> and
>> start the process all over again.  The community could also provide
>> update scripts to help production deployments move from one release
>> branch to another.  This is currently a pain now and is one of the
>> reason I think people don't update their production deployments.
>>
>> I'm attaching a graphic that shows how this proposal would work.
>>
>> I'll also put in another plug for community driven test cases.  The
>> test cases would be used to determine when the release branch was
>> stable enough for a recommended general release.
>>
>>
>> Brett
>>
>>
>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>> <[hidden email]> wrote:
>>
>>        I just setup your jira permissions Bruno (sorry for forgetting
>>        that earlier) and you should be able to do this now.
>>
>>        How we want to do this is a good question. I suppose defining
>>        a release target is the way to go, and we can use that for bug
>>        reporting after the branch is created as well.
>>
>>        As for the version name of the release we should talk about
>>        it. Thinking about it now we have discussed doing a release
>>        branch once per year, and perhaps once every 2 years. Perhaps
>>        we should version the release with the year? I've never liked
>>        that approach a whole lot, because in many cases it is less
>>        meaningful that a major/minor version number, but for OFBiz
>>        the release branches are time based so perhaps a year makes
>>        sense.
>>
>>        If we do that this next release could simply be "release2009",
>>        or if we want to be more specific and perhaps use the Ubuntu
>>        model (and assuming we're planning for a release in March) we
>>        could use something like "release9.3". I think I like the
>>        simple release2009 better...
>>
>>        Any other opinions?
>>
>>        -David
>>
>>
>>
>>
>>        On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>
>>                David,
>>                could you create the new version in JIRA so that we
>>                can schedule these
>>                issues on it and have them displayed in the Road Map?
>>
>>                https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>
>>                Thanks,
>>                -Bruno
>>
>>                2009/1/16 David E Jones <[hidden email]>
>>
>>
>>                        On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>                        wrote:
>>
>>                        David E Jones wrote:
>>
>>                                        What do we still have that is
>>                                        up in the air for refactoring,
>>                                        cleanups,
>>                                        and enhancements? I know quite
>>                                        a few have been worked on
>>                                        recently but I'm
>>                                        not sure of their exact
>>                                        status, but here are some that
>>                                        come to mind:
>>
>>
>>                                https://issues.apache.org/jira/browse/OFBIZ-1868
>>
>>
>>                        Yes, that would be a good one to get done.
>>
>>                        There may also be other framework versus apps
>>                        issues that need to be
>>                        resolved, actually I know there are (Bruno
>>                        brought one up today in fact).
>>
>>                        -David
>>
>>
>>
>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive prices
>

[Jacques Le Roux]

I totally agree with David : experience leads to reality

Jacques

From: "David E Jones" <[hidden email]>

>
> My reply to another message seems to fit this exactly:
>
> ============================================
> I'll acknowledge that more than one release per year could happen, but  
> I'd be really surprised to see it happen. When a release branch is  
> done it seems to take many months to back-port enough bug fixes from  
> the trunk and get fixes in from other sources to actually make it  
> fairly solid and functional.
>
> We also have the issue of update paths and scripts or whatever. If we  
> have too many releases it causes a lot more confusion for prospective  
> users about which release to use, and also causes more effort to  
> maintain more update paths between releases. If we only release every  
> 1-2 years then it is generally pretty clear which one to use.
>
> Actually, I've spelled a lot of this out a long time ago here and as  
> far as general concepts and issues go I don't think much has changed:
>
> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
> ============================================
>
> To sum up: we could certainly try it (I'm up for trying anything), but  
> I think with the lack of resources that a single release branch was  
> able to rally it would be even more distracting and dispersing of  
> resources to have multiple release branches close together. My guess  
> was 3 months to get bugs worked out of a release branch, and I think  
> it really took more like 6-9 months for release4.0. If we do releases  
> closer together I don't think they will EVER get cleaned up with the  
> bugs worked out.
>
> -David
>
>
> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>
>> I think this is good proposal.
>> it should be automatically scheduled.... and update script is a good
>> idea...
>>
>> so please (re)read this proposal.
>>
>> Hans
>>
>> ps. the attachment not really get trough?
>>
>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>> Here is another proposal for release branches.  Rather than doing a
>>> release branch every 1 - 2 years how about doing it by calendar and
>>> releasing a new branch more frequently (e.g. every 3 months).  The
>>> objective would be to stay as close to the trunk as possible while
>>> still providing stability for production releases.
>>>
>>> All appropriate fixes for the release branch would go back into the
>>> trunk.  Then after 3 months we would create another release branch  
>>> and
>>> start the process all over again.  The community could also provide
>>> update scripts to help production deployments move from one release
>>> branch to another.  This is currently a pain now and is one of the
>>> reason I think people don't update their production deployments.
>>>
>>> I'm attaching a graphic that shows how this proposal would work.
>>>
>>> I'll also put in another plug for community driven test cases.  The
>>> test cases would be used to determine when the release branch was
>>> stable enough for a recommended general release.
>>>
>>>
>>> Brett
>>>
>>>
>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>> <[hidden email]> wrote:
>>>
>>>        I just setup your jira permissions Bruno (sorry for forgetting
>>>        that earlier) and you should be able to do this now.
>>>
>>>        How we want to do this is a good question. I suppose defining
>>>        a release target is the way to go, and we can use that for bug
>>>        reporting after the branch is created as well.
>>>
>>>        As for the version name of the release we should talk about
>>>        it. Thinking about it now we have discussed doing a release
>>>        branch once per year, and perhaps once every 2 years. Perhaps
>>>        we should version the release with the year? I've never liked
>>>        that approach a whole lot, because in many cases it is less
>>>        meaningful that a major/minor version number, but for OFBiz
>>>        the release branches are time based so perhaps a year makes
>>>        sense.
>>>
>>>        If we do that this next release could simply be "release2009",
>>>        or if we want to be more specific and perhaps use the Ubuntu
>>>        model (and assuming we're planning for a release in March) we
>>>        could use something like "release9.3". I think I like the
>>>        simple release2009 better...
>>>
>>>        Any other opinions?
>>>
>>>        -David
>>>
>>>
>>>
>>>
>>>        On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>
>>>                David,
>>>                could you create the new version in JIRA so that we
>>>                can schedule these
>>>                issues on it and have them displayed in the Road Map?
>>>
>>>                https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>
>>>                Thanks,
>>>                -Bruno
>>>
>>>                2009/1/16 David E Jones <[hidden email]>
>>>
>>>
>>>                        On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>                        wrote:
>>>
>>>                        David E Jones wrote:
>>>
>>>                                        What do we still have that is
>>>                                        up in the air for refactoring,
>>>                                        cleanups,
>>>                                        and enhancements? I know quite
>>>                                        a few have been worked on
>>>                                        recently but I'm
>>>                                        not sure of their exact
>>>                                        status, but here are some that
>>>                                        come to mind:
>>>
>>>
>>>                                https://issues.apache.org/jira/browse/OFBIZ-1868
>>>
>>>
>>>                        Yes, that would be a good one to get done.
>>>
>>>                        There may also be other framework versus apps
>>>                        issues that need to be
>>>                        resolved, actually I know there are (Bruno
>>>                        brought one up today in fact).
>>>
>>>                        -David
>>>
>>>
>>>
>>>
>>>
>> --
>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>
>

[Jacques Le Roux]

Too near, nothing to present, no time, maybe next year...

Jacques

From: "Pierre Smits" <[hidden email]>

> Getting together at the Apachecon 2009 in Amsterdam would be a good
> opportunity to announce the new release (policy) to the public.
>
> Who is visiting that event?
>
> 2009/1/16 Jacques Le Roux <[hidden email]>
>
>> +1 (for Ubuntu like)
>>
>> Jacques
>>
>> From: "Bruno Busco" <[hidden email]>
>>
>>> >
>>>
>>>> How we want to do this is a good question. I suppose defining a release
>>>>
>>>> target is the way to go, and we can use that for bug reporting after the
>>>> branch is created as well.
>>>>
>>>>
>>> Yes, this is the way JIRA is supposed to be used.
>>>
>>>
>>>  If we do that this next release could simply be "release2009", or if we
>>>> want to be more specific and perhaps use the Ubuntu model (and assuming
>>>> we're planning for a release in March) we could use something like
>>>> "release9.3". I think I like the simple release2009 better...
>>>>
>>>> Any other opinions?
>>>>
>>>>
>>> I would prefer the "release9.3" scheme, since it will allow us to have
>>> more
>>> that one release in a year (just in case). It will give very soon a more
>>> precise indication of the time in which the release was done.
>>>
>>> The version string can be created in JIRA as release9.3, than, if for any
>>> reason we miss the month (or if we finish earlier) we will rename it.
>>>
>>> If there are no objections I will create a "release 9.3" version scheduled
>>> for march 2009.
>>>
>>> -Bruno
>>>
>>>
>>>> -David
>>>>
>>>>
>>>>
>>>> On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>>
>>>>  David,
>>>>
>>>>> could you create the new version in JIRA so that we can schedule these
>>>>> issues on it and have them displayed in the Road Map?
>>>>>
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>>
>>>>> Thanks,
>>>>> -Bruno
>>>>>
>>>>> 2009/1/16 David E Jones <[hidden email]>
>>>>>
>>>>>
>>>>>  On Jan 15, 2009, at 3:33 PM, Adrian Crum wrote:
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>
>>>>>>
>>>>>>>  What do we still have that is up in the air for refactoring,
>>>>>>> cleanups,
>>>>>>>
>>>>>>>> and enhancements? I know quite a few have been worked on recently but
>>>>>>>> I'm
>>>>>>>> not sure of their exact status, but here are some that come to mind:
>>>>>>>>
>>>>>>>>
>>>>>>>>  https://issues.apache.org/jira/browse/OFBIZ-1868
>>>>>>>
>>>>>>>
>>>>>>>  Yes, that would be a good one to get done.
>>>>>>
>>>>>> There may also be other framework versus apps issues that need to be
>>>>>> resolved, actually I know there are (Bruno brought one up today in
>>>>>> fact).
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>

[Brett]

Maybe every 3 months was too optimistic.  I just seems like a year is a long
time to wait for another release.  Especially if you are working with one of
the new ofbiz applications like workeffort and you want new features as they
become available..


Brett

On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <[hidden email]
> wrote:

>
> My reply to another message seems to fit this exactly:
>
> ============================================
> I'll acknowledge that more than one release per year could happen, but I'd
> be really surprised to see it happen. When a release branch is done it seems
> to take many months to back-port enough bug fixes from the trunk and get
> fixes in from other sources to actually make it fairly solid and functional.
>
> We also have the issue of update paths and scripts or whatever. If we have
> too many releases it causes a lot more confusion for prospective users about
> which release to use, and also causes more effort to maintain more update
> paths between releases. If we only release every 1-2 years then it is
> generally pretty clear which one to use.
>
> Actually, I've spelled a lot of this out a long time ago here and as far as
> general concepts and issues go I don't think much has changed:
>
> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
> ============================================
>
> To sum up: we could certainly try it (I'm up for trying anything), but I
> think with the lack of resources that a single release branch was able to
> rally it would be even more distracting and dispersing of resources to have
> multiple release branches close together. My guess was 3 months to get bugs
> worked out of a release branch, and I think it really took more like 6-9
> months for release4.0. If we do releases closer together I don't think they
> will EVER get cleaned up with the bugs worked out.
>
> -David
>
>
>
> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>
>  I think this is good proposal.
>> it should be automatically scheduled.... and update script is a good
>> idea...
>>
>> so please (re)read this proposal.
>>
>> Hans
>>
>> ps. the attachment not really get trough?
>>
>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>
>>> Here is another proposal for release branches.  Rather than doing a
>>> release branch every 1 - 2 years how about doing it by calendar and
>>> releasing a new branch more frequently (e.g. every 3 months).  The
>>> objective would be to stay as close to the trunk as possible while
>>> still providing stability for production releases.
>>>
>>> All appropriate fixes for the release branch would go back into the
>>> trunk.  Then after 3 months we would create another release branch and
>>> start the process all over again.  The community could also provide
>>> update scripts to help production deployments move from one release
>>> branch to another.  This is currently a pain now and is one of the
>>> reason I think people don't update their production deployments.
>>>
>>> I'm attaching a graphic that shows how this proposal would work.
>>>
>>> I'll also put in another plug for community driven test cases.  The
>>> test cases would be used to determine when the release branch was
>>> stable enough for a recommended general release.
>>>
>>>
>>> Brett
>>>
>>>
>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>> <[hidden email]> wrote:
>>>
>>>       I just setup your jira permissions Bruno (sorry for forgetting
>>>       that earlier) and you should be able to do this now.
>>>
>>>       How we want to do this is a good question. I suppose defining
>>>       a release target is the way to go, and we can use that for bug
>>>       reporting after the branch is created as well.
>>>
>>>       As for the version name of the release we should talk about
>>>       it. Thinking about it now we have discussed doing a release
>>>       branch once per year, and perhaps once every 2 years. Perhaps
>>>       we should version the release with the year? I've never liked
>>>       that approach a whole lot, because in many cases it is less
>>>       meaningful that a major/minor version number, but for OFBiz
>>>       the release branches are time based so perhaps a year makes
>>>       sense.
>>>
>>>       If we do that this next release could simply be "release2009",
>>>       or if we want to be more specific and perhaps use the Ubuntu
>>>       model (and assuming we're planning for a release in March) we
>>>       could use something like "release9.3". I think I like the
>>>       simple release2009 better...
>>>
>>>       Any other opinions?
>>>
>>>       -David
>>>
>>>
>>>
>>>
>>>       On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>
>>>               David,
>>>               could you create the new version in JIRA so that we
>>>               can schedule these
>>>               issues on it and have them displayed in the Road Map?
>>>
>>>
>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>
>>>               Thanks,
>>>               -Bruno
>>>
>>>               2009/1/16 David E Jones <[hidden email]>
>>>
>>>
>>>                       On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>                       wrote:
>>>
>>>                       David E Jones wrote:
>>>
>>>                                       What do we still have that is
>>>                                       up in the air for refactoring,
>>>                                       cleanups,
>>>                                       and enhancements? I know quite
>>>                                       a few have been worked on
>>>                                       recently but I'm
>>>                                       not sure of their exact
>>>                                       status, but here are some that
>>>                                       come to mind:
>>>
>>>
>>>
>>> https://issues.apache.org/jira/browse/OFBIZ-1868
>>>
>>>
>>>                       Yes, that would be a good one to get done.
>>>
>>>                       There may also be other framework versus apps
>>>                       issues that need to be
>>>                       resolved, actually I know there are (Bruno
>>>                       brought one up today in fact).
>>>
>>>                       -David
>>>
>>>
>>>
>>>
>>>
>>>  --
>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>
>>
>

[David E Jones-3]

Sounds like you're leaning towards using the trunk... ;)

-David


On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote:

> Maybe every 3 months was too optimistic.  I just seems like a year  
> is a long
> time to wait for another release.  Especially if you are working  
> with one of
> the new ofbiz applications like workeffort and you want new features  
> as they
> become available..
>
>
> Brett
>
> On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <[hidden email]
>> wrote:
>
>>
>> My reply to another message seems to fit this exactly:
>>
>> ============================================
>> I'll acknowledge that more than one release per year could happen,  
>> but I'd
>> be really surprised to see it happen. When a release branch is done  
>> it seems
>> to take many months to back-port enough bug fixes from the trunk  
>> and get
>> fixes in from other sources to actually make it fairly solid and  
>> functional.
>>
>> We also have the issue of update paths and scripts or whatever. If  
>> we have
>> too many releases it causes a lot more confusion for prospective  
>> users about
>> which release to use, and also causes more effort to maintain more  
>> update
>> paths between releases. If we only release every 1-2 years then it is
>> generally pretty clear which one to use.
>>
>> Actually, I've spelled a lot of this out a long time ago here and  
>> as far as
>> general concepts and issues go I don't think much has changed:
>>
>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
>> ============================================
>>
>> To sum up: we could certainly try it (I'm up for trying anything),  
>> but I
>> think with the lack of resources that a single release branch was  
>> able to
>> rally it would be even more distracting and dispersing of resources  
>> to have
>> multiple release branches close together. My guess was 3 months to  
>> get bugs
>> worked out of a release branch, and I think it really took more  
>> like 6-9
>> months for release4.0. If we do releases closer together I don't  
>> think they
>> will EVER get cleaned up with the bugs worked out.
>>
>> -David
>>
>>
>>
>> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>>
>> I think this is good proposal.
>>> it should be automatically scheduled.... and update script is a good
>>> idea...
>>>
>>> so please (re)read this proposal.
>>>
>>> Hans
>>>
>>> ps. the attachment not really get trough?
>>>
>>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>>
>>>> Here is another proposal for release branches.  Rather than doing a
>>>> release branch every 1 - 2 years how about doing it by calendar and
>>>> releasing a new branch more frequently (e.g. every 3 months).  The
>>>> objective would be to stay as close to the trunk as possible while
>>>> still providing stability for production releases.
>>>>
>>>> All appropriate fixes for the release branch would go back into the
>>>> trunk.  Then after 3 months we would create another release  
>>>> branch and
>>>> start the process all over again.  The community could also provide
>>>> update scripts to help production deployments move from one release
>>>> branch to another.  This is currently a pain now and is one of the
>>>> reason I think people don't update their production deployments.
>>>>
>>>> I'm attaching a graphic that shows how this proposal would work.
>>>>
>>>> I'll also put in another plug for community driven test cases.  The
>>>> test cases would be used to determine when the release branch was
>>>> stable enough for a recommended general release.
>>>>
>>>>
>>>> Brett
>>>>
>>>>
>>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>>> <[hidden email]> wrote:
>>>>
>>>>      I just setup your jira permissions Bruno (sorry for forgetting
>>>>      that earlier) and you should be able to do this now.
>>>>
>>>>      How we want to do this is a good question. I suppose defining
>>>>      a release target is the way to go, and we can use that for bug
>>>>      reporting after the branch is created as well.
>>>>
>>>>      As for the version name of the release we should talk about
>>>>      it. Thinking about it now we have discussed doing a release
>>>>      branch once per year, and perhaps once every 2 years. Perhaps
>>>>      we should version the release with the year? I've never liked
>>>>      that approach a whole lot, because in many cases it is less
>>>>      meaningful that a major/minor version number, but for OFBiz
>>>>      the release branches are time based so perhaps a year makes
>>>>      sense.
>>>>
>>>>      If we do that this next release could simply be "release2009",
>>>>      or if we want to be more specific and perhaps use the Ubuntu
>>>>      model (and assuming we're planning for a release in March) we
>>>>      could use something like "release9.3". I think I like the
>>>>      simple release2009 better...
>>>>
>>>>      Any other opinions?
>>>>
>>>>      -David
>>>>
>>>>
>>>>
>>>>
>>>>      On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>>
>>>>              David,
>>>>              could you create the new version in JIRA so that we
>>>>              can schedule these
>>>>              issues on it and have them displayed in the Road Map?
>>>>
>>>>
>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>
>>>>              Thanks,
>>>>              -Bruno
>>>>
>>>>              2009/1/16 David E Jones <[hidden email]>
>>>>
>>>>
>>>>                      On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>>                      wrote:
>>>>
>>>>                      David E Jones wrote:
>>>>
>>>>                                      What do we still have that is
>>>>                                      up in the air for refactoring,
>>>>                                      cleanups,
>>>>                                      and enhancements? I know quite
>>>>                                      a few have been worked on
>>>>                                      recently but I'm
>>>>                                      not sure of their exact
>>>>                                      status, but here are some that
>>>>                                      come to mind:
>>>>
>>>>
>>>>
>>>> https://issues.apache.org/jira/browse/OFBIZ-1868
>>>>
>>>>
>>>>                      Yes, that would be a good one to get done.
>>>>
>>>>                      There may also be other framework versus apps
>>>>                      issues that need to be
>>>>                      resolved, actually I know there are (Bruno
>>>>                      brought one up today in fact).
>>>>
>>>>                      -David
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>
>>>
>>

Point 1 is now completed with the great help of Jacques.

I can work with you on point 3 to cleanup with the new attributes  
declared into XSDs.

Thanks
Marco


Il giorno 16/gen/09, alle ore 08:37, [hidden email] ha scritto:

> Hi David,
>
> about the status of point 1 is really mostly done but I think at  
> maximum next week we will have all cleaned.
>
> Thanks
> Marco
>
>>
>> What do we still have that is up in the air for refactoring,  
>> cleanups,
>> and enhancements? I know quite a few have been worked on recently but
>> I'm not sure of their exact status, but here are some that come to  
>> mind:
>>
>> 1. UI label cleanups: Marco/Jacques, mostly done except for a couple
>> of specialpurpose components?
>> 2. Double -> BigDecimal: Scott/David, good chunk done but not the
>> whole project yet
>> 3. simple-method, widget attribute consistency: David/Jacques, all
>> XSDs and Java updated, still a few app files that need cleaning up  
>> but
>> the framework is mostly done
>> 4. portal framework and my portal: Bruno/Hans, this seems to be  
>> pretty
>> far along but some refinement and decisions about how to work with
>> framework versus apps needs to be done including the possibility of
>> having a MyPortal webapp that is part of the framework and that
>> applications, specialpurpose, and hot-deploy components can make
>> portlets available for, plus pre-build portlet sets by role too, so
>> that end-users can pick and choose based on what is deployed with
>> inherent support in the framework (by the way, I think this is cool,
>> it is kind of like a new framework feature with a common tool
>> applications can use, kind of like many of the nicer OS X features
>> where there is a clear line between the OS and apps but the OS
>> provides many things to allow a consistent user experience between
>> multiples apps, etc)
>> 5. visual themes in manager apps and ecommerce: Bruno/Adrian/others,
>> pretty far along, basics done yet? this is another cool feature and I
>> like the UI enhancement experiments that are starting to go along  
>> with
>> this and will hopefully lead is do a very nice default theme at some
>> point in the near future
>>
>> Other things? I know I must be missing a few...
>>
>> On a side note, below is a running wish list I've been keeping and
>> slowly working on for the last year or so. We don't need to wait for
>> these for a framework release, and most of the ones related to
>> cleanups are complete now and so off the list (GenericDelegator  
>> stuff,
>> simple-method/widget stuff, etc). Just some food for thought that I
>> suppose is on this topic. Still, these are just ideas and things I'd
>> like to work on (because I'd like to have them for use in day-to-day
>> work or I think they are important in some way) and without actual
>> work going on they are fairly meaningless (ideas are cheap and easy  
>> to
>> come by, actualization of them is not).
>>
>> That said... we may want to work on some security issues before
>> another release branch...
>>
>> -David
>>
>> =========================================
>> - ETL tool for mapping relational and Map/List/etc data, probably as
>> operations in simple-methods (it is already pretty good for this, but
>> more need to more in abstract and then apply to simple-methods and  
>> see
>> if/what changes are needed)
>>
>> - XML consume operations for simple-method (and possibly XML produce
>> too, though perhaps not because data prep can be done in simple-
>> method
>> and then FTL is a great way to template out the XML to produce)
>>
>> - Drools support
>>
>> - XSS prevention tools:
>> https://issues.apache.org/jira/browse/OFBIZ-260
>> http://jira.undersunconsulting.com/browse/OFBIZ-559
>> https://issues.apache.org/jira/browse/OFBIZ-1193
>> https://issues.apache.org/jira/browse/OFBIZ-1476
>> Perhaps use service engine filters for ALL incoming data and by
>> default do not allow HTML; all service in fields that should allow
>> HTML will have to disable this filter manually, so it will require a
>> bit of work.
>>
>> - other security issues:
>> https://issues.apache.org/jira/browse/OFBIZ-1959
>>
>> - IDE plugin for eclipse that uses artifact info stuff
>>
>> - artifact info stuff for ftl files, groovy scripts
>>
>> - AJAX form/etc widget stuff, especially a dynamic tree for the tree
>> widget and better dynamic widgets in the form widget for various  
>> things
>>
>> - docs: reference (based on training videos), "support", training,
>> example narration
>> =========================================
>>
>>
>> On Jan 15, 2009, at 7:51 AM, Adrian Crum wrote:
>>
>>> I agree with much of what David said.
>>>
>>> Personally, I feel the R4 branch timing was too early. There were
>>> some major refactorings going on at the time, and those refactorings
>>> were completed shortly after the R4 branch - which made R4 obsolete
>>> almost immediately. At the time I didn't have much interest in
>>> maintaining the R4 branch.
>>>
>>> Things are different this time around. As David mentioned, there has
>>> been a lot of commit activity lately. Much of the work I've done in
>>> the last few months has been making preparations for a new release
>>> branch. From my perspective, if we hold off a bit on new major
>>> changes and let the dust settle a little, the current trunk would be
>>> ready for another release branch. This time around I'm committed to
>>> help maintain it.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> Thanks for your comments Scott. I was going to write something
>>>> almost as fatalistic. The reality really is that there were very
>>>> few fixes that went directly into the release4.0 branch, and I
>>>> don't think any of those made it into the trunk. There were lots of
>>>> fixes from the trunk that went into the release branch thanks to
>>>> (as Scott mentioned) a few committers who kept an eye on that.
>>>> Those who are interested in a release branch seem to have different
>>>> motives and intents than those using the trunk, which is fine, but
>>>> is not very self-sustaining, hence my comments here:
>>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>>>> So, let's get real: release branches attract users but don't
>>>> attract committers or contributions. Some of those users may
>>>> eventually become committers or contributors and move to the trunk
>>>> in order to do so. So, really (to use a cliche: I've said it before
>>>> and I'll say it again) doing releases in any form is mostly a
>>>> marketing activity.
>>>> Releases are certainly of value to the project, and of course to
>>>> the people and organizations who use the releases, and those who
>>>> get an introduction to OFBiz and are attracted to it because of a
>>>> release of some form. Back to reality though, in a community driven
>>>> project there is no central organization to fund the effort, and
>>>> most OFBiz contributors and committers contribute based on what
>>>> clients request or on issues they want to help with.
>>>> Not to say that it is impossible, there are certainly many open
>>>> source projects that do so on a regular basis. As I've thought
>>>> about this over the years the only feeble conclusion I can come up
>>>> with is that those projects have defined functionality sets that
>>>> they can target and plan for. This is something that is easier to
>>>> do with framework level tools, which is one of the reasons I've
>>>> been trying to push for a focus on the framework. However, even
>>>> there it has been tough to get people to propose things and plan...
>>>> however significant cleanups and enhancements have happened and it
>>>> actually is getting into pretty good shape for release so it can
>>>> stand on its own.
>>>> For the applications and such it's a bit tougher... the scope is
>>>> large and difficult to agree on, especially given the variety of
>>>> organizations and individuals that use OFBiz and contribute back
>>>> and by doing so make OFBiz what it is. To help everyone get on the
>>>> same page I've started an effort to define some business processes
>>>> that can drive more requirements and designs to help the refine
>>>> OFBiz and give us some targets to shoot for:
>>>> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index
>>>> Now, stepping back a little, we don't HAVE to do this in order to
>>>> do a release. And again being honest with ourselves, without such a
>>>> thing it doesn't matter too much _when_ we create the release
>>>> branch... it's really quite arbitrary.
>>>> So yes, a lot of thought and planning and numerous attempts (many
>>>> just going very slowly...) to move in this direction are happening.
>>>> For the next release branch, there was recent discussion about it
>>>> and a decision to do it as I recall, it's now a question of when
>>>> and not if. And the when (also from memory, sorry) was intended to
>>>> be about 2 years from the date of the release4.0 branch, and that
>>>> is just a few weeks from now. There are lots of great cleanup
>>>> efforts going on and unless something serious is up in the air in a
>>>> few weeks, the release branch will happen.
>>>> I only hope it will be of value to a number of people and that good
>>>> will come from it.
>>>> This is one aspect of OFBiz that I don't think is terribly
>>>> successful, and past trends are somewhat frustrating, but I still
>>>> think it is a good thing and so we work for it and keep trying.
>>>> Someday I'm hoping various people from the community will rally and
>>>> create a really great stable release that shines and works like
>>>> it's supposed to.
>>>> Comments from volunteers and pundits (ie the peanut gallery)  
>>>> welcome.
>>>> -David
>>>> On Jan 14, 2009, at 8:12 PM, Scott Gray wrote:
>>>>> Hi Bruno
>>>>> It sounds reasonable in theory but the reality is that merging bug
>>>>> fixes
>>>>> into a branch takes a great deal of time on an ongoing basis.  I
>>>>> don't
>>>>> recall seeing a single bug fixing patch being contributed by any
>>>>> of the
>>>>> community at large, the work was maintained by a couple of
>>>>> committers and NO
>>>>> ONE else.
>>>>>
>>>>> The whole reason IMO that the v4 release branch never became an
>>>>> actual
>>>>> release was because virtually no one in the community showed any
>>>>> real
>>>>> interest in it.
>>>>>
>>>>> Personally I think the best thing for the project right now would
>>>>> be remove
>>>>> any mention of the v4 branch from the main page and any other
>>>>> docs, so that
>>>>> people don't mistakenly get the impression that it is the best
>>>>> path for them
>>>>> to take.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> 2009/1/14 Bruno Busco <[hidden email]>
>>>>>
>>>>>> oops,
>>>>>> sorry to have posted this to the USER ML, I apologize, it was
>>>>>> intended, of course, as a DEV discussion.
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Bruno Busco <[hidden email]>
>>>>>> Date: 2009/1/14
>>>>>> Subject: Re: locale error in simple method
>>>>>> To: [hidden email]
>>>>>>
>>>>>>
>>>>>> I think that Vince's situation is very common.
>>>>>>
>>>>>> Whenever you get your ofbiz put in production (or a sort of) you
>>>>>> get
>>>>>> really "apprensive" and try to not update your working box.
>>>>>> This makes hard also to get bug fixes only from the trunk.
>>>>>>
>>>>>> Could we think to try to have a new release branch?
>>>>>> I mean a branch where only bug fix are merged from the trunk?
>>>>>> I know that this has been discussed many times but we should give
>>>>>> it a
>>>>>> try. The framework-only release could be still something in the
>>>>>> agenda
>>>>>> and should not be affected by the existence of the new complete
>>>>>> release branch.
>>>>>>
>>>>>> The last release branch (4.0) seems now too far from the trunk  
>>>>>> head
>>>>>> and we often suggest not to use it any more. This is fine because
>>>>>> we
>>>>>> want people on the "living edge" of the code but then we will get
>>>>>> them
>>>>>> in the "should I update or not?" situation.
>>>>>>
>>>>>> Having a new release branch we will have most people living there
>>>>>> and
>>>>>> contributing back bug-fix patch or bug reports that will still be
>>>>>> used
>>>>>> in the trunk.
>>>>>>
>>>>>> I see many new features coming into the trunk and this is really
>>>>>> great
>>>>>> but, may be, many more would come if who is going to commit them
>>>>>> knows
>>>>>> that the community could always rely on an unaffetced "stable"
>>>>>> branch.
>>>>>>
>>>>>> -Bruno
>>>>>>
>>>>>>
>>>>>> 2009/1/14 Vince M. Clark <[hidden email]>:
>>>>>>> I don't waste my time with 4.0.
>>>>>>>
>>>>>>> Preaching doesn't bother me. I'm used to it and have done a bit
>>>>>>> myself.
>>>>>>>
>>>>>>> But to be clear, I'm very collaborative, and am not holding
>>>>>>> anything back
>>>>>> from the community. This particular instance I have not upgraded
>>>>>> because it
>>>>>> is production (sort of) and I have had difficulty upgrading other
>>>>>> instances
>>>>>> recently because of some seed data issues, and possibly other
>>>>>> reasons.
>>>>>> Basically related to some of the new stuff like visual themes.
>>>>>>>
>>>>>>> I will try my custom service against a current download of trunk
>>>>>>> to
>>>>>> verify that it isn't just a version issue.
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> Sent: Tuesday, January 13, 2009 6:06:06 PM (GMT-0700) America/
>>>>>>> Denver
>>>>>>> Subject: Re: locale error in simple method
>>>>>>>
>>>>>>>
>>>>>>> Is that the trunk rev or in the release4.0 branch?
>>>>>>>
>>>>>>> Either way it's a few months old (looks like 23 Jul 2008)... it
>>>>>>> would
>>>>>>> take a fair amount of time for someone to go back and try to
>>>>>>> reproduce
>>>>>>> the error on that revision. Have you considered updating to a
>>>>>>> newer
>>>>>>> version of OFBiz?
>>>>>>>
>>>>>>> Just as an FYI, I usually recommend that people working from the
>>>>>>> trunk
>>>>>>> really collaborate with the community, an that usually means
>>>>>>> needing
>>>>>>> to update at least once per day (or at the _very_ least a couple
>>>>>>> of
>>>>>>> times per week) until the development part of each cycle is done
>>>>>>> (ie
>>>>>>> before doing integration or business level testing, if that  
>>>>>>> means
>>>>>>> anything for your process).
>>>>>>>
>>>>>>> There are lots of reasons for this, and what you're running into
>>>>>>> is
>>>>>>> perhaps the most important: by sticking with that revision  
>>>>>>> you're
>>>>>>> basically going it alone and choosing not to collaborate with  
>>>>>>> the
>>>>>>> community, which makes it hard for others in the community to
>>>>>>> collaborate with you. The same is true for the practice of
>>>>>>> changing
>>>>>>> things in the OFBiz framework or core parts of different
>>>>>>> applications
>>>>>>> and not contributing it back to the project. The project  
>>>>>>> suffers a
>>>>>>> little, but the project will do fine as there are LOTS of people
>>>>>>> contributing back. Who really suffers is the end-user  
>>>>>>> organization
>>>>>>> that has to foot the bill of maintaining these things instead of
>>>>>>> sharing that with the community.
>>>>>>>
>>>>>>> Sorry for the preaching, but on the other hand thanks for the
>>>>>>> soap box
>>>>>>> to stand on for a little sermon.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jan 13, 2009, at 4:34 PM, Vince M. Clark wrote:
>>>>>>>
>>>>>>>> Thanks David. Rev is 679168
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> Sent: Tuesday, January 13, 2009 5:36:35 PM (GMT-0700) America/
>>>>>>>> Denver
>>>>>>>> Subject: Re: locale error in simple method
>>>>>>>>
>>>>>>>>
>>>>>>>> Stepping back even more... which version/revision of OFBiz are
>>>>>>>> you
>>>>>>>> using?
>>>>>>>>
>>>>>>>> Based on what you wrote, with the browser submitting a form to
>>>>>>>> the
>>>>>>>> OFBiz web server, as long as it is going through the
>>>>>>>> ControlServlet
>>>>>>>> and you are calling the service you described through a  
>>>>>>>> request-
>>>>>>>> map ->
>>>>>>>> event tag, then it should work the same way as anything else in
>>>>>>>> OFBiz.
>>>>>>>>
>>>>>>>> Unless something is broken somewhere then OFBiz should be
>>>>>>>> getting a
>>>>>>>> locale no matter what, even if it is the system default locale.
>>>>>>>> It
>>>>>>>> looks like somehow that isn't making it into the service call
>>>>>>>> (you
>>>>>>>> could verify that by adding a log tag in your simple-method to
>>>>>>>> print
>>>>>>>> the ${locale} string). That's part of the reason I'm about the
>>>>>>>> revision you are using... it could be a real issue that most of
>>>>>>>> us
>>>>>>>> aren't seeing if you're not using a recent trunk revision.
>>>>>>>>
>>>>>>>> Of, if the assumptions in the 2nd paragraph above are not
>>>>>>>> correct (ie
>>>>>>>> you are calling things differently) then there could be issues
>>>>>>>> there
>>>>>>>> as well.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 13, 2009, at 3:59 PM, Vince M. Clark wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> First a disclaimer (plea for mercy). I am an ERP person, not a
>>>>>>>>> web
>>>>>>>>> or UI person. So all this http, session, context stuff is  
>>>>>>>>> rather
>>>>>>>>> confusing to me.
>>>>>>>>>
>>>>>>>>> I've been digging on this issue and want to make sure
>>>>>>>>> something is
>>>>>>>>> very clear because I think it may have something to do with  
>>>>>>>>> the
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> OfBiz is NOT rendering any screens for me. I'm using it as
>>>>>>>>> kind of a
>>>>>>>>> "cheap" web service. I have a static html web form served by
>>>>>>>>> Apache
>>>>>>>>> web server. The form action calls OfBiz, and then I redirect
>>>>>>>>> back to
>>>>>>>>> a static html page. So OfBiz just accepts the request,
>>>>>>>>> processes it,
>>>>>>>>> and redirects. No screen rendering whatsoever by OfBiz.
>>>>>>>>>
>>>>>>>>> I'm pointing this out because of one of the comments I found
>>>>>>>>> in a
>>>>>>>>> java class (which of course I cannot find now) that said
>>>>>>>>> something
>>>>>>>>> about if locale was not in the context then the browser (or
>>>>>>>>> maybe
>>>>>>>>> session) default would be used.
>>>>>>>>>
>>>>>>>>> So to simplify (or maybe over simplify) my question, is there
>>>>>>>>> something I should be doing in my simple method to put locale
>>>>>>>>> in the
>>>>>>>>> context before I call createLead. Also, can someone give me a
>>>>>>>>> tip on
>>>>>>>>> how to iterate through whatever is in the context and write it
>>>>>>>>> out
>>>>>>>>> to the log so I can see it.
>>>>>>>>>
>>
>

[Luke Prentice]

hi guys,

my colleagues (rajib khan and guy gershoni) and have been working with ofbiz
for over 3 years now. we're currently going through the process of
"upgrading" to the latest trunk of ofbiz. we've done this periodically for a
few months and tried really hard to keep our own customisations abstracted
out (so merges are less painful).

i've been following this discussion with interest. because of the pain of
merging in changes from a not-totally-stable trunk (i know that it's not
stable -- cos it's a development trunk!) we need to decide when to "cut our
losses" and move away from the development trunk. some of the recent changes
have been radical enough to slow down our development significantly.

so... we'd like to stay "connected" to the development community and
contribute back changes where that's useful (eg
https://issues.apache.org/jira/browse/OFBIZ-1906). plus we can of course
benefit from fixes in the trunk. however, on reflection, the destabilisation
that results from merging is too great a burden for us to keep doing. (eg,
commit 712932 to ShoppingCart.java was a deep problem for us because we're
extending a number of classes in this file).

[aside: a potential discussion is whether or how can ofbiz users customise
classes? is it bad practice? in our case we have modified the shopping cart
because we want the OrderItem to be extended too.]

hence my interest in this topic. specifically because our team would like to
"lock on" to a stable release branch. we're way ahead of release branch4.0
and have noticed release9.3 appeared recently.

given the list of "must do" and "would like to get done" *before* release9.3
is bedded down, what is a reasonable time frame for this to happen?

short version: *when will release branch 9.3 be committed as stable?*

the answer to that will determine whether we remain connected to the trunk
and seek to commit/merge changes and "play our part" in the community.

many thanks,

luke.

On Sun, Jan 18, 2009 at 6:16 PM, David E Jones
<[hidden email]>wrote:

>
> Sounds like you're leaning towards using the trunk... ;)
>
> -David
>
>
>
> On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote:
>
>  Maybe every 3 months was too optimistic.  I just seems like a year is a
>> long
>> time to wait for another release.  Especially if you are working with one
>> of
>> the new ofbiz applications like workeffort and you want new features as
>> they
>> become available..
>>
>>
>> Brett
>>
>> On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <
>> [hidden email]
>>
>>> wrote:
>>>
>>
>>
>>> My reply to another message seems to fit this exactly:
>>>
>>> ============================================
>>> I'll acknowledge that more than one release per year could happen, but
>>> I'd
>>> be really surprised to see it happen. When a release branch is done it
>>> seems
>>> to take many months to back-port enough bug fixes from the trunk and get
>>> fixes in from other sources to actually make it fairly solid and
>>> functional.
>>>
>>> We also have the issue of update paths and scripts or whatever. If we
>>> have
>>> too many releases it causes a lot more confusion for prospective users
>>> about
>>> which release to use, and also causes more effort to maintain more update
>>> paths between releases. If we only release every 1-2 years then it is
>>> generally pretty clear which one to use.
>>>
>>> Actually, I've spelled a lot of this out a long time ago here and as far
>>> as
>>> general concepts and issues go I don't think much has changed:
>>>
>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
>>> ============================================
>>>
>>> To sum up: we could certainly try it (I'm up for trying anything), but I
>>> think with the lack of resources that a single release branch was able to
>>> rally it would be even more distracting and dispersing of resources to
>>> have
>>> multiple release branches close together. My guess was 3 months to get
>>> bugs
>>> worked out of a release branch, and I think it really took more like 6-9
>>> months for release4.0. If we do releases closer together I don't think
>>> they
>>> will EVER get cleaned up with the bugs worked out.
>>>
>>> -David
>>>
>>>
>>>
>>> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>>>
>>> I think this is good proposal.
>>>
>>>> it should be automatically scheduled.... and update script is a good
>>>> idea...
>>>>
>>>> so please (re)read this proposal.
>>>>
>>>> Hans
>>>>
>>>> ps. the attachment not really get trough?
>>>>
>>>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>>>
>>>>  Here is another proposal for release branches.  Rather than doing a
>>>>> release branch every 1 - 2 years how about doing it by calendar and
>>>>> releasing a new branch more frequently (e.g. every 3 months).  The
>>>>> objective would be to stay as close to the trunk as possible while
>>>>> still providing stability for production releases.
>>>>>
>>>>> All appropriate fixes for the release branch would go back into the
>>>>> trunk.  Then after 3 months we would create another release branch and
>>>>> start the process all over again.  The community could also provide
>>>>> update scripts to help production deployments move from one release
>>>>> branch to another.  This is currently a pain now and is one of the
>>>>> reason I think people don't update their production deployments.
>>>>>
>>>>> I'm attaching a graphic that shows how this proposal would work.
>>>>>
>>>>> I'll also put in another plug for community driven test cases.  The
>>>>> test cases would be used to determine when the release branch was
>>>>> stable enough for a recommended general release.
>>>>>
>>>>>
>>>>> Brett
>>>>>
>>>>>
>>>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>     I just setup your jira permissions Bruno (sorry for forgetting
>>>>>     that earlier) and you should be able to do this now.
>>>>>
>>>>>     How we want to do this is a good question. I suppose defining
>>>>>     a release target is the way to go, and we can use that for bug
>>>>>     reporting after the branch is created as well.
>>>>>
>>>>>     As for the version name of the release we should talk about
>>>>>     it. Thinking about it now we have discussed doing a release
>>>>>     branch once per year, and perhaps once every 2 years. Perhaps
>>>>>     we should version the release with the year? I've never liked
>>>>>     that approach a whole lot, because in many cases it is less
>>>>>     meaningful that a major/minor version number, but for OFBiz
>>>>>     the release branches are time based so perhaps a year makes
>>>>>     sense.
>>>>>
>>>>>     If we do that this next release could simply be "release2009",
>>>>>     or if we want to be more specific and perhaps use the Ubuntu
>>>>>     model (and assuming we're planning for a release in March) we
>>>>>     could use something like "release9.3". I think I like the
>>>>>     simple release2009 better...
>>>>>
>>>>>     Any other opinions?
>>>>>
>>>>>     -David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>>>
>>>>>             David,
>>>>>             could you create the new version in JIRA so that we
>>>>>             can schedule these
>>>>>             issues on it and have them displayed in the Road Map?
>>>>>
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>>
>>>>>             Thanks,
>>>>>             -Bruno
>>>>>
>>>>>             2009/1/16 David E Jones <[hidden email]>
>>>>>
>>>>>
>>>>>                     On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>>>                     wrote:
>>>>>
>>>>>                     David E Jones wrote:
>>>>>
>>>>>                                     What do we still have that is
>>>>>                                     up in the air for refactoring,
>>>>>                                     cleanups,
>>>>>                                     and enhancements? I know quite
>>>>>                                     a few have been worked on
>>>>>                                     recently but I'm
>>>>>                                     not sure of their exact
>>>>>                                     status, but here are some that
>>>>>                                     come to mind:
>>>>>
>>>>>
>>>>>
>>>>> https://issues.apache.org/jira/browse/OFBIZ-1868
>>>>>
>>>>>
>>>>>                     Yes, that would be a good one to get done.
>>>>>
>>>>>                     There may also be other framework versus apps
>>>>>                     issues that need to be
>>>>>                     resolved, actually I know there are (Bruno
>>>>>                     brought one up today in fact).
>>>>>
>>>>>                     -David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>>
>>>>
>>>>
>>>
>

[David E Jones-3]

Unless I'm misunderstanding I think the answers to your questions are  
earlier in this thread. As implied by the name, the planned release  
branch date would be March 2009 (hence the 9.3, in the Ubuntu style).

As for a "stable" branch with errors worked out, the comments about my  
expectations of at least three months and our experience with  
release4.0 of 6-9 months are the best answer available (AFAIK anyway).

As for "safe" extensions to OFBiz... changing classes is a no-no and  
can usually be avoided by some sort of contribution with either the  
literal change you need, or something that makes the class more  
flexible so that you can intercept elsewhere with the change you need.  
In general, class extension is NOT a very good form of creating  
extended functionality that is easy to maintain, no matter what OO  
folks say. You can do a lot with the cart by creating custom request  
events instead of using the default ones, and if the ShoppingCart and  
related classes were a bit cleaner and more flexible (which has been  
discussed a number of times, even recently) then even more could be  
done.

-David


On Jan 19, 2009, at 5:59 PM, Luke Prentice wrote:

> hi guys,
>
> my colleagues (rajib khan and guy gershoni) and have been working  
> with ofbiz
> for over 3 years now. we're currently going through the process of
> "upgrading" to the latest trunk of ofbiz. we've done this  
> periodically for a
> few months and tried really hard to keep our own customisations  
> abstracted
> out (so merges are less painful).
>
> i've been following this discussion with interest. because of the  
> pain of
> merging in changes from a not-totally-stable trunk (i know that it's  
> not
> stable -- cos it's a development trunk!) we need to decide when to  
> "cut our
> losses" and move away from the development trunk. some of the recent  
> changes
> have been radical enough to slow down our development significantly.
>
> so... we'd like to stay "connected" to the development community and
> contribute back changes where that's useful (eg
> https://issues.apache.org/jira/browse/OFBIZ-1906). plus we can of  
> course
> benefit from fixes in the trunk. however, on reflection, the  
> destabilisation
> that results from merging is too great a burden for us to keep  
> doing. (eg,
> commit 712932 to ShoppingCart.java was a deep problem for us because  
> we're
> extending a number of classes in this file).
>
> [aside: a potential discussion is whether or how can ofbiz users  
> customise
> classes? is it bad practice? in our case we have modified the  
> shopping cart
> because we want the OrderItem to be extended too.]
>
> hence my interest in this topic. specifically because our team would  
> like to
> "lock on" to a stable release branch. we're way ahead of release  
> branch4.0
> and have noticed release9.3 appeared recently.
>
> given the list of "must do" and "would like to get done" *before*  
> release9.3
> is bedded down, what is a reasonable time frame for this to happen?
>
> short version: *when will release branch 9.3 be committed as stable?*
>
> the answer to that will determine whether we remain connected to the  
> trunk
> and seek to commit/merge changes and "play our part" in the community.
>
> many thanks,
>
> luke.
>
> On Sun, Jan 18, 2009 at 6:16 PM, David E Jones
> <[hidden email]>wrote:
>
>>
>> Sounds like you're leaning towards using the trunk... ;)
>>
>> -David
>>
>>
>>
>> On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote:
>>
>> Maybe every 3 months was too optimistic.  I just seems like a year  
>> is a
>>> long
>>> time to wait for another release.  Especially if you are working  
>>> with one
>>> of
>>> the new ofbiz applications like workeffort and you want new  
>>> features as
>>> they
>>> become available..
>>>
>>>
>>> Brett
>>>
>>> On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <
>>> [hidden email]
>>>
>>>> wrote:
>>>>
>>>
>>>
>>>> My reply to another message seems to fit this exactly:
>>>>
>>>> ============================================
>>>> I'll acknowledge that more than one release per year could  
>>>> happen, but
>>>> I'd
>>>> be really surprised to see it happen. When a release branch is  
>>>> done it
>>>> seems
>>>> to take many months to back-port enough bug fixes from the trunk  
>>>> and get
>>>> fixes in from other sources to actually make it fairly solid and
>>>> functional.
>>>>
>>>> We also have the issue of update paths and scripts or whatever.  
>>>> If we
>>>> have
>>>> too many releases it causes a lot more confusion for prospective  
>>>> users
>>>> about
>>>> which release to use, and also causes more effort to maintain  
>>>> more update
>>>> paths between releases. If we only release every 1-2 years then  
>>>> it is
>>>> generally pretty clear which one to use.
>>>>
>>>> Actually, I've spelled a lot of this out a long time ago here and  
>>>> as far
>>>> as
>>>> general concepts and issues go I don't think much has changed:
>>>>
>>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
>>>> ============================================
>>>>
>>>> To sum up: we could certainly try it (I'm up for trying  
>>>> anything), but I
>>>> think with the lack of resources that a single release branch was  
>>>> able to
>>>> rally it would be even more distracting and dispersing of  
>>>> resources to
>>>> have
>>>> multiple release branches close together. My guess was 3 months  
>>>> to get
>>>> bugs
>>>> worked out of a release branch, and I think it really took more  
>>>> like 6-9
>>>> months for release4.0. If we do releases closer together I don't  
>>>> think
>>>> they
>>>> will EVER get cleaned up with the bugs worked out.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>>>>
>>>> I think this is good proposal.
>>>>
>>>>> it should be automatically scheduled.... and update script is a  
>>>>> good
>>>>> idea...
>>>>>
>>>>> so please (re)read this proposal.
>>>>>
>>>>> Hans
>>>>>
>>>>> ps. the attachment not really get trough?
>>>>>
>>>>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>>>>
>>>>> Here is another proposal for release branches.  Rather than  
>>>>> doing a
>>>>>> release branch every 1 - 2 years how about doing it by calendar  
>>>>>> and
>>>>>> releasing a new branch more frequently (e.g. every 3 months).  
>>>>>> The
>>>>>> objective would be to stay as close to the trunk as possible  
>>>>>> while
>>>>>> still providing stability for production releases.
>>>>>>
>>>>>> All appropriate fixes for the release branch would go back into  
>>>>>> the
>>>>>> trunk.  Then after 3 months we would create another release  
>>>>>> branch and
>>>>>> start the process all over again.  The community could also  
>>>>>> provide
>>>>>> update scripts to help production deployments move from one  
>>>>>> release
>>>>>> branch to another.  This is currently a pain now and is one of  
>>>>>> the
>>>>>> reason I think people don't update their production deployments.
>>>>>>
>>>>>> I'm attaching a graphic that shows how this proposal would work.
>>>>>>
>>>>>> I'll also put in another plug for community driven test cases.  
>>>>>> The
>>>>>> test cases would be used to determine when the release branch was
>>>>>> stable enough for a recommended general release.
>>>>>>
>>>>>>
>>>>>> Brett
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>    I just setup your jira permissions Bruno (sorry for forgetting
>>>>>>    that earlier) and you should be able to do this now.
>>>>>>
>>>>>>    How we want to do this is a good question. I suppose defining
>>>>>>    a release target is the way to go, and we can use that for bug
>>>>>>    reporting after the branch is created as well.
>>>>>>
>>>>>>    As for the version name of the release we should talk about
>>>>>>    it. Thinking about it now we have discussed doing a release
>>>>>>    branch once per year, and perhaps once every 2 years. Perhaps
>>>>>>    we should version the release with the year? I've never liked
>>>>>>    that approach a whole lot, because in many cases it is less
>>>>>>    meaningful that a major/minor version number, but for OFBiz
>>>>>>    the release branches are time based so perhaps a year makes
>>>>>>    sense.
>>>>>>
>>>>>>    If we do that this next release could simply be "release2009",
>>>>>>    or if we want to be more specific and perhaps use the Ubuntu
>>>>>>    model (and assuming we're planning for a release in March) we
>>>>>>    could use something like "release9.3". I think I like the
>>>>>>    simple release2009 better...
>>>>>>
>>>>>>    Any other opinions?
>>>>>>
>>>>>>    -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>>>>
>>>>>>            David,
>>>>>>            could you create the new version in JIRA so that we
>>>>>>            can schedule these
>>>>>>            issues on it and have them displayed in the Road Map?
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>>>
>>>>>>            Thanks,
>>>>>>            -Bruno
>>>>>>
>>>>>>            2009/1/16 David E Jones <[hidden email]>
>>>>>>
>>>>>>
>>>>>>                    On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>>>>                    wrote:
>>>>>>
>>>>>>                    David E Jones wrote:
>>>>>>
>>>>>>                                    What do we still have that is
>>>>>>                                    up in the air for refactoring,
>>>>>>                                    cleanups,
>>>>>>                                    and enhancements? I know quite
>>>>>>                                    a few have been worked on
>>>>>>                                    recently but I'm
>>>>>>                                    not sure of their exact
>>>>>>                                    status, but here are some that
>>>>>>                                    come to mind:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-1868
>>>>>>
>>>>>>
>>>>>>                    Yes, that would be a good one to get done.
>>>>>>
>>>>>>                    There may also be other framework versus apps
>>>>>>                    issues that need to be
>>>>>>                    resolved, actually I know there are (Bruno
>>>>>>                    brought one up today in fact).
>>>>>>
>>>>>>                    -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>>>
>>>>>
>>>>>
>>>>
>>

[Vince Clark]

Please clarify the process. Are we continuing to work in trunk and then take a snapshot in March, calling that Release Branch 9.3?

----- Original Message -----
From: "David E Jones" <[hidden email]>
To: [hidden email]
Cc: "Rajib Khan" <[hidden email]>, "Guy Gershoni" <[hidden email]>, "Peter Stone" <[hidden email]>
Sent: Tuesday, January 20, 2009 1:25:17 AM (GMT-0700) America/Denver
Subject: Re: New Release Branch (was: locale error in simple method)


Unless I'm misunderstanding I think the answers to your questions are
earlier in this thread. As implied by the name, the planned release
branch date would be March 2009 (hence the 9.3, in the Ubuntu style).

As for a "stable" branch with errors worked out, the comments about my
expectations of at least three months and our experience with
release4.0 of 6-9 months are the best answer available (AFAIK anyway).

As for "safe" extensions to OFBiz... changing classes is a no-no and
can usually be avoided by some sort of contribution with either the
literal change you need, or something that makes the class more
flexible so that you can intercept elsewhere with the change you need.
In general, class extension is NOT a very good form of creating
extended functionality that is easy to maintain, no matter what OO
folks say. You can do a lot with the cart by creating custom request
events instead of using the default ones, and if the ShoppingCart and
related classes were a bit cleaner and more flexible (which has been
discussed a number of times, even recently) then even more could be
done.

-David


On Jan 19, 2009, at 5:59 PM, Luke Prentice wrote:

> hi guys,
>
> my colleagues (rajib khan and guy gershoni) and have been working
> with ofbiz
> for over 3 years now. we're currently going through the process of
> "upgrading" to the latest trunk of ofbiz. we've done this
> periodically for a
> few months and tried really hard to keep our own customisations
> abstracted
> out (so merges are less painful).
>
> i've been following this discussion with interest. because of the
> pain of
> merging in changes from a not-totally-stable trunk (i know that it's
> not
> stable -- cos it's a development trunk!) we need to decide when to
> "cut our
> losses" and move away from the development trunk. some of the recent
> changes
> have been radical enough to slow down our development significantly.
>
> so... we'd like to stay "connected" to the development community and
> contribute back changes where that's useful (eg
> https://issues.apache.org/jira/browse/OFBIZ-1906). plus we can of
> course
> benefit from fixes in the trunk. however, on reflection, the
> destabilisation
> that results from merging is too great a burden for us to keep
> doing. (eg,
> commit 712932 to ShoppingCart.java was a deep problem for us because
> we're
> extending a number of classes in this file).
>
> [aside: a potential discussion is whether or how can ofbiz users
> customise
> classes? is it bad practice? in our case we have modified the
> shopping cart
> because we want the OrderItem to be extended too.]
>
> hence my interest in this topic. specifically because our team would
> like to
> "lock on" to a stable release branch. we're way ahead of release
> branch4.0
> and have noticed release9.3 appeared recently.
>
> given the list of "must do" and "would like to get done" *before*
> release9.3
> is bedded down, what is a reasonable time frame for this to happen?
>
> short version: *when will release branch 9.3 be committed as stable?*
>
> the answer to that will determine whether we remain connected to the
> trunk
> and seek to commit/merge changes and "play our part" in the community.
>
> many thanks,
>
> luke.
>
> On Sun, Jan 18, 2009 at 6:16 PM, David E Jones
> <[hidden email]>wrote:
>
>>
>> Sounds like you're leaning towards using the trunk... ;)
>>
>> -David
>>
>>
>>
>> On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote:
>>
>> Maybe every 3 months was too optimistic. I just seems like a year
>> is a
>>> long
>>> time to wait for another release. Especially if you are working
>>> with one
>>> of
>>> the new ofbiz applications like workeffort and you want new
>>> features as
>>> they
>>> become available..
>>>
>>>
>>> Brett
>>>
>>> On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <
>>> [hidden email]
>>>
>>>> wrote:
>>>>
>>>
>>>
>>>> My reply to another message seems to fit this exactly:
>>>>
>>>> ============================================
>>>> I'll acknowledge that more than one release per year could
>>>> happen, but
>>>> I'd
>>>> be really surprised to see it happen. When a release branch is
>>>> done it
>>>> seems
>>>> to take many months to back-port enough bug fixes from the trunk
>>>> and get
>>>> fixes in from other sources to actually make it fairly solid and
>>>> functional.
>>>>
>>>> We also have the issue of update paths and scripts or whatever.
>>>> If we
>>>> have
>>>> too many releases it causes a lot more confusion for prospective
>>>> users
>>>> about
>>>> which release to use, and also causes more effort to maintain
>>>> more update
>>>> paths between releases. If we only release every 1-2 years then
>>>> it is
>>>> generally pretty clear which one to use.
>>>>
>>>> Actually, I've spelled a lot of this out a long time ago here and
>>>> as far
>>>> as
>>>> general concepts and issues go I don't think much has changed:
>>>>
>>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan 
>>>> ============================================
>>>>
>>>> To sum up: we could certainly try it (I'm up for trying
>>>> anything), but I
>>>> think with the lack of resources that a single release branch was
>>>> able to
>>>> rally it would be even more distracting and dispersing of
>>>> resources to
>>>> have
>>>> multiple release branches close together. My guess was 3 months
>>>> to get
>>>> bugs
>>>> worked out of a release branch, and I think it really took more
>>>> like 6-9
>>>> months for release4.0. If we do releases closer together I don't
>>>> think
>>>> they
>>>> will EVER get cleaned up with the bugs worked out.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>>>>
>>>> I think this is good proposal.
>>>>
>>>>> it should be automatically scheduled.... and update script is a
>>>>> good
>>>>> idea...
>>>>>
>>>>> so please (re)read this proposal.
>>>>>
>>>>> Hans
>>>>>
>>>>> ps. the attachment not really get trough?
>>>>>
>>>>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>>>>
>>>>> Here is another proposal for release branches. Rather than
>>>>> doing a
>>>>>> release branch every 1 - 2 years how about doing it by calendar
>>>>>> and
>>>>>> releasing a new branch more frequently (e.g. every 3 months).
>>>>>> The
>>>>>> objective would be to stay as close to the trunk as possible
>>>>>> while
>>>>>> still providing stability for production releases.
>>>>>>
>>>>>> All appropriate fixes for the release branch would go back into
>>>>>> the
>>>>>> trunk. Then after 3 months we would create another release
>>>>>> branch and
>>>>>> start the process all over again. The community could also
>>>>>> provide
>>>>>> update scripts to help production deployments move from one
>>>>>> release
>>>>>> branch to another. This is currently a pain now and is one of
>>>>>> the
>>>>>> reason I think people don't update their production deployments.
>>>>>>
>>>>>> I'm attaching a graphic that shows how this proposal would work.
>>>>>>
>>>>>> I'll also put in another plug for community driven test cases.
>>>>>> The
>>>>>> test cases would be used to determine when the release branch was
>>>>>> stable enough for a recommended general release.
>>>>>>
>>>>>>
>>>>>> Brett
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> I just setup your jira permissions Bruno (sorry for forgetting
>>>>>> that earlier) and you should be able to do this now.
>>>>>>
>>>>>> How we want to do this is a good question. I suppose defining
>>>>>> a release target is the way to go, and we can use that for bug
>>>>>> reporting after the branch is created as well.
>>>>>>
>>>>>> As for the version name of the release we should talk about
>>>>>> it. Thinking about it now we have discussed doing a release
>>>>>> branch once per year, and perhaps once every 2 years. Perhaps
>>>>>> we should version the release with the year? I've never liked
>>>>>> that approach a whole lot, because in many cases it is less
>>>>>> meaningful that a major/minor version number, but for OFBiz
>>>>>> the release branches are time based so perhaps a year makes
>>>>>> sense.
>>>>>>
>>>>>> If we do that this next release could simply be "release2009",
>>>>>> or if we want to be more specific and perhaps use the Ubuntu
>>>>>> model (and assuming we're planning for a release in March) we
>>>>>> could use something like "release9.3". I think I like the
>>>>>> simple release2009 better...
>>>>>>
>>>>>> Any other opinions?
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>>>>
>>>>>> David,
>>>>>> could you create the new version in JIRA so that we
>>>>>> can schedule these
>>>>>> issues on it and have them displayed in the Road Map?
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel 
>>>>>>
>>>>>> Thanks,
>>>>>> -Bruno
>>>>>>
>>>>>> 2009/1/16 David E Jones <[hidden email]>
>>>>>>
>>>>>>
>>>>>> On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>>>> wrote:
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>
>>>>>> What do we still have that is
>>>>>> up in the air for refactoring,
>>>>>> cleanups,
>>>>>> and enhancements? I know quite
>>>>>> a few have been worked on
>>>>>> recently but I'm
>>>>>> not sure of their exact
>>>>>> status, but here are some that
>>>>>> come to mind:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-1868 
>>>>>>
>>>>>>
>>>>>> Yes, that would be a good one to get done.
>>>>>>
>>>>>> There may also be other framework versus apps
>>>>>> issues that need to be
>>>>>> resolved, actually I know there are (Bruno
>>>>>> brought one up today in fact).
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>>>
>>>>>
>>>>>
>>>>
>>

[David E Jones-3]

Yes. It will be the same as the release4.0 branch, and in general  
follow the pattern/process described here:

http://docs.ofbiz.org/display/OFBADMIN/Release+Plan

-David


On Feb 2, 2009, at 9:52 AM, Vince M. Clark wrote:

> Please clarify the process. Are we continuing to work in trunk and  
> then take a snapshot in March, calling that Release Branch 9.3?
>
> ----- Original Message -----
> From: "David E Jones" <[hidden email]>
> To: [hidden email]
> Cc: "Rajib Khan" <[hidden email]>, "Guy Gershoni"  
> <[hidden email]>, "Peter Stone" <[hidden email]>
> Sent: Tuesday, January 20, 2009 1:25:17 AM (GMT-0700) America/Denver
> Subject: Re: New Release Branch (was: locale error in simple method)
>
>
> Unless I'm misunderstanding I think the answers to your questions are
> earlier in this thread. As implied by the name, the planned release
> branch date would be March 2009 (hence the 9.3, in the Ubuntu style).
>
> As for a "stable" branch with errors worked out, the comments about my
> expectations of at least three months and our experience with
> release4.0 of 6-9 months are the best answer available (AFAIK anyway).
>
> As for "safe" extensions to OFBiz... changing classes is a no-no and
> can usually be avoided by some sort of contribution with either the
> literal change you need, or something that makes the class more
> flexible so that you can intercept elsewhere with the change you need.
> In general, class extension is NOT a very good form of creating
> extended functionality that is easy to maintain, no matter what OO
> folks say. You can do a lot with the cart by creating custom request
> events instead of using the default ones, and if the ShoppingCart and
> related classes were a bit cleaner and more flexible (which has been
> discussed a number of times, even recently) then even more could be
> done.
>
> -David
>
>
> On Jan 19, 2009, at 5:59 PM, Luke Prentice wrote:
>
>> hi guys,
>>
>> my colleagues (rajib khan and guy gershoni) and have been working
>> with ofbiz
>> for over 3 years now. we're currently going through the process of
>> "upgrading" to the latest trunk of ofbiz. we've done this
>> periodically for a
>> few months and tried really hard to keep our own customisations
>> abstracted
>> out (so merges are less painful).
>>
>> i've been following this discussion with interest. because of the
>> pain of
>> merging in changes from a not-totally-stable trunk (i know that it's
>> not
>> stable -- cos it's a development trunk!) we need to decide when to
>> "cut our
>> losses" and move away from the development trunk. some of the recent
>> changes
>> have been radical enough to slow down our development significantly.
>>
>> so... we'd like to stay "connected" to the development community and
>> contribute back changes where that's useful (eg
>> https://issues.apache.org/jira/browse/OFBIZ-1906). plus we can of
>> course
>> benefit from fixes in the trunk. however, on reflection, the
>> destabilisation
>> that results from merging is too great a burden for us to keep
>> doing. (eg,
>> commit 712932 to ShoppingCart.java was a deep problem for us because
>> we're
>> extending a number of classes in this file).
>>
>> [aside: a potential discussion is whether or how can ofbiz users
>> customise
>> classes? is it bad practice? in our case we have modified the
>> shopping cart
>> because we want the OrderItem to be extended too.]
>>
>> hence my interest in this topic. specifically because our team would
>> like to
>> "lock on" to a stable release branch. we're way ahead of release
>> branch4.0
>> and have noticed release9.3 appeared recently.
>>
>> given the list of "must do" and "would like to get done" *before*
>> release9.3
>> is bedded down, what is a reasonable time frame for this to happen?
>>
>> short version: *when will release branch 9.3 be committed as stable?*
>>
>> the answer to that will determine whether we remain connected to the
>> trunk
>> and seek to commit/merge changes and "play our part" in the  
>> community.
>>
>> many thanks,
>>
>> luke.
>>
>> On Sun, Jan 18, 2009 at 6:16 PM, David E Jones
>> <[hidden email]>wrote:
>>
>>>
>>> Sounds like you're leaning towards using the trunk... ;)
>>>
>>> -David
>>>
>>>
>>>
>>> On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote:
>>>
>>> Maybe every 3 months was too optimistic. I just seems like a year
>>> is a
>>>> long
>>>> time to wait for another release. Especially if you are working
>>>> with one
>>>> of
>>>> the new ofbiz applications like workeffort and you want new
>>>> features as
>>>> they
>>>> become available..
>>>>
>>>>
>>>> Brett
>>>>
>>>> On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <
>>>> [hidden email]
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>>
>>>>> My reply to another message seems to fit this exactly:
>>>>>
>>>>> ============================================
>>>>> I'll acknowledge that more than one release per year could
>>>>> happen, but
>>>>> I'd
>>>>> be really surprised to see it happen. When a release branch is
>>>>> done it
>>>>> seems
>>>>> to take many months to back-port enough bug fixes from the trunk
>>>>> and get
>>>>> fixes in from other sources to actually make it fairly solid and
>>>>> functional.
>>>>>
>>>>> We also have the issue of update paths and scripts or whatever.
>>>>> If we
>>>>> have
>>>>> too many releases it causes a lot more confusion for prospective
>>>>> users
>>>>> about
>>>>> which release to use, and also causes more effort to maintain
>>>>> more update
>>>>> paths between releases. If we only release every 1-2 years then
>>>>> it is
>>>>> generally pretty clear which one to use.
>>>>>
>>>>> Actually, I've spelled a lot of this out a long time ago here and
>>>>> as far
>>>>> as
>>>>> general concepts and issues go I don't think much has changed:
>>>>>
>>>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
>>>>> ============================================
>>>>>
>>>>> To sum up: we could certainly try it (I'm up for trying
>>>>> anything), but I
>>>>> think with the lack of resources that a single release branch was
>>>>> able to
>>>>> rally it would be even more distracting and dispersing of
>>>>> resources to
>>>>> have
>>>>> multiple release branches close together. My guess was 3 months
>>>>> to get
>>>>> bugs
>>>>> worked out of a release branch, and I think it really took more
>>>>> like 6-9
>>>>> months for release4.0. If we do releases closer together I don't
>>>>> think
>>>>> they
>>>>> will EVER get cleaned up with the bugs worked out.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>>>>>
>>>>> I think this is good proposal.
>>>>>
>>>>>> it should be automatically scheduled.... and update script is a
>>>>>> good
>>>>>> idea...
>>>>>>
>>>>>> so please (re)read this proposal.
>>>>>>
>>>>>> Hans
>>>>>>
>>>>>> ps. the attachment not really get trough?
>>>>>>
>>>>>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>>>>>
>>>>>> Here is another proposal for release branches. Rather than
>>>>>> doing a
>>>>>>> release branch every 1 - 2 years how about doing it by calendar
>>>>>>> and
>>>>>>> releasing a new branch more frequently (e.g. every 3 months).
>>>>>>> The
>>>>>>> objective would be to stay as close to the trunk as possible
>>>>>>> while
>>>>>>> still providing stability for production releases.
>>>>>>>
>>>>>>> All appropriate fixes for the release branch would go back into
>>>>>>> the
>>>>>>> trunk. Then after 3 months we would create another release
>>>>>>> branch and
>>>>>>> start the process all over again. The community could also
>>>>>>> provide
>>>>>>> update scripts to help production deployments move from one
>>>>>>> release
>>>>>>> branch to another. This is currently a pain now and is one of
>>>>>>> the
>>>>>>> reason I think people don't update their production deployments.
>>>>>>>
>>>>>>> I'm attaching a graphic that shows how this proposal would work.
>>>>>>>
>>>>>>> I'll also put in another plug for community driven test cases.
>>>>>>> The
>>>>>>> test cases would be used to determine when the release branch  
>>>>>>> was
>>>>>>> stable enough for a recommended general release.
>>>>>>>
>>>>>>>
>>>>>>> Brett
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> I just setup your jira permissions Bruno (sorry for forgetting
>>>>>>> that earlier) and you should be able to do this now.
>>>>>>>
>>>>>>> How we want to do this is a good question. I suppose defining
>>>>>>> a release target is the way to go, and we can use that for bug
>>>>>>> reporting after the branch is created as well.
>>>>>>>
>>>>>>> As for the version name of the release we should talk about
>>>>>>> it. Thinking about it now we have discussed doing a release
>>>>>>> branch once per year, and perhaps once every 2 years. Perhaps
>>>>>>> we should version the release with the year? I've never liked
>>>>>>> that approach a whole lot, because in many cases it is less
>>>>>>> meaningful that a major/minor version number, but for OFBiz
>>>>>>> the release branches are time based so perhaps a year makes
>>>>>>> sense.
>>>>>>>
>>>>>>> If we do that this next release could simply be "release2009",
>>>>>>> or if we want to be more specific and perhaps use the Ubuntu
>>>>>>> model (and assuming we're planning for a release in March) we
>>>>>>> could use something like "release9.3". I think I like the
>>>>>>> simple release2009 better...
>>>>>>>
>>>>>>> Any other opinions?
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>>>>>
>>>>>>> David,
>>>>>>> could you create the new version in JIRA so that we
>>>>>>> can schedule these
>>>>>>> issues on it and have them displayed in the Road Map?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Bruno
>>>>>>>
>>>>>>> 2009/1/16 David E Jones <[hidden email]>
>>>>>>>
>>>>>>>
>>>>>>> On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>>>>> wrote:
>>>>>>>
>>>>>>> David E Jones wrote:
>>>>>>>
>>>>>>> What do we still have that is
>>>>>>> up in the air for refactoring,
>>>>>>> cleanups,
>>>>>>> and enhancements? I know quite
>>>>>>> a few have been worked on
>>>>>>> recently but I'm
>>>>>>> not sure of their exact
>>>>>>> status, but here are some that
>>>>>>> come to mind:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-1868
>>>>>>>
>>>>>>>
>>>>>>> Yes, that would be a good one to get done.
>>>>>>>
>>>>>>> There may also be other framework versus apps
>>>>>>> issues that need to be
>>>>>>> resolved, actually I know there are (Bruno
>>>>>>> brought one up today in fact).
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>

[Bruno Busco]

Anyway, according to the road-map we should try to have those implemented:

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310500&fixfor=12313602

-Bruno

2009/2/2 David E Jones <[hidden email]>

>
> Yes. It will be the same as the release4.0 branch, and in general follow
> the pattern/process described here:
>
> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
>
> -David
>
>
>
> On Feb 2, 2009, at 9:52 AM, Vince M. Clark wrote:
>
>  Please clarify the process. Are we continuing to work in trunk and then
>> take a snapshot in March, calling that Release Branch 9.3?
>>
>> ----- Original Message -----
>> From: "David E Jones" <[hidden email]>
>> To: [hidden email]
>> Cc: "Rajib Khan" <[hidden email]>, "Guy Gershoni" <[hidden email]>,
>> "Peter Stone" <[hidden email]>
>> Sent: Tuesday, January 20, 2009 1:25:17 AM (GMT-0700) America/Denver
>> Subject: Re: New Release Branch (was: locale error in simple method)
>>
>>
>> Unless I'm misunderstanding I think the answers to your questions are
>> earlier in this thread. As implied by the name, the planned release
>> branch date would be March 2009 (hence the 9.3, in the Ubuntu style).
>>
>> As for a "stable" branch with errors worked out, the comments about my
>> expectations of at least three months and our experience with
>> release4.0 of 6-9 months are the best answer available (AFAIK anyway).
>>
>> As for "safe" extensions to OFBiz... changing classes is a no-no and
>> can usually be avoided by some sort of contribution with either the
>> literal change you need, or something that makes the class more
>> flexible so that you can intercept elsewhere with the change you need.
>> In general, class extension is NOT a very good form of creating
>> extended functionality that is easy to maintain, no matter what OO
>> folks say. You can do a lot with the cart by creating custom request
>> events instead of using the default ones, and if the ShoppingCart and
>> related classes were a bit cleaner and more flexible (which has been
>> discussed a number of times, even recently) then even more could be
>> done.
>>
>> -David
>>
>>
>> On Jan 19, 2009, at 5:59 PM, Luke Prentice wrote:
>>
>>  hi guys,
>>>
>>> my colleagues (rajib khan and guy gershoni) and have been working
>>> with ofbiz
>>> for over 3 years now. we're currently going through the process of
>>> "upgrading" to the latest trunk of ofbiz. we've done this
>>> periodically for a
>>> few months and tried really hard to keep our own customisations
>>> abstracted
>>> out (so merges are less painful).
>>>
>>> i've been following this discussion with interest. because of the
>>> pain of
>>> merging in changes from a not-totally-stable trunk (i know that it's
>>> not
>>> stable -- cos it's a development trunk!) we need to decide when to
>>> "cut our
>>> losses" and move away from the development trunk. some of the recent
>>> changes
>>> have been radical enough to slow down our development significantly.
>>>
>>> so... we'd like to stay "connected" to the development community and
>>> contribute back changes where that's useful (eg
>>> https://issues.apache.org/jira/browse/OFBIZ-1906). plus we can of
>>> course
>>> benefit from fixes in the trunk. however, on reflection, the
>>> destabilisation
>>> that results from merging is too great a burden for us to keep
>>> doing. (eg,
>>> commit 712932 to ShoppingCart.java was a deep problem for us because
>>> we're
>>> extending a number of classes in this file).
>>>
>>> [aside: a potential discussion is whether or how can ofbiz users
>>> customise
>>> classes? is it bad practice? in our case we have modified the
>>> shopping cart
>>> because we want the OrderItem to be extended too.]
>>>
>>> hence my interest in this topic. specifically because our team would
>>> like to
>>> "lock on" to a stable release branch. we're way ahead of release
>>> branch4.0
>>> and have noticed release9.3 appeared recently.
>>>
>>> given the list of "must do" and "would like to get done" *before*
>>> release9.3
>>> is bedded down, what is a reasonable time frame for this to happen?
>>>
>>> short version: *when will release branch 9.3 be committed as stable?*
>>>
>>> the answer to that will determine whether we remain connected to the
>>> trunk
>>> and seek to commit/merge changes and "play our part" in the community.
>>>
>>> many thanks,
>>>
>>> luke.
>>>
>>> On Sun, Jan 18, 2009 at 6:16 PM, David E Jones
>>> <[hidden email]>wrote:
>>>
>>>
>>>> Sounds like you're leaning towards using the trunk... ;)
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>> On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote:
>>>>
>>>> Maybe every 3 months was too optimistic. I just seems like a year
>>>> is a
>>>>
>>>>> long
>>>>> time to wait for another release. Especially if you are working
>>>>> with one
>>>>> of
>>>>> the new ofbiz applications like workeffort and you want new
>>>>> features as
>>>>> they
>>>>> become available..
>>>>>
>>>>>
>>>>> Brett
>>>>>
>>>>> On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <
>>>>> [hidden email]
>>>>>
>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>
>>>>>  My reply to another message seems to fit this exactly:
>>>>>>
>>>>>> ============================================
>>>>>> I'll acknowledge that more than one release per year could
>>>>>> happen, but
>>>>>> I'd
>>>>>> be really surprised to see it happen. When a release branch is
>>>>>> done it
>>>>>> seems
>>>>>> to take many months to back-port enough bug fixes from the trunk
>>>>>> and get
>>>>>> fixes in from other sources to actually make it fairly solid and
>>>>>> functional.
>>>>>>
>>>>>> We also have the issue of update paths and scripts or whatever.
>>>>>> If we
>>>>>> have
>>>>>> too many releases it causes a lot more confusion for prospective
>>>>>> users
>>>>>> about
>>>>>> which release to use, and also causes more effort to maintain
>>>>>> more update
>>>>>> paths between releases. If we only release every 1-2 years then
>>>>>> it is
>>>>>> generally pretty clear which one to use.
>>>>>>
>>>>>> Actually, I've spelled a lot of this out a long time ago here and
>>>>>> as far
>>>>>> as
>>>>>> general concepts and issues go I don't think much has changed:
>>>>>>
>>>>>> http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
>>>>>> ============================================
>>>>>>
>>>>>> To sum up: we could certainly try it (I'm up for trying
>>>>>> anything), but I
>>>>>> think with the lack of resources that a single release branch was
>>>>>> able to
>>>>>> rally it would be even more distracting and dispersing of
>>>>>> resources to
>>>>>> have
>>>>>> multiple release branches close together. My guess was 3 months
>>>>>> to get
>>>>>> bugs
>>>>>> worked out of a release branch, and I think it really took more
>>>>>> like 6-9
>>>>>> months for release4.0. If we do releases closer together I don't
>>>>>> think
>>>>>> they
>>>>>> will EVER get cleaned up with the bugs worked out.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
>>>>>>
>>>>>> I think this is good proposal.
>>>>>>
>>>>>>  it should be automatically scheduled.... and update script is a
>>>>>>> good
>>>>>>> idea...
>>>>>>>
>>>>>>> so please (re)read this proposal.
>>>>>>>
>>>>>>> Hans
>>>>>>>
>>>>>>> ps. the attachment not really get trough?
>>>>>>>
>>>>>>> On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
>>>>>>>
>>>>>>> Here is another proposal for release branches. Rather than
>>>>>>> doing a
>>>>>>>
>>>>>>>> release branch every 1 - 2 years how about doing it by calendar
>>>>>>>> and
>>>>>>>> releasing a new branch more frequently (e.g. every 3 months).
>>>>>>>> The
>>>>>>>> objective would be to stay as close to the trunk as possible
>>>>>>>> while
>>>>>>>> still providing stability for production releases.
>>>>>>>>
>>>>>>>> All appropriate fixes for the release branch would go back into
>>>>>>>> the
>>>>>>>> trunk. Then after 3 months we would create another release
>>>>>>>> branch and
>>>>>>>> start the process all over again. The community could also
>>>>>>>> provide
>>>>>>>> update scripts to help production deployments move from one
>>>>>>>> release
>>>>>>>> branch to another. This is currently a pain now and is one of
>>>>>>>> the
>>>>>>>> reason I think people don't update their production deployments.
>>>>>>>>
>>>>>>>> I'm attaching a graphic that shows how this proposal would work.
>>>>>>>>
>>>>>>>> I'll also put in another plug for community driven test cases.
>>>>>>>> The
>>>>>>>> test cases would be used to determine when the release branch was
>>>>>>>> stable enough for a recommended general release.
>>>>>>>>
>>>>>>>>
>>>>>>>> Brett
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
>>>>>>>> <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> I just setup your jira permissions Bruno (sorry for forgetting
>>>>>>>> that earlier) and you should be able to do this now.
>>>>>>>>
>>>>>>>> How we want to do this is a good question. I suppose defining
>>>>>>>> a release target is the way to go, and we can use that for bug
>>>>>>>> reporting after the branch is created as well.
>>>>>>>>
>>>>>>>> As for the version name of the release we should talk about
>>>>>>>> it. Thinking about it now we have discussed doing a release
>>>>>>>> branch once per year, and perhaps once every 2 years. Perhaps
>>>>>>>> we should version the release with the year? I've never liked
>>>>>>>> that approach a whole lot, because in many cases it is less
>>>>>>>> meaningful that a major/minor version number, but for OFBiz
>>>>>>>> the release branches are time based so perhaps a year makes
>>>>>>>> sense.
>>>>>>>>
>>>>>>>> If we do that this next release could simply be "release2009",
>>>>>>>> or if we want to be more specific and perhaps use the Ubuntu
>>>>>>>> model (and assuming we're planning for a release in March) we
>>>>>>>> could use something like "release9.3". I think I like the
>>>>>>>> simple release2009 better...
>>>>>>>>
>>>>>>>> Any other opinions?
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
>>>>>>>>
>>>>>>>> David,
>>>>>>>> could you create the new version in JIRA so that we
>>>>>>>> can schedule these
>>>>>>>> issues on it and have them displayed in the Road Map?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Bruno
>>>>>>>>
>>>>>>>> 2009/1/16 David E Jones <[hidden email]>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 15, 2009, at 3:33 PM, Adrian Crum
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> David E Jones wrote:
>>>>>>>>
>>>>>>>> What do we still have that is
>>>>>>>> up in the air for refactoring,
>>>>>>>> cleanups,
>>>>>>>> and enhancements? I know quite
>>>>>>>> a few have been worked on
>>>>>>>> recently but I'm
>>>>>>>> not sure of their exact
>>>>>>>> status, but here are some that
>>>>>>>> come to mind:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-1868
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, that would be a good one to get done.
>>>>>>>>
>>>>>>>> There may also be other framework versus apps
>>>>>>>> issues that need to be
>>>>>>>> resolved, actually I know there are (Bruno
>>>>>>>> brought one up today in fact).
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>  Antwebsystems.com: Quality OFBiz services for competitive prices
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>