Best practices for updates from trunk

[Matt Warnock <mw...@ridgecrestherbals.com>]

I run a small enterprise and I doubt our needs are unusual.  We would
like to run trunk and stay (more or less) current.  We're running
postgresql as a backend.  I'm hoping to automate (as much as possible)
the update process.  I'm hoping to implement a few things not provided
in the standard demo setup.

1) I need to backup the database nightly, so that our daily work doesn't
get lost (doh!).  I can use pg_dump for that, but of course it backs up
the entire database, including seed, admin-user-login, and site-specific
data.  I could also use the webtools dump, which I assume does the exact
same thing but in XML, which is a good deal larger in file size.
However, webtools won't write an XML file for an empty table, while
pg_dump would write a structure definition for that table.  Probably
pg_dump would be a good deal faster.  Size and speed issues aside, it
seems that neither method differentiates in any way between seed and
non-seed data. Am I correct here?

2) To effectively use the webtools backup, I would need to automate it
from a cron job.  Is there an easy way to call ofbiz services from the
command line, or do I need to schedule a job within OFBiz to do this
kind of thing?  What are the pros and cons of a system cron job vs. a
scheduled job in OFBiz?

3) I need a log of what version I was running when.  For example, if I
update weekly, and on Sunday night I roll forward to the latest trunk
revision 970999, and it breaks something, I need to have a log that
tells me that Friday (when it worked) I was running 970888, so I can
roll back to that revision, until I get the kinks worked out with the
upgrade.  Otherwise I have to restore from a dated backup, which I can
always do, but it seems that a simple "svn checkout 970888; ./ant build"
might be cleaner.  I'm assuming that after updating the code with "svn
checkout" I can log the date/time to a file with the output of "svn
info".   

4) If a revision requires a database update or modification, I would
like to know about it in advance, and make sure that manual modification
is completed before the upgrade.  I'm assuming what I need there should
always be found in:
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring
+Data+Migration

5) I would like to update all seed data in place (postgresql) without
overwriting the rest of the (non-seed) data.  Will executing "./ant
run-install-seed" overwrite the EXISTING seed data in a production
database without affecting the non-seed data?  Or it it only intended
for use on an empty database, as all the examples I have found do? If
the latter, how do you restore only the NON-seed data after a seed data
initialization?

Are there any other bear traps or best practices that I should be aware
of?  Or is this stuff documented somewhere that I have not found?  There
was a discussion of it (at least the seed vs. demo data issue) about a
year ago on this list, but I didn't see these specific questions
answered.  

Or am I overly optimistic about the possibility of updating a production
system regularly as OFBiz trunk changes?

Thanks in advance.

Re: Best practices for updates from trunk

[Matt Warnock <mw...@ridgecrestherbals.com>]

Thanks David!

At the moment, we only have a few people (4-5 max) that really use the
system, and none of those really "full-time" like a dedicated data entry
person would.  So perhaps we can afford to be more lax, or expedite the
testing.  We certainly don't need the extensive testing cycle that would
be needed for enterprises with more riding on a "deployment".  An
"agile" model would probably work well for us for the time being-- the
question is how best to implement it. 

Reading between the lines, it sounds like in-place seed data updates are
either impossible or problematic in practice, and are not recommended.  

So perhaps we need to look at freezing the entity defs as you suggest,
then perhaps automating a diff on any entity definition changes to make
sure they are properly scrutinized (and manually implemented) before any
corresponding code update.

-- 
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.

On Mon, 2010-08-30 at 18:07 -0600, David E Jones wrote:
> Matt,
> 
> I wouldn't recommend updating a production instance against the trunk
>  without testing. I generally do recommend to clients who are doing
>  customizations or building on top of OFBiz that they update against
>  the trunk frequently during development, and then stop before
>  integration (general system) testing, or at least stop for their
>  release candidate branch and continue updating against the OFBiz trunk
>  for their development branch.
> 
> As for database changes, the Revisions+Requiring+Data+Migration page is
>  manually updated and therefore not totally reliable. I'd recommend
>  running the Check/Update database stuff in the Entity Engine by
>  changing your entityengine.xml file to not automatically update
>  anything (ie don't add new tables or columns, etc), and then look at
>  the startup log or use webtools to see the differences between the
>  current entity definitions and the meta-data in your database.
> 
> -David
> 

> On Aug 30, 2010, at 3:12 PM, Matt Warnock wrote:
> 
> > I run a small enterprise and I doubt our needs are unusual.  We would
> > like to run trunk and stay (more or less) current.  We're running
> > postgresql as a backend.  I'm hoping to automate (as much as possible)
> > the update process.  I'm hoping to implement a few things not provided
> > in the standard demo setup.
> > 
> > 1) I need to backup the database nightly, so that our daily work doesn't
> > get lost (doh!).  I can use pg_dump for that, but of course it backs up
> > the entire database, including seed, admin-user-login, and site-specific
> > data.  I could also use the webtools dump, which I assume does the exact
> > same thing but in XML, which is a good deal larger in file size.
> > However, webtools won't write an XML file for an empty table, while
> > pg_dump would write a structure definition for that table.  Probably
> > pg_dump would be a good deal faster.  Size and speed issues aside, it
> > seems that neither method differentiates in any way between seed and
> > non-seed data. Am I correct here?
> > 
> > 2) To effectively use the webtools backup, I would need to automate it
> > from a cron job.  Is there an easy way to call ofbiz services from the
> > command line, or do I need to schedule a job within OFBiz to do this
> > kind of thing?  What are the pros and cons of a system cron job vs. a
> > scheduled job in OFBiz?
> > 
> > 3) I need a log of what version I was running when.  For example, if I
> > update weekly, and on Sunday night I roll forward to the latest trunk
> > revision 970999, and it breaks something, I need to have a log that
> > tells me that Friday (when it worked) I was running 970888, so I can
> > roll back to that revision, until I get the kinks worked out with the
> > upgrade.  Otherwise I have to restore from a dated backup, which I can
> > always do, but it seems that a simple "svn checkout 970888; ./ant build"
> > might be cleaner.  I'm assuming that after updating the code with "svn
> > checkout" I can log the date/time to a file with the output of "svn
> > info".   
> > 
> > 4) If a revision requires a database update or modification, I would
> > like to know about it in advance, and make sure that manual modification
> > is completed before the upgrade.  I'm assuming what I need there should
> > always be found in:
> > https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring
> > +Data+Migration
> > 
> > 5) I would like to update all seed data in place (postgresql) without
> > overwriting the rest of the (non-seed) data.  Will executing "./ant
> > run-install-seed" overwrite the EXISTING seed data in a production
> > database without affecting the non-seed data?  Or it it only intended
> > for use on an empty database, as all the examples I have found do? If
> > the latter, how do you restore only the NON-seed data after a seed data
> > initialization?
> > 
> > Are there any other bear traps or best practices that I should be aware
> > of?  Or is this stuff documented somewhere that I have not found?  There
> > was a discussion of it (at least the seed vs. demo data issue) about a
> > year ago on this list, but I didn't see these specific questions
> > answered.  
> > 
> > Or am I overly optimistic about the possibility of updating a production
> > system regularly as OFBiz trunk changes?
> > 
> > Thanks in advance.
> > 

Re: Best practices for updates from trunk

[David E Jones <de...@me.com>]

Matt,

I wouldn't recommend updating a production instance against the trunk without testing. I generally do recommend to clients who are doing customizations or building on top of OFBiz that they update against the trunk frequently during development, and then stop before integration (general system) testing, or at least stop for their release candidate branch and continue updating against the OFBiz trunk for their development branch.

As for database changes, the Revisions+Requiring+Data+Migration page is manually updated and therefore not totally reliable. I'd recommend running the Check/Update database stuff in the Entity Engine by changing your entityengine.xml file to not automatically update anything (ie don't add new tables or columns, etc), and then look at the startup log or use webtools to see the differences between the current entity definitions and the meta-data in your database.

-David


On Aug 30, 2010, at 3:12 PM, Matt Warnock wrote:

> I run a small enterprise and I doubt our needs are unusual.  We would
> like to run trunk and stay (more or less) current.  We're running
> postgresql as a backend.  I'm hoping to automate (as much as possible)
> the update process.  I'm hoping to implement a few things not provided
> in the standard demo setup.
> 
> 1) I need to backup the database nightly, so that our daily work doesn't
> get lost (doh!).  I can use pg_dump for that, but of course it backs up
> the entire database, including seed, admin-user-login, and site-specific
> data.  I could also use the webtools dump, which I assume does the exact
> same thing but in XML, which is a good deal larger in file size.
> However, webtools won't write an XML file for an empty table, while
> pg_dump would write a structure definition for that table.  Probably
> pg_dump would be a good deal faster.  Size and speed issues aside, it
> seems that neither method differentiates in any way between seed and
> non-seed data. Am I correct here?
> 
> 2) To effectively use the webtools backup, I would need to automate it
> from a cron job.  Is there an easy way to call ofbiz services from the
> command line, or do I need to schedule a job within OFBiz to do this
> kind of thing?  What are the pros and cons of a system cron job vs. a
> scheduled job in OFBiz?
> 
> 3) I need a log of what version I was running when.  For example, if I
> update weekly, and on Sunday night I roll forward to the latest trunk
> revision 970999, and it breaks something, I need to have a log that
> tells me that Friday (when it worked) I was running 970888, so I can
> roll back to that revision, until I get the kinks worked out with the
> upgrade.  Otherwise I have to restore from a dated backup, which I can
> always do, but it seems that a simple "svn checkout 970888; ./ant build"
> might be cleaner.  I'm assuming that after updating the code with "svn
> checkout" I can log the date/time to a file with the output of "svn
> info".   
> 
> 4) If a revision requires a database update or modification, I would
> like to know about it in advance, and make sure that manual modification
> is completed before the upgrade.  I'm assuming what I need there should
> always be found in:
> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring
> +Data+Migration
> 
> 5) I would like to update all seed data in place (postgresql) without
> overwriting the rest of the (non-seed) data.  Will executing "./ant
> run-install-seed" overwrite the EXISTING seed data in a production
> database without affecting the non-seed data?  Or it it only intended
> for use on an empty database, as all the examples I have found do? If
> the latter, how do you restore only the NON-seed data after a seed data
> initialization?
> 
> Are there any other bear traps or best practices that I should be aware
> of?  Or is this stuff documented somewhere that I have not found?  There
> was a discussion of it (at least the seed vs. demo data issue) about a
> year ago on this list, but I didn't see these specific questions
> answered.  
> 
> Or am I overly optimistic about the possibility of updating a production
> system regularly as OFBiz trunk changes?
> 
> Thanks in advance.
> 

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

Fortunately we have now Selenium and Junit. We should be able to do better, but you are right, it's not a simple task and moreover 
not very appealing for most of ordinary mortals

Jacques

From: "BJ Freeman" <bj...@free-man.net>
> ah yes I do remember win9x, I was on the Microsoft Campus during the
> time working on a different project.
> there was a room of about 200 machines of different configurations
> (speed, memory, os settings) that ran the application under test.
> There were no tester but Test engineers(5-20) that built test scenarios
> in Microsoft own Test software. Their software tested from the UI down
> to the core subroutines.
> if something was broke is was given a priority as blocking to trivial
> like jira.
> this just set what was worked on first. however all were resolved.
>
> let me say I am not saying that ofbiz should be at this level, only that
> it should be accurate about what is the reality of ofbiz state.
>
> and yes since 2002 ofbiz has come a long way and most of the newbies
> don't know what they missed (cough cough).
>
>
>
>
> =========================
> BJ Freeman  <http://bjfreeman.elance.com>
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
>
>
> Jacques Le Roux sent the following on 8/31/2010 10:22 AM:
>> From: "BJ Freeman" <bj...@free-man.net>
>>> I am Glad for this discussion.
>>> My years on Design teams had a lot different criteria.
>>>
>>> so to Summarize if something is broke and no one wants to work on it,
>>> it is not considered a bug.
>>
>> I don't think so, it's considered a bug but not a blocking nor a
>> critical one.
>>
>>> As far as buildbot it is only as good as the tests written that it
>>> uses and as was pointed out on the dev list ofbiz UI and minilanq is
>>> not tested, as in the math error.
>>>
>>> So the fact it "passed" a build only says the test so far, don't fail,
>>> not that ofbiz is bug free.
>>
>> I was told one day (15 years ago, I guess), that, at this time, for Word
>> (remember Window 95, tadaaa...), Microsoft had a team of 10 to 20 devs
>> and at all between 120 to 150 persons Still the testers/dev ratio was
>> less than 10 (much administrative people too make the glue). At the NASA
>> (not sure the period), for embedded software the ratio was 100! But
>> don't take me wrong, I don't mean that we need more bureaucracy ;o)
>>
>>> reminds me of a used car salesman.
>>
>> I never get there, else I buy a new one (I did once), or rather I buy it
>> from owner to owner (I know mechanic).
>> Anyway, it's still far better than what he had a couple years ago (not
>> my car)... Hopefully it will be far better in 2 years (still not my car)...
>>
>> Jacques
>>
>>>
>>> =========================
>>> BJ Freeman <http://bjfreeman.elance.com>
>>> Strategic Power Office with Supplier Automation
>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>> Systems Integrator-- Glad to Assist
>>>
>>> Chat Y! messenger: bjfr33man
>>> Scott Gray sent the following on 8/31/2010 2:56 AM:
>>>
>>>> OFBIZ-3912 is a good example of an issue that is critical to an
>>>> individual rather than the community I think. A good indicator is
>>>> that it has been broken for 5 months before being reported, can't be
>>>> that critical then huh?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 31/08/2010, at 9:45 PM, Jacques Le Roux wrote:
>>>>
>>>>> Scott Gray wrote:
>>>>>> A blocking bug IMO is nothing more than the community (rather than
>>>>>> an individual) deciding that a bug is important enough that a
>>>>>> release shouldn't occur until it is fixed. I don't think we need
>>>>>> any criteria other than that really.
>>>>>
>>>>> Yes that's fine to me. And a critical (for instance at
>>>>> https://issues.apache.org/jira/browse/OFBIZ-3912)?
>>>>>
>>>>> Jacques
>>>>>> Regards
>>>>>> Scott
>>>>>> On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:
>>>>>>> Hey Scott, that's right!
>>>>>>> Happy to close this one. So eventually you were right, there are
>>>>>>> ANY blocking bugs in OFBiz under our criteria ;o)
>>>>>>> Though I guess we should better define our criteria for blocking.
>>>>>>> Because if we allow to use blocking only for bugs blocking all
>>>>>>> OFBiz there should be hardly any such bugs. I mean it would be
>>>>>>> very, very quickly fixed and we would have hardly the time to
>>>>>>> create a blocking bug. Notbaly because we have now BuildBot
>>>>>>> running and all commiters are quickly aware of any errors they
>>>>>>> woulds have made. Did you thought about it Scott, what is your
>>>>>>> perception? Thanks
>>>>>>> Jacques
>>>>>>> Scott Gray wrote:
>>>>>>>> Hi Jacques,
>>>>>>>> I thought you fixed OFBIZ-3837 recently? Or was that some other
>>>>>>>> shipping estimate problem you were working on?
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>>>>>>>>> There are currently 275 UNRESOLVED bugs, 11 have patches
>>>>>>>>> available, 14 are reopened.
>>>>>>>>> This is againt all versions. There are only 78 for trunk but
>>>>>>>>> this is not a reliable criteria (if any are)
>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as
>>>>>>>>> blocking. But I guess not under Scott's criteria (it's not
>>>>>>>>> blocking OFBiz, just blocking a part of it, so it's critical
>>>>>>>>> actually) 4 are critical and 173 major
>>>>>>>>> No needs to say that any help to clean things would be really
>>>>>>>>> appreciated...
>>>>>>>>> HTH
>>>>>>>>> Jacques
>>>>>>>>> From: "BJ Freeman"<bj...@free-man.net>
>>>>>>>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>>>>>>>> =========================
>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>>
>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>>>>>>>> Actually I meant a response to it like there are no bugs that
>>>>>>>>>>> fit this
>>>>>>>>>>> condition.
>>>>>>>>>>> =========================
>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>> Strategic Power Office with Supplier Automation
>>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>>>>>>>>> You missed something by reading an email from a community
>>>>>>>>>>>> member and
>>>>>>>>>>>> interpreting it's contents as some sort of official policy.
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Scott
>>>>>>>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>>>>>>>>> I was reffering to this:
>>>>>>>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>>>>>>>> I guess the basic questions might be: Did we have an
>>>>>>>>>>>>>> official "freeze"
>>>>>>>>>>>>>> process where we only accepted bug fixes against that
>>>>>>>>>>>>>> branch? Do we
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>>>>>>>> I agree. At least *all* bugs should be looked at, and given
>>>>>>>>>>>>> a target
>>>>>>>>>>>>> release tag, etc. Time for some bug triage. I don't think
>>>>>>>>>>>>> there has
>>>>>>>>>>>>> been a concerted effort like that in like, forever.
>>>>>>>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>>>>>>>> Have I missed something?
>>>>>>>>>>>>> =========================
>>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>>>>>>>>> There are a number of bugs that have to be resolved before
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> remember this is a volunteer effort so there is no full
>>>>>>>>>>>>>>> time person
>>>>>>>>>>>>>>> doing the patches for the bugs.
>>>>>>>>>>>>>> What are you basing this on?
>>>>>>>>>>>>>>> once they are completed and testing has been done then
>>>>>>>>>>>>>>> there will
>>>>>>>>>>>>>>> be a release.
>>>>>>>>>>>>>>> right now we are about 4 months past the planned release
>>>>>>>>>>>>>>> date.
>>>>>>>>>>>>>> What are you basing this on? Maybe there is some
>>>>>>>>>>>>>> confusion... the
>>>>>>>>>>>>>> date on a release is the date it was branched from the
>>>>>>>>>>>>>> trunk, not
>>>>>>>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>>>>>>>> -David
>>>>>>>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected
>>>>>>>>>>>>>>>> release date?
>>>>>>>>>>>>>>>> Just curious.
>>>>>
>>>>
>>>
>>
>>
>>
> 

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

ah yes I do remember win9x, I was on the Microsoft Campus during the 
time working on a different project.
there was a room of about 200 machines of different configurations 
(speed, memory, os settings) that ran the application under test.
There were no tester but Test engineers(5-20) that built test scenarios 
in Microsoft own Test software. Their software tested from the UI down 
to the core subroutines.
if something was broke is was given a priority as blocking to trivial 
like jira.
this just set what was worked on first. however all were resolved.

let me say I am not saying that ofbiz should be at this level, only that 
it should be accurate about what is the reality of ofbiz state.

and yes since 2002 ofbiz has come a long way and most of the newbies 
don't know what they missed (cough cough).




=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Jacques Le Roux sent the following on 8/31/2010 10:22 AM:
> From: "BJ Freeman" <bj...@free-man.net>
>> I am Glad for this discussion.
>> My years on Design teams had a lot different criteria.
>>
>> so to Summarize if something is broke and no one wants to work on it,
>> it is not considered a bug.
>
> I don't think so, it's considered a bug but not a blocking nor a
> critical one.
>
>> As far as buildbot it is only as good as the tests written that it
>> uses and as was pointed out on the dev list ofbiz UI and minilanq is
>> not tested, as in the math error.
>>
>> So the fact it "passed" a build only says the test so far, don't fail,
>> not that ofbiz is bug free.
>
> I was told one day (15 years ago, I guess), that, at this time, for Word
> (remember Window 95, tadaaa...), Microsoft had a team of 10 to 20 devs
> and at all between 120 to 150 persons Still the testers/dev ratio was
> less than 10 (much administrative people too make the glue). At the NASA
> (not sure the period), for embedded software the ratio was 100! But
> don't take me wrong, I don't mean that we need more bureaucracy ;o)
>
>> reminds me of a used car salesman.
>
> I never get there, else I buy a new one (I did once), or rather I buy it
> from owner to owner (I know mechanic).
> Anyway, it's still far better than what he had a couple years ago (not
> my car)... Hopefully it will be far better in 2 years (still not my car)...
>
> Jacques
>
>>
>> =========================
>> BJ Freeman <http://bjfreeman.elance.com>
>> Strategic Power Office with Supplier Automation
>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com <http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat Y! messenger: bjfr33man
>> Scott Gray sent the following on 8/31/2010 2:56 AM:
>>
>>> OFBIZ-3912 is a good example of an issue that is critical to an
>>> individual rather than the community I think. A good indicator is
>>> that it has been broken for 5 months before being reported, can't be
>>> that critical then huh?
>>>
>>> Regards
>>> Scott
>>>
>>> On 31/08/2010, at 9:45 PM, Jacques Le Roux wrote:
>>>
>>>> Scott Gray wrote:
>>>>> A blocking bug IMO is nothing more than the community (rather than
>>>>> an individual) deciding that a bug is important enough that a
>>>>> release shouldn't occur until it is fixed. I don't think we need
>>>>> any criteria other than that really.
>>>>
>>>> Yes that's fine to me. And a critical (for instance at
>>>> https://issues.apache.org/jira/browse/OFBIZ-3912)?
>>>>
>>>> Jacques
>>>>> Regards
>>>>> Scott
>>>>> On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:
>>>>>> Hey Scott, that's right!
>>>>>> Happy to close this one. So eventually you were right, there are
>>>>>> ANY blocking bugs in OFBiz under our criteria ;o)
>>>>>> Though I guess we should better define our criteria for blocking.
>>>>>> Because if we allow to use blocking only for bugs blocking all
>>>>>> OFBiz there should be hardly any such bugs. I mean it would be
>>>>>> very, very quickly fixed and we would have hardly the time to
>>>>>> create a blocking bug. Notbaly because we have now BuildBot
>>>>>> running and all commiters are quickly aware of any errors they
>>>>>> woulds have made. Did you thought about it Scott, what is your
>>>>>> perception? Thanks
>>>>>> Jacques
>>>>>> Scott Gray wrote:
>>>>>>> Hi Jacques,
>>>>>>> I thought you fixed OFBIZ-3837 recently? Or was that some other
>>>>>>> shipping estimate problem you were working on?
>>>>>>> Regards
>>>>>>> Scott
>>>>>>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>>>>>>>> There are currently 275 UNRESOLVED bugs, 11 have patches
>>>>>>>> available, 14 are reopened.
>>>>>>>> This is againt all versions. There are only 78 for trunk but
>>>>>>>> this is not a reliable criteria (if any are)
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as
>>>>>>>> blocking. But I guess not under Scott's criteria (it's not
>>>>>>>> blocking OFBiz, just blocking a part of it, so it's critical
>>>>>>>> actually) 4 are critical and 173 major
>>>>>>>> No needs to say that any help to clean things would be really
>>>>>>>> appreciated...
>>>>>>>> HTH
>>>>>>>> Jacques
>>>>>>>> From: "BJ Freeman"<bj...@free-man.net>
>>>>>>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>>>>>>> =========================
>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>
>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>>>>>>> Actually I meant a response to it like there are no bugs that
>>>>>>>>>> fit this
>>>>>>>>>> condition.
>>>>>>>>>> =========================
>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>> Strategic Power Office with Supplier Automation
>>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>>>>>>>> You missed something by reading an email from a community
>>>>>>>>>>> member and
>>>>>>>>>>> interpreting it's contents as some sort of official policy.
>>>>>>>>>>> Regards
>>>>>>>>>>> Scott
>>>>>>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>>>>>>>> I was reffering to this:
>>>>>>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>>>>>>> I guess the basic questions might be: Did we have an
>>>>>>>>>>>>> official "freeze"
>>>>>>>>>>>>> process where we only accepted bug fixes against that
>>>>>>>>>>>>> branch? Do we
>>>>>>>>>>>>> have
>>>>>>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>>>>>>> I agree. At least *all* bugs should be looked at, and given
>>>>>>>>>>>> a target
>>>>>>>>>>>> release tag, etc. Time for some bug triage. I don't think
>>>>>>>>>>>> there has
>>>>>>>>>>>> been a concerted effort like that in like, forever.
>>>>>>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>>>>>>> Have I missed something?
>>>>>>>>>>>> =========================
>>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>>>>
>>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>>>>>>>> There are a number of bugs that have to be resolved before
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>> remember this is a volunteer effort so there is no full
>>>>>>>>>>>>>> time person
>>>>>>>>>>>>>> doing the patches for the bugs.
>>>>>>>>>>>>> What are you basing this on?
>>>>>>>>>>>>>> once they are completed and testing has been done then
>>>>>>>>>>>>>> there will
>>>>>>>>>>>>>> be a release.
>>>>>>>>>>>>>> right now we are about 4 months past the planned release
>>>>>>>>>>>>>> date.
>>>>>>>>>>>>> What are you basing this on? Maybe there is some
>>>>>>>>>>>>> confusion... the
>>>>>>>>>>>>> date on a release is the date it was branched from the
>>>>>>>>>>>>> trunk, not
>>>>>>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>>>>>>> -David
>>>>>>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected
>>>>>>>>>>>>>>> release date?
>>>>>>>>>>>>>>> Just curious.
>>>>
>>>
>>
>
>
>

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

From: "BJ Freeman" <bj...@free-man.net>
>I am Glad for this discussion.
> My years on Design teams had a lot different criteria.
>
> so to Summarize if something is broke and no one wants to work on it, it is not considered a bug.

I don't think so, it's considered a bug but not a blocking nor a critical one.

> As far as buildbot it is only as good as the tests written that it uses and as was pointed out on the dev list ofbiz UI and 
> minilanq is not tested, as in the math error.
>
> So the fact it "passed" a build only says the test so far, don't fail, not that ofbiz is bug free.

I was told one day (15 years ago, I guess), that, at this time, for Word (remember Window 95, tadaaa...), Microsoft had a team of 10 
to 20 devs and at all between 120 to 150 persons Still the testers/dev ratio was less than 10 (much administrative people too make 
the glue). At the NASA (not sure the period), for embedded software the ratio was 100! But don't take me wrong, I don't mean that we 
need more bureaucracy ;o)

> reminds me of a used car salesman.

I never get there, else I buy a new one (I did once), or rather I buy it from owner to owner (I know mechanic).
Anyway, it's still far better than what he had a couple years ago (not my car)... Hopefully it will be far better in 2 years (still 
not my car)...

Jacques

>
> =========================
> BJ Freeman  <http://bjfreeman.elance.com>
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
> Scott Gray sent the following on 8/31/2010 2:56 AM:
>
>> OFBIZ-3912 is a good example of an issue that is critical to an individual rather than the community I think.  A good indicator 
>> is that it has been broken for 5 months before being reported, can't be that critical then huh?
>>
>> Regards
>> Scott
>>
>> On 31/08/2010, at 9:45 PM, Jacques Le Roux wrote:
>>
>>> Scott Gray wrote:
>>>> A blocking bug IMO is nothing more than the community (rather than an individual) deciding that a bug is important enough that 
>>>> a
>>>> release shouldn't occur until it is fixed.  I don't think we need any criteria other than that really.
>>>
>>> Yes that's fine to me. And a critical (for instance at https://issues.apache.org/jira/browse/OFBIZ-3912)?
>>>
>>> Jacques
>>>> Regards
>>>> Scott
>>>> On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:
>>>>> Hey Scott, that's right!
>>>>> Happy to close this one. So eventually you were right, there are ANY blocking bugs in OFBiz under our criteria ;o)
>>>>> Though I guess we should better define our criteria for blocking. Because if we allow to use blocking only for bugs blocking 
>>>>> all
>>>>> OFBiz there should be hardly any such bugs. I mean it would be very, very quickly fixed and we would have hardly the time to
>>>>> create a blocking bug. Notbaly because we have now BuildBot running and all commiters are quickly aware of any errors they
>>>>> woulds have made. Did you thought about it Scott, what is your perception?   Thanks
>>>>> Jacques
>>>>> Scott Gray wrote:
>>>>>> Hi Jacques,
>>>>>> I thought you fixed OFBIZ-3837 recently?  Or was that some other shipping estimate problem you were working on?
>>>>>> Regards
>>>>>> Scott
>>>>>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>>>>>>> There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
>>>>>>> This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not
>>>>>>> blocking OFBiz, just blocking a part of it, so it's critical actually) 4 are critical and 173 major
>>>>>>> No needs to say that any help to clean things would be really appreciated...
>>>>>>> HTH
>>>>>>> Jacques
>>>>>>> From: "BJ Freeman"<bj...@free-man.net>
>>>>>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>>>>>> =========================
>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>> Strategic Power Office with Supplier Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>> Chat  Y! messenger: bjfr33man
>>>>>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>>>>>> Actually I meant a response to it like there are no bugs that fit this
>>>>>>>>> condition.
>>>>>>>>> =========================
>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>> Strategic Power Office with Supplier Automation
>>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>>>>>>> You missed something by reading an email from a community member and
>>>>>>>>>> interpreting it's contents as some sort of official policy.
>>>>>>>>>> Regards
>>>>>>>>>> Scott
>>>>>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>>>>>>> I was reffering to this:
>>>>>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>>>>>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>>>>>>>>> have
>>>>>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>>>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>>>>>>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>>>>>>>>> been a concerted effort like that in like, forever.
>>>>>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>>>>>> Have I missed something?
>>>>>>>>>>> =========================
>>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>>>>>>> There are a number of bugs that have to be resolved before release
>>>>>>>>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>>>>>>>>> doing the patches for the bugs.
>>>>>>>>>>>> What are you basing this on?
>>>>>>>>>>>>> once they are completed and testing has been done then there will
>>>>>>>>>>>>> be a release.
>>>>>>>>>>>>> right now we are about 4 months past the planned release date.
>>>>>>>>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>>>>>>>>> date on a release is the date it was branched from the trunk, not
>>>>>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>>>>>> -David
>>>>>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>>>>>>>>> Just curious.
>>>
>>
> 

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

I am Glad for this discussion.
My years on Design teams had a lot different criteria.

so to Summarize if something is broke and no one wants to work on it, it 
is not considered a bug.

As far as buildbot it is only as good as the tests written that it uses 
and as was pointed out on the dev list ofbiz UI and minilanq is not 
tested, as in the math error.

So the fact it "passed" a build only says the test so far, don't fail, 
not that ofbiz is bug free.


reminds me of a used car salesman.


=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Scott Gray sent the following on 8/31/2010 2:56 AM:

> OFBIZ-3912 is a good example of an issue that is critical to an individual rather than the community I think.  A good indicator is that it has been broken for 5 months before being reported, can't be that critical then huh?
>
> Regards
> Scott
>
> On 31/08/2010, at 9:45 PM, Jacques Le Roux wrote:
>
>> Scott Gray wrote:
>>> A blocking bug IMO is nothing more than the community (rather than an individual) deciding that a bug is important enough that a
>>> release shouldn't occur until it is fixed.  I don't think we need any criteria other than that really.
>>
>> Yes that's fine to me. And a critical (for instance at https://issues.apache.org/jira/browse/OFBIZ-3912)?
>>
>> Jacques
>>> Regards
>>> Scott
>>> On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:
>>>> Hey Scott, that's right!
>>>> Happy to close this one. So eventually you were right, there are ANY blocking bugs in OFBiz under our criteria ;o)
>>>> Though I guess we should better define our criteria for blocking. Because if we allow to use blocking only for bugs blocking all
>>>> OFBiz there should be hardly any such bugs. I mean it would be very, very quickly fixed and we would have hardly the time to
>>>> create a blocking bug. Notbaly because we have now BuildBot running and all commiters are quickly aware of any errors they
>>>> woulds have made. Did you thought about it Scott, what is your perception?   Thanks
>>>> Jacques
>>>> Scott Gray wrote:
>>>>> Hi Jacques,
>>>>> I thought you fixed OFBIZ-3837 recently?  Or was that some other shipping estimate problem you were working on?
>>>>> Regards
>>>>> Scott
>>>>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>>>>>> There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
>>>>>> This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not
>>>>>> blocking OFBiz, just blocking a part of it, so it's critical actually) 4 are critical and 173 major
>>>>>> No needs to say that any help to clean things would be really appreciated...
>>>>>> HTH
>>>>>> Jacques
>>>>>> From: "BJ Freeman"<bj...@free-man.net>
>>>>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>>>>> =========================
>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>> Strategic Power Office with Supplier Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>> Chat  Y! messenger: bjfr33man
>>>>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>>>>> Actually I meant a response to it like there are no bugs that fit this
>>>>>>>> condition.
>>>>>>>> =========================
>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>> Strategic Power Office with Supplier Automation
>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>>>>>> You missed something by reading an email from a community member and
>>>>>>>>> interpreting it's contents as some sort of official policy.
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>>>>>> I was reffering to this:
>>>>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>>>>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>>>>>>>> have
>>>>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>>>>>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>>>>>>>> been a concerted effort like that in like, forever.
>>>>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>>>>> Have I missed something?
>>>>>>>>>> =========================
>>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>>>>>> There are a number of bugs that have to be resolved before release
>>>>>>>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>>>>>>>> doing the patches for the bugs.
>>>>>>>>>>> What are you basing this on?
>>>>>>>>>>>> once they are completed and testing has been done then there will
>>>>>>>>>>>> be a release.
>>>>>>>>>>>> right now we are about 4 months past the planned release date.
>>>>>>>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>>>>>>>> date on a release is the date it was branched from the trunk, not
>>>>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>>>>> -David
>>>>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>>>>>>>> Just curious.
>>
>

Re: Best practices for updates from trunk

[Matt Warnock <mw...@ridgecrestherbals.com>]

I am still following, and have been surprised at what I started...
It *IS* great!  :-)

Thanks for the tip, I'll try that right away.  Thanks again.
-- 
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.

On Tue, 2010-08-31 at 14:23 +0200, Carsten Schinzer wrote:
> Incredible how the original topic now turned into something pretty different
> ... it's just great!
> 
> Matt, if you are still following this, I have a recommendation to make for
> your original point 3.
> You should start versioning your own releases (I do the same) and integrate
> a later revision of OFBiz every now and then.
> 
> The trick is know as Subversion "Vendor Branch" and it is described in
> detail here:
> http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html
> 
> Try it out and you will see: after some 2-3 updates from the vendor's
> repository (in this case OFBiz'), you will feel safe with the procedure. And
> you should then also be able to automate it using scripting.
> 
> I still recommend you use an official release branch of OFBiz rather than
> trunk, but using this recommendation will actually allow you to do
> "fallbacks" on arbitrary versions of OFBiz trunk as long as you are
> consequently tagging your own releases.
> I do also recommend a testing stage before committing to your local
> repository and rolling on to production.
> Pros and cons on these latter two points have been addressed in the trail
> already.
> 
> Hope this helps!
> 
> Regards
> 
> 
> Carsten

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

Hi Matt,

Not a big deal, but yes it's not a good practice and I was corrected many times at my own beginning, that why I remember it well :o)
Actually when it's a different subject, for the sake of clairity you should open a new thread by creating an entirely new message 
and not responding to an existing one. Because these last one contains information in its header which will hook it on the thread it 
belongs

Thanks to care

Jacques

From: "Matt Warnock" <mw...@ridgecrestherbals.com>
> Hmm.  I usually just reply to an existing thread, but change the subject
> line to create a new thread.  It sounds from your comment like that may
> not be good practice.  Is there some thread identification code in the
> header, usually invisible in mail clients, that I was not aware of?
>
> If so, my apologies to everyone.  I usually read this in Evolution on
> Ubuntu, and was not aware of the issue, as it doesn't show there.
> -- 
> Matt Warnock <mw...@ridgecrestherbals.com>
> RidgeCrest Herbals, Inc.
>
> On Tue, 2010-08-31 at 14:45 +0200, Jacques Le Roux wrote:
>> From: "Carsten Schinzer" <c....@googlemail.com>
>> > Incredible how the original topic now turned into something pretty different
>> > ... it's just great!
>>
>> Yes :D  Actually Matt 1st hacked Jonatan's thread Error generating PDF invoice
>> http://markmail.org/message/vmon3ig3smles7k3
>>
>> Jacques
>>
>> > Matt, if you are still following this, I have a recommendation to make for
>> > your original point 3.
>> > You should start versioning your own releases (I do the same) and integrate
>> > a later revision of OFBiz every now and then.
>> >
>> > The trick is know as Subversion "Vendor Branch" and it is described in
>> > detail here:
>> > http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html
>>
>> There are also alternatives suggested in wiki
>> https://cwiki.apache.org/confluence/display/OFBIZ/Online+Developers+Section
>>
>> Jacques
>>
>> > Try it out and you will see: after some 2-3 updates from the vendor's
>> > repository (in this case OFBiz'), you will feel safe with the procedure. And
>> > you should then also be able to automate it using scripting.
>> >
>> > I still recommend you use an official release branch of OFBiz rather than
>> > trunk, but using this recommendation will actually allow you to do
>> > "fallbacks" on arbitrary versions of OFBiz trunk as long as you are
>> > consequently tagging your own releases.
>> > I do also recommend a testing stage before committing to your local
>> > repository and rolling on to production.
>> > Pros and cons on these latter two points have been addressed in the trail
>> > already.
>> >
>> > Hope this helps!
>> >
>> > Regards
>> >
>> >
>> > Carsten
>> >
> 

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

From: "Carsten Schinzer" <c....@googlemail.com>
> Incredible how the original topic now turned into something pretty different
> ... it's just great!

Yes :D  Actually Matt 1st hacked Jonatan's thread Error generating PDF invoice
http://markmail.org/message/vmon3ig3smles7k3

Jacques
 
> Matt, if you are still following this, I have a recommendation to make for
> your original point 3.
> You should start versioning your own releases (I do the same) and integrate
> a later revision of OFBiz every now and then.
> 
> The trick is know as Subversion "Vendor Branch" and it is described in
> detail here:
> http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html

There are also alternatives suggested in wiki
https://cwiki.apache.org/confluence/display/OFBIZ/Online+Developers+Section

Jacques

> Try it out and you will see: after some 2-3 updates from the vendor's
> repository (in this case OFBiz'), you will feel safe with the procedure. And
> you should then also be able to automate it using scripting.
> 
> I still recommend you use an official release branch of OFBiz rather than
> trunk, but using this recommendation will actually allow you to do
> "fallbacks" on arbitrary versions of OFBiz trunk as long as you are
> consequently tagging your own releases.
> I do also recommend a testing stage before committing to your local
> repository and rolling on to production.
> Pros and cons on these latter two points have been addressed in the trail
> already.
> 
> Hope this helps!
> 
> Regards
> 
> 
> Carsten
>

Re: Best practices for updates from trunk

[Carsten Schinzer <c....@googlemail.com>]

Incredible how the original topic now turned into something pretty different
... it's just great!

Matt, if you are still following this, I have a recommendation to make for
your original point 3.
You should start versioning your own releases (I do the same) and integrate
a later revision of OFBiz every now and then.

The trick is know as Subversion "Vendor Branch" and it is described in
detail here:
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html

Try it out and you will see: after some 2-3 updates from the vendor's
repository (in this case OFBiz'), you will feel safe with the procedure. And
you should then also be able to automate it using scripting.

I still recommend you use an official release branch of OFBiz rather than
trunk, but using this recommendation will actually allow you to do
"fallbacks" on arbitrary versions of OFBiz trunk as long as you are
consequently tagging your own releases.
I do also recommend a testing stage before committing to your local
repository and rolling on to production.
Pros and cons on these latter two points have been addressed in the trail
already.

Hope this helps!

Regards


Carsten

Re: Best practices for updates from trunk

[Erwan de FERRIERES <er...@nereide.fr>]

Le 31/08/2010 12:31, Jacques Le Roux a écrit :
> Hi Erwan,
>
> Is there a Jira reporting this, with a patch?
>
> Thanks
>
> Jacques
>
Strangely, there is no jira... but here is the thread showing the 
problem : 
http://ofbiz.135035.n4.nabble.com/Lucene-is-broken-td2123400.html#a2123871
I may have only reported the problem to the mailing list... And so, 
there is no patch. Be that is one was existing I would have commited it !
Cheers,

-- 
Erwan de FERRIERES
www.nereide.biz

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

Hi Erwan,

Is there a Jira reporting this, with a patch?

Thanks

Jacques

Erwan de FERRIERES wrote:
> Le 31/08/2010 11:56, Scott Gray a écrit :
>> OFBIZ-3912 is a good example of an issue that is critical to an individual rather than the community I think.  A good indicator
>> is that it has been broken for 5 months before being reported, can't be that critical then huh? Regards
>> Scott
>
> Hi,
> lucene is broken since a long time in trunk... I think this is critical,
> but the communauty don't... And this hasn't stopped us making a release..
>
> Cheers, 

Re: Best practices for updates from trunk

[Erwan de FERRIERES <er...@nereide.fr>]

Le 31/08/2010 11:56, Scott Gray a écrit :
> OFBIZ-3912 is a good example of an issue that is critical to an individual rather than the community I think.  A good indicator is that it has been broken for 5 months before being reported, can't be that critical then huh?
>
> Regards
> Scott

Hi,
lucene is broken since a long time in trunk... I think this is critical, 
but the communauty don't... And this hasn't stopped us making a release..

Cheers,

-- 
Erwan de FERRIERES
www.nereide.biz

Re: Best practices for updates from trunk

[Scott Gray <sc...@hotwaxmedia.com>]

OFBIZ-3912 is a good example of an issue that is critical to an individual rather than the community I think.  A good indicator is that it has been broken for 5 months before being reported, can't be that critical then huh?

Regards
Scott

On 31/08/2010, at 9:45 PM, Jacques Le Roux wrote:

> Scott Gray wrote:
>> A blocking bug IMO is nothing more than the community (rather than an individual) deciding that a bug is important enough that a
>> release shouldn't occur until it is fixed.  I don't think we need any criteria other than that really. 
> 
> Yes that's fine to me. And a critical (for instance at https://issues.apache.org/jira/browse/OFBIZ-3912)?
> 
> Jacques
>> Regards
>> Scott
>> On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:
>>> Hey Scott, that's right!
>>> Happy to close this one. So eventually you were right, there are ANY blocking bugs in OFBiz under our criteria ;o)
>>> Though I guess we should better define our criteria for blocking. Because if we allow to use blocking only for bugs blocking all
>>> OFBiz there should be hardly any such bugs. I mean it would be very, very quickly fixed and we would have hardly the time to
>>> create a blocking bug. Notbaly because we have now BuildBot running and all commiters are quickly aware of any errors they
>>> woulds have made. Did you thought about it Scott, what is your perception?   Thanks
>>> Jacques
>>> Scott Gray wrote:
>>>> Hi Jacques,
>>>> I thought you fixed OFBIZ-3837 recently?  Or was that some other shipping estimate problem you were working on?
>>>> Regards
>>>> Scott
>>>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>>>>> There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
>>>>> This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
>>>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not
>>>>> blocking OFBiz, just blocking a part of it, so it's critical actually) 4 are critical and 173 major
>>>>> No needs to say that any help to clean things would be really appreciated...
>>>>> HTH
>>>>> Jacques
>>>>> From: "BJ Freeman" <bj...@free-man.net>
>>>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>>>> =========================
>>>>>> BJ Freeman  <http://bjfreeman.elance.com>
>>>>>> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>> Specialtymarket.com  <http://www.specialtymarket.com/>
>>>>>> Systems Integrator-- Glad to Assist
>>>>>> Chat  Y! messenger: bjfr33man
>>>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>>>> Actually I meant a response to it like there are no bugs that fit this
>>>>>>> condition.
>>>>>>> =========================
>>>>>>> BJ Freeman <http://bjfreeman.elance.com>
>>>>>>> Strategic Power Office with Supplier Automation
>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>>>>> You missed something by reading an email from a community member and
>>>>>>>> interpreting it's contents as some sort of official policy.
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>>>>> I was reffering to this:
>>>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>>>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>>>>>>> have
>>>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>>>>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>>>>>>> been a concerted effort like that in like, forever.
>>>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>>>> Have I missed something?
>>>>>>>>> =========================
>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>>>>> There are a number of bugs that have to be resolved before release
>>>>>>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>>>>>>> doing the patches for the bugs.
>>>>>>>>>> What are you basing this on?
>>>>>>>>>>> once they are completed and testing has been done then there will
>>>>>>>>>>> be a release.
>>>>>>>>>>> right now we are about 4 months past the planned release date.
>>>>>>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>>>>>>> date on a release is the date it was branched from the trunk, not
>>>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>>>> -David
>>>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>>>>>>> Just curious.
> 

Re: Best practices for updates from trunk

[Nicolas Malin <ma...@librenberry.net>]

I agree with you Scott after it's really a vision problem. When I choose 
a criteria level, I don't look to existant problems but the impact of a 
bug for the community. If OFBiz contains several bugs for me, I use 
production addon for my customer so as each bug is trivial  and after I 
think to importance for the community.

Nicolas

Jacques Le Roux a écrit :
> Scott Gray wrote:
>> A blocking bug IMO is nothing more than the community (rather than an 
>> individual) deciding that a bug is important enough that a
>> release shouldn't occur until it is fixed.  I don't think we need any 
>> criteria other than that really. 
>
> Yes that's fine to me. And a critical (for instance at 
> https://issues.apache.org/jira/browse/OFBIZ-3912)?
>
> Jacques
>
>> Regards
>> Scott
>>
>> On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:
>>
>>> Hey Scott, that's right!
>>>
>>> Happy to close this one. So eventually you were right, there are ANY 
>>> blocking bugs in OFBiz under our criteria ;o)
>>>
>>> Though I guess we should better define our criteria for blocking. 
>>> Because if we allow to use blocking only for bugs blocking all
>>> OFBiz there should be hardly any such bugs. I mean it would be very, 
>>> very quickly fixed and we would have hardly the time to
>>> create a blocking bug. Notbaly because we have now BuildBot running 
>>> and all commiters are quickly aware of any errors they
>>> woulds have made. Did you thought about it Scott, what is your 
>>> perception?  
>>> Thanks
>>>
>>> Jacques
>>>
>>> Scott Gray wrote:
>>>> Hi Jacques,
>>>>
>>>> I thought you fixed OFBIZ-3837 recently?  Or was that some other 
>>>> shipping estimate problem you were working on?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>>>>
>>>>> There are currently 275 UNRESOLVED bugs, 11 have patches 
>>>>> available, 14 are reopened.
>>>>> This is againt all versions. There are only 78 for trunk but this 
>>>>> is not a reliable criteria (if any are)
>>>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as 
>>>>> blocking. But I guess not under Scott's criteria (it's not
>>>>> blocking OFBiz, just blocking a part of it, so it's critical 
>>>>> actually) 4 are critical and 173 major
>>>>>
>>>>> No needs to say that any help to clean things would be really 
>>>>> appreciated...
>>>>>
>>>>> HTH
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "BJ Freeman" <bj...@free-man.net>
>>>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>>>>
>>>>>> =========================
>>>>>> BJ Freeman  <http://bjfreeman.elance.com>
>>>>>> Strategic Power Office with Supplier Automation  
>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>> Specialtymarket.com  <http://www.specialtymarket.com/>
>>>>>> Systems Integrator-- Glad to Assist
>>>>>>
>>>>>> Chat  Y! messenger: bjfr33man
>>>>>>
>>>>>>
>>>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>>>> Actually I meant a response to it like there are no bugs that 
>>>>>>> fit this
>>>>>>> condition.
>>>>>>>
>>>>>>> =========================
>>>>>>> BJ Freeman <http://bjfreeman.elance.com>
>>>>>>> Strategic Power Office with Supplier Automation
>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>
>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>
>>>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>>>>
>>>>>>>
>>>>>>>> You missed something by reading an email from a community 
>>>>>>>> member and
>>>>>>>> interpreting it's contents as some sort of official policy.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>>>>
>>>>>>>>> I was reffering to this:
>>>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>>>> I guess the basic questions might be: Did we have an official 
>>>>>>>>>> "freeze"
>>>>>>>>>> process where we only accepted bug fixes against that branch? 
>>>>>>>>>> Do we
>>>>>>>>>> have
>>>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>>>>
>>>>>>>>> I agree. At least *all* bugs should be looked at, and given a 
>>>>>>>>> target
>>>>>>>>> release tag, etc. Time for some bug triage. I don't think 
>>>>>>>>> there has
>>>>>>>>> been a concerted effort like that in like, forever.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>>>> Have I missed something?
>>>>>>>>>
>>>>>>>>> =========================
>>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>>> Strategic Power Office with Supplier
>>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>>>
>>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>>>>
>>>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>>>>
>>>>>>>>>>> There are a number of bugs that have to be resolved before 
>>>>>>>>>>> release
>>>>>>>>>>> remember this is a volunteer effort so there is no full time 
>>>>>>>>>>> person
>>>>>>>>>>> doing the patches for the bugs.
>>>>>>>>>>
>>>>>>>>>> What are you basing this on?
>>>>>>>>>>
>>>>>>>>>>> once they are completed and testing has been done then there 
>>>>>>>>>>> will
>>>>>>>>>>> be a release.
>>>>>>>>>>> right now we are about 4 months past the planned release date.
>>>>>>>>>>
>>>>>>>>>> What are you basing this on? Maybe there is some confusion... 
>>>>>>>>>> the
>>>>>>>>>> date on a release is the date it was branched from the trunk, 
>>>>>>>>>> not
>>>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected 
>>>>>>>>>>>> release date?
>>>>>>>>>>>> Just curious.
>

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

Scott Gray wrote:
> A blocking bug IMO is nothing more than the community (rather than an individual) deciding that a bug is important enough that a
> release shouldn't occur until it is fixed.  I don't think we need any criteria other than that really. 

Yes that's fine to me. And a critical (for instance at https://issues.apache.org/jira/browse/OFBIZ-3912)?

Jacques
 
> Regards
> Scott
> 
> On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:
> 
>> Hey Scott, that's right!
>> 
>> Happy to close this one. So eventually you were right, there are ANY blocking bugs in OFBiz under our criteria ;o)
>> 
>> Though I guess we should better define our criteria for blocking. Because if we allow to use blocking only for bugs blocking all
>> OFBiz there should be hardly any such bugs. I mean it would be very, very quickly fixed and we would have hardly the time to
>> create a blocking bug. Notbaly because we have now BuildBot running and all commiters are quickly aware of any errors they
>> woulds have made. Did you thought about it Scott, what is your perception?   
>> 
>> Thanks
>> 
>> Jacques
>> 
>> Scott Gray wrote:
>>> Hi Jacques,
>>> 
>>> I thought you fixed OFBIZ-3837 recently?  Or was that some other shipping estimate problem you were working on?
>>> 
>>> Regards
>>> Scott
>>> 
>>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>>> 
>>>> There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
>>>> This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
>>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not
>>>> blocking OFBiz, just blocking a part of it, so it's critical actually) 4 are critical and 173 major
>>>> 
>>>> No needs to say that any help to clean things would be really appreciated...
>>>> 
>>>> HTH
>>>> 
>>>> Jacques
>>>> 
>>>> From: "BJ Freeman" <bj...@free-man.net>
>>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>>> 
>>>>> =========================
>>>>> BJ Freeman  <http://bjfreeman.elance.com>
>>>>> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>> Specialtymarket.com  <http://www.specialtymarket.com/>
>>>>> Systems Integrator-- Glad to Assist
>>>>> 
>>>>> Chat  Y! messenger: bjfr33man
>>>>> 
>>>>> 
>>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>>> Actually I meant a response to it like there are no bugs that fit this
>>>>>> condition.
>>>>>> 
>>>>>> =========================
>>>>>> BJ Freeman <http://bjfreeman.elance.com>
>>>>>> Strategic Power Office with Supplier Automation
>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>>>> Systems Integrator-- Glad to Assist
>>>>>> 
>>>>>> Chat Y! messenger: bjfr33man
>>>>>> 
>>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>>> 
>>>>>> 
>>>>>>> You missed something by reading an email from a community member and
>>>>>>> interpreting it's contents as some sort of official policy.
>>>>>>> 
>>>>>>> Regards
>>>>>>> Scott
>>>>>>> 
>>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>>> 
>>>>>>>> I was reffering to this:
>>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>>>>>> have
>>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>>> 
>>>>>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>>>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>>>>>> been a concerted effort like that in like, forever.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>>> Have I missed something?
>>>>>>>> 
>>>>>>>> =========================
>>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>>> Strategic Power Office with Supplier
>>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>>> 
>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>>> 
>>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>>> 
>>>>>>>> 
>>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>>> 
>>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>>> 
>>>>>>>>>> There are a number of bugs that have to be resolved before release
>>>>>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>>>>>> doing the patches for the bugs.
>>>>>>>>> 
>>>>>>>>> What are you basing this on?
>>>>>>>>> 
>>>>>>>>>> once they are completed and testing has been done then there will
>>>>>>>>>> be a release.
>>>>>>>>>> right now we are about 4 months past the planned release date.
>>>>>>>>> 
>>>>>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>>>>>> date on a release is the date it was branched from the trunk, not
>>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>>> 
>>>>>>>>> -David
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>>>>>> Just curious.

Re: Best practices for updates from trunk

[Scott Gray <sc...@hotwaxmedia.com>]

A blocking bug IMO is nothing more than the community (rather than an individual) deciding that a bug is important enough that a release shouldn't occur until it is fixed.  I don't think we need any criteria other than that really.

Regards
Scott

On 31/08/2010, at 9:09 PM, Jacques Le Roux wrote:

> Hey Scott, that's right!
> 
> Happy to close this one. So eventually you were right, there are ANY blocking bugs in OFBiz under our criteria ;o)
> 
> Though I guess we should better define our criteria for blocking. Because if we allow to use blocking only for bugs blocking all OFBiz there should be hardly any such bugs. I mean it would be very, very quickly fixed and we would have hardly the time to create a blocking bug. Notbaly because we have now BuildBot running and all commiters are quickly aware of any errors they woulds have made. Did you thought about it Scott, what is your perception?
> 
> Thanks
> 
> Jacques
> 
> Scott Gray wrote:
>> Hi Jacques,
>> 
>> I thought you fixed OFBIZ-3837 recently?  Or was that some other shipping estimate problem you were working on?
>> 
>> Regards
>> Scott
>> 
>> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>> 
>>> There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
>>> This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
>>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not
>>> blocking OFBiz, just blocking a part of it, so it's critical actually) 4 are critical and 173 major
>>> 
>>> No needs to say that any help to clean things would be really appreciated...
>>> 
>>> HTH
>>> 
>>> Jacques
>>> 
>>> From: "BJ Freeman" <bj...@free-man.net>
>>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>> 
>>>> =========================
>>>> BJ Freeman  <http://bjfreeman.elance.com>
>>>> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>> Specialtymarket.com  <http://www.specialtymarket.com/>
>>>> Systems Integrator-- Glad to Assist
>>>> 
>>>> Chat  Y! messenger: bjfr33man
>>>> 
>>>> 
>>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>>> Actually I meant a response to it like there are no bugs that fit this
>>>>> condition.
>>>>> 
>>>>> =========================
>>>>> BJ Freeman <http://bjfreeman.elance.com>
>>>>> Strategic Power Office with Supplier Automation
>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>>> Systems Integrator-- Glad to Assist
>>>>> 
>>>>> Chat Y! messenger: bjfr33man
>>>>> 
>>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>> 
>>>>> 
>>>>>> You missed something by reading an email from a community member and
>>>>>> interpreting it's contents as some sort of official policy.
>>>>>> 
>>>>>> Regards
>>>>>> Scott
>>>>>> 
>>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>> 
>>>>>>> I was reffering to this:
>>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>>>>> have
>>>>>>>> any open bugs that are considered "release critical"?
>>>>>>> 
>>>>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>>>>> been a concerted effort like that in like, forever.
>>>>>>> 
>>>>>>> 
>>>>>>> I have not seen anything that shows this as taken care of.
>>>>>>> Have I missed something?
>>>>>>> 
>>>>>>> =========================
>>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>>> Strategic Power Office with Supplier
>>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>> 
>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>>> Systems Integrator-- Glad to Assist
>>>>>>> 
>>>>>>> Chat Y! messenger: bjfr33man
>>>>>>> 
>>>>>>> 
>>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>> 
>>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>> 
>>>>>>>>> There are a number of bugs that have to be resolved before release
>>>>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>>>>> doing the patches for the bugs.
>>>>>>>> 
>>>>>>>> What are you basing this on?
>>>>>>>> 
>>>>>>>>> once they are completed and testing has been done then there will
>>>>>>>>> be a release.
>>>>>>>>> right now we are about 4 months past the planned release date.
>>>>>>>> 
>>>>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>>>>> date on a release is the date it was branched from the trunk, not
>>>>>>>> the date that a binary release is done from the branch.
>>>>>>>> 
>>>>>>>> -David
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>>>>> Just curious. 
> 
> 

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

Hey Scott, that's right!

Happy to close this one. So eventually you were right, there are ANY blocking bugs in OFBiz under our criteria ;o)

Though I guess we should better define our criteria for blocking. Because if we allow to use blocking only for bugs blocking all 
OFBiz there should be hardly any such bugs. I mean it would be very, very quickly fixed and we would have hardly the time to create 
a blocking bug. Notbaly because we have now BuildBot running and all commiters are quickly aware of any errors they woulds have 
made. Did you thought about it Scott, what is your perception?

Thanks

Jacques

Scott Gray wrote:
> Hi Jacques,
>
> I thought you fixed OFBIZ-3837 recently?  Or was that some other shipping estimate problem you were working on?
>
> Regards
> Scott
>
> On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:
>
>> There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
>> This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
>> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not
>> blocking OFBiz, just blocking a part of it, so it's critical actually) 4 are critical and 173 major
>>
>> No needs to say that any help to clean things would be really appreciated...
>>
>> HTH
>>
>> Jacques
>>
>> From: "BJ Freeman" <bj...@free-man.net>
>>> Quick scan of Jira shows 4 open bugs not counting mine.
>>>
>>> =========================
>>> BJ Freeman  <http://bjfreeman.elance.com>
>>> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>> Specialtymarket.com  <http://www.specialtymarket.com/>
>>> Systems Integrator-- Glad to Assist
>>>
>>> Chat  Y! messenger: bjfr33man
>>>
>>>
>>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>>> Actually I meant a response to it like there are no bugs that fit this
>>>> condition.
>>>>
>>>> =========================
>>>> BJ Freeman <http://bjfreeman.elance.com>
>>>> Strategic Power Office with Supplier Automation
>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>> Systems Integrator-- Glad to Assist
>>>>
>>>> Chat Y! messenger: bjfr33man
>>>>
>>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>>>
>>>>
>>>>> You missed something by reading an email from a community member and
>>>>> interpreting it's contents as some sort of official policy.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>>>
>>>>>> I was reffering to this:
>>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>>>> have
>>>>>>> any open bugs that are considered "release critical"?
>>>>>>
>>>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>>>> been a concerted effort like that in like, forever.
>>>>>>
>>>>>>
>>>>>> I have not seen anything that shows this as taken care of.
>>>>>> Have I missed something?
>>>>>>
>>>>>> =========================
>>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>>> Strategic Power Office with Supplier
>>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>>>
>>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>>> Systems Integrator-- Glad to Assist
>>>>>>
>>>>>> Chat Y! messenger: bjfr33man
>>>>>>
>>>>>>
>>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>>>
>>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>>>
>>>>>>>> There are a number of bugs that have to be resolved before release
>>>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>>>> doing the patches for the bugs.
>>>>>>>
>>>>>>> What are you basing this on?
>>>>>>>
>>>>>>>> once they are completed and testing has been done then there will
>>>>>>>> be a release.
>>>>>>>> right now we are about 4 months past the planned release date.
>>>>>>>
>>>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>>>> date on a release is the date it was branched from the trunk, not
>>>>>>> the date that a binary release is done from the branch.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>>>> Just curious. 

Re: Best practices for updates from trunk

[Scott Gray <sc...@hotwaxmedia.com>]

Hi Jacques,

I thought you fixed OFBIZ-3837 recently?  Or was that some other shipping estimate problem you were working on?

Regards
Scott

On 31/08/2010, at 7:52 PM, Jacques Le Roux wrote:

> There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
> This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
> https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not blocking OFBiz, just blocking a part of it, so it's critical actually)
> 4 are critical and 173 major
> 
> No needs to say that any help to clean things would be really appreciated...
> 
> HTH
> 
> Jacques
> 
> From: "BJ Freeman" <bj...@free-man.net>
>> Quick scan of Jira shows 4 open bugs not counting mine.
>> 
>> =========================
>> BJ Freeman  <http://bjfreeman.elance.com>
>> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com  <http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>> 
>> Chat  Y! messenger: bjfr33man
>> 
>> 
>> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>>> Actually I meant a response to it like there are no bugs that fit this
>>> condition.
>>> 
>>> =========================
>>> BJ Freeman <http://bjfreeman.elance.com>
>>> Strategic Power Office with Supplier Automation
>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>> Systems Integrator-- Glad to Assist
>>> 
>>> Chat Y! messenger: bjfr33man
>>> 
>>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>> 
>>> 
>>>> You missed something by reading an email from a community member and
>>>> interpreting it's contents as some sort of official policy.
>>>> 
>>>> Regards
>>>> Scott
>>>> 
>>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>> 
>>>>> I was reffering to this:
>>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>>> have
>>>>>> any open bugs that are considered "release critical"?
>>>>> 
>>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>>> been a concerted effort like that in like, forever.
>>>>> 
>>>>> 
>>>>> I have not seen anything that shows this as taken care of.
>>>>> Have I missed something?
>>>>> 
>>>>> =========================
>>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>>> Strategic Power Office with Supplier
>>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>> 
>>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>>> Systems Integrator-- Glad to Assist
>>>>> 
>>>>> Chat Y! messenger: bjfr33man
>>>>> 
>>>>> 
>>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>> 
>>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>> 
>>>>>>> There are a number of bugs that have to be resolved before release
>>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>>> doing the patches for the bugs.
>>>>>> 
>>>>>> What are you basing this on?
>>>>>> 
>>>>>>> once they are completed and testing has been done then there will
>>>>>>> be a release.
>>>>>>> right now we are about 4 months past the planned release date.
>>>>>> 
>>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>>> date on a release is the date it was branched from the trunk, not
>>>>>> the date that a binary release is done from the branch.
>>>>>> 
>>>>>> -David
>>>>>> 
>>>>>> 
>>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>>> Just curious.
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
> 
> 

Re: Best practices for updates from trunk

[Jacques Le Roux <ja...@les7arts.com>]

There are currently 275 UNRESOLVED bugs, 11 have patches available, 14 are reopened.
This is againt all versions. There are only 78 for trunk but this is not a reliable criteria (if any are)
https://issues.apache.org/jira/browse/OFBIZ-3837 is marked as blocking. But I guess not under Scott's criteria (it's not blocking 
OFBiz, just blocking a part of it, so it's critical actually)
4 are critical and 173 major

No needs to say that any help to clean things would be really appreciated...

HTH

Jacques

From: "BJ Freeman" <bj...@free-man.net>
> Quick scan of Jira shows 4 open bugs not counting mine.
>
> =========================
> BJ Freeman  <http://bjfreeman.elance.com>
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
>
>
> BJ Freeman sent the following on 8/30/2010 10:17 PM:
>> Actually I meant a response to it like there are no bugs that fit this
>> condition.
>>
>> =========================
>> BJ Freeman <http://bjfreeman.elance.com>
>> Strategic Power Office with Supplier Automation
>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com <http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat Y! messenger: bjfr33man
>>
>> Scott Gray sent the following on 8/30/2010 10:12 PM:
>>
>>
>>> You missed something by reading an email from a community member and
>>> interpreting it's contents as some sort of official policy.
>>>
>>> Regards
>>> Scott
>>>
>>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>>
>>>> I was reffering to this:
>>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>>> process where we only accepted bug fixes against that branch? Do we
>>>>> have
>>>>> any open bugs that are considered "release critical"?
>>>>
>>>> I agree. At least *all* bugs should be looked at, and given a target
>>>> release tag, etc. Time for some bug triage. I don't think there has
>>>> been a concerted effort like that in like, forever.
>>>>
>>>>
>>>> I have not seen anything that shows this as taken care of.
>>>> Have I missed something?
>>>>
>>>> =========================
>>>> BJ Freeman<http://bjfreeman.elance.com>
>>>> Strategic Power Office with Supplier
>>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>>
>>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>>> Systems Integrator-- Glad to Assist
>>>>
>>>> Chat Y! messenger: bjfr33man
>>>>
>>>>
>>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>>
>>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>>
>>>>>> There are a number of bugs that have to be resolved before release
>>>>>> remember this is a volunteer effort so there is no full time person
>>>>>> doing the patches for the bugs.
>>>>>
>>>>> What are you basing this on?
>>>>>
>>>>>> once they are completed and testing has been done then there will
>>>>>> be a release.
>>>>>> right now we are about 4 months past the planned release date.
>>>>>
>>>>> What are you basing this on? Maybe there is some confusion... the
>>>>> date on a release is the date it was branched from the trunk, not
>>>>> the date that a binary release is done from the branch.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>>> Just curious.
>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

Quick scan of Jira shows 4 open bugs not counting mine.

=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


BJ Freeman sent the following on 8/30/2010 10:17 PM:
> Actually I meant a response to it like there are no bugs that fit this
> condition.
>
> =========================
> BJ Freeman <http://bjfreeman.elance.com>
> Strategic Power Office with Supplier Automation
> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
>
> Scott Gray sent the following on 8/30/2010 10:12 PM:
>
>
>> You missed something by reading an email from a community member and
>> interpreting it's contents as some sort of official policy.
>>
>> Regards
>> Scott
>>
>> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>>
>>> I was reffering to this:
>>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>>> I guess the basic questions might be: Did we have an official "freeze"
>>>> process where we only accepted bug fixes against that branch? Do we
>>>> have
>>>> any open bugs that are considered "release critical"?
>>>
>>> I agree. At least *all* bugs should be looked at, and given a target
>>> release tag, etc. Time for some bug triage. I don't think there has
>>> been a concerted effort like that in like, forever.
>>>
>>>
>>> I have not seen anything that shows this as taken care of.
>>> Have I missed something?
>>>
>>> =========================
>>> BJ Freeman<http://bjfreeman.elance.com>
>>> Strategic Power Office with Supplier
>>> Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>>>
>>> Specialtymarket.com<http://www.specialtymarket.com/>
>>> Systems Integrator-- Glad to Assist
>>>
>>> Chat Y! messenger: bjfr33man
>>>
>>>
>>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>>
>>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>>
>>>>> There are a number of bugs that have to be resolved before release
>>>>> remember this is a volunteer effort so there is no full time person
>>>>> doing the patches for the bugs.
>>>>
>>>> What are you basing this on?
>>>>
>>>>> once they are completed and testing has been done then there will
>>>>> be a release.
>>>>> right now we are about 4 months past the planned release date.
>>>>
>>>> What are you basing this on? Maybe there is some confusion... the
>>>> date on a release is the date it was branched from the trunk, not
>>>> the date that a binary release is done from the branch.
>>>>
>>>> -David
>>>>
>>>>
>>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>>> Thanks. Is 10.04 nearing release? Is there an expected release date?
>>>>>> Just curious.
>>>>
>>>>
>>>
>>
>

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

Actually I meant a response to it like there are no bugs that fit this 
condition.

=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man

Scott Gray sent the following on 8/30/2010 10:12 PM:


> You missed something by reading an email from a community member and interpreting it's contents as some sort of official policy.
>
> Regards
> Scott
>
> On 31/08/2010, at 5:07 PM, BJ Freeman wrote:
>
>> I was reffering to this:
>> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
>>> I guess the basic questions might be: Did we have an official "freeze"
>>> process where we only accepted bug fixes against that branch? Do we have
>>> any open bugs that are considered "release critical"?
>>
>> I agree.  At least *all* bugs should be looked at, and given a target release tag, etc.  Time for some bug triage.  I don't think there has been a concerted effort like that in like, forever.
>>
>>
>> I have not seen anything that shows this as taken care of.
>> Have I missed something?
>>
>> =========================
>> BJ Freeman<http://bjfreeman.elance.com>
>> Strategic Power Office with Supplier Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com<http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat  Y! messenger: bjfr33man
>>
>>
>> David E Jones sent the following on 8/30/2010 9:47 PM:
>>>
>>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>>>
>>>> There are a number of bugs that have to be resolved before release
>>>> remember this is a volunteer effort so there is no full time person doing the patches for the bugs.
>>>
>>> What are you basing this on?
>>>
>>>> once they are completed and testing has been done then there will be a release.
>>>> right now we are about 4 months past the planned release date.
>>>
>>> What are you basing this on? Maybe there is some confusion... the date on a release is the date it was branched from the trunk, not the date that a binary release is done from the branch.
>>>
>>> -David
>>>
>>>
>>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>>> Thanks.  Is 10.04 nearing release?  Is there an expected release date?
>>>>> Just curious.
>>>
>>>
>>
>

Re: Best practices for updates from trunk

[Scott Gray <sc...@hotwaxmedia.com>]

You missed something by reading an email from a community member and interpreting it's contents as some sort of official policy.

Regards
Scott

On 31/08/2010, at 5:07 PM, BJ Freeman wrote:

> I was reffering to this:
> On 07/29/2010 01:53 AM, Ean Schuessler wrote:
> > I guess the basic questions might be: Did we have an official "freeze"
> > process where we only accepted bug fixes against that branch? Do we have
> > any open bugs that are considered "release critical"?
> 
> I agree.  At least *all* bugs should be looked at, and given a target release tag, etc.  Time for some bug triage.  I don't think there has been a concerted effort like that in like, forever.
> 
> 
> I have not seen anything that shows this as taken care of.
> Have I missed something?
> 
> =========================
> BJ Freeman  <http://bjfreeman.elance.com>
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
> 
> Chat  Y! messenger: bjfr33man
> 
> 
> David E Jones sent the following on 8/30/2010 9:47 PM:
>> 
>> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>> 
>>> There are a number of bugs that have to be resolved before release
>>> remember this is a volunteer effort so there is no full time person doing the patches for the bugs.
>> 
>> What are you basing this on?
>> 
>>> once they are completed and testing has been done then there will be a release.
>>> right now we are about 4 months past the planned release date.
>> 
>> What are you basing this on? Maybe there is some confusion... the date on a release is the date it was branched from the trunk, not the date that a binary release is done from the branch.
>> 
>> -David
>> 
>> 
>>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>>> Thanks.  Is 10.04 nearing release?  Is there an expected release date?
>>>> Just curious.
>> 
>> 
> 

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

I was reffering to this:
On 07/29/2010 01:53 AM, Ean Schuessler wrote:
 > I guess the basic questions might be: Did we have an official "freeze"
 > process where we only accepted bug fixes against that branch? Do we have
 > any open bugs that are considered "release critical"?

I agree.  At least *all* bugs should be looked at, and given a target 
release tag, etc.  Time for some bug triage.  I don't think there has 
been a concerted effort like that in like, forever.


I have not seen anything that shows this as taken care of.
Have I missed something?

=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


David E Jones sent the following on 8/30/2010 9:47 PM:
>
> On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:
>
>> There are a number of bugs that have to be resolved before release
>> remember this is a volunteer effort so there is no full time person doing the patches for the bugs.
>
> What are you basing this on?
>
>> once they are completed and testing has been done then there will be a release.
>> right now we are about 4 months past the planned release date.
>
> What are you basing this on? Maybe there is some confusion... the date on a release is the date it was branched from the trunk, not the date that a binary release is done from the branch.
>
> -David
>
>
>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>> Thanks.  Is 10.04 nearing release?  Is there an expected release date?
>>> Just curious.
>
>

Re: Best practices for updates from trunk

[David E Jones <de...@me.com>]

On Aug 30, 2010, at 10:38 PM, BJ Freeman wrote:

> There are a number of bugs that have to be resolved before release
> remember this is a volunteer effort so there is no full time person doing the patches for the bugs.

What are you basing this on?

> once they are completed and testing has been done then there will be a release.
> right now we are about 4 months past the planned release date.

What are you basing this on? Maybe there is some confusion... the date on a release is the date it was branched from the trunk, not the date that a binary release is done from the branch.

-David


> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>> Thanks.  Is 10.04 nearing release?  Is there an expected release date?
>> Just curious.

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

See my answer to davids email

=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Scott Gray sent the following on 8/30/2010 9:48 PM:
> On 31/08/2010, at 4:38 PM, BJ Freeman wrote:
>
>> There are a number of bugs that have to be resolved before release
>
> I'm not aware of any bugs that are blocking a release, there may be bugs but not blocking ones.
>
>> remember this is a volunteer effort so there is no full time person doing the patches for the bugs.
>>
>> once they are completed and testing has been done then there will be a release.
>> right now we are about 4 months past the planned release date.
>
> No, the release branch was created 4 months ago.  There was never a planned release date, generally it's just when the community thinks it is ready and someone is willing to put the time in to do all the necessary release tasks.
>
>>
>> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>>> Thanks.  Is 10.04 nearing release?  Is there an expected release date?
>>> Just curious.
>

Re: Best practices for updates from trunk

[Scott Gray <sc...@hotwaxmedia.com>]

On 31/08/2010, at 4:38 PM, BJ Freeman wrote:

> There are a number of bugs that have to be resolved before release

I'm not aware of any bugs that are blocking a release, there may be bugs but not blocking ones.

> remember this is a volunteer effort so there is no full time person doing the patches for the bugs.
> 
> once they are completed and testing has been done then there will be a release.
> right now we are about 4 months past the planned release date.

No, the release branch was created 4 months ago.  There was never a planned release date, generally it's just when the community thinks it is ready and someone is willing to put the time in to do all the necessary release tasks.

> 
> Matt Warnock sent the following on 8/30/2010 9:27 PM:
>> Thanks.  Is 10.04 nearing release?  Is there an expected release date?
>> Just curious.

Re: Best practices for updates from trunk

[Matt Warnock <mw...@ridgecrestherbals.com>]

Understood.  Just curious, as I say.  Thanks BJ!
-- 
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.

On Mon, 2010-08-30 at 21:38 -0700, BJ Freeman wrote:
> There are a number of bugs that have to be resolved before release
> remember this is a volunteer effort so there is no full time person 
> doing the patches for the bugs.
> 
> once they are completed and testing has been done then there will be a 
> release.
> right now we are about 4 months past the planned release date.
> 
> Matt Warnock sent the following on 8/30/2010 9:27 PM:
> > Thanks.  Is 10.04 nearing release?  Is there an expected release date?
> > Just curious.

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

There are a number of bugs that have to be resolved before release
remember this is a volunteer effort so there is no full time person 
doing the patches for the bugs.

once they are completed and testing has been done then there will be a 
release.
right now we are about 4 months past the planned release date.

Matt Warnock sent the following on 8/30/2010 9:27 PM:
> Thanks.  Is 10.04 nearing release?  Is there an expected release date?
> Just curious.

Re: Best practices for updates from trunk

[Matt Warnock <mw...@ridgecrestherbals.com>]

Thanks.  Is 10.04 nearing release?  Is there an expected release date?
Just curious.
-- 
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.

On Mon, 2010-08-30 at 20:31 -0700, BJ Freeman wrote:
> then I suggest best practices is not to do it till a release.
> as your db gets larger the processes of verifying everything can take 
> weeks or months.
> 
> do your testing against a copy of your production.
> 
> =========================
> BJ Freeman  <http://bjfreeman.elance.com>
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
> 
> Chat  Y! messenger: bjfr33man
> Matt Warnock sent the following on 8/30/2010 5:28 PM:
> 
> 
> > Thanks, BJ, but I am looking for best practices on how to do it NOW, not
> > the automated component under design for the future.  The emails you
> > mentioned don't really address any of the questions below.  But neither
> > does any of the existing docs I have found so far. :-)
> >
> > Pointers, anyone?
> >
> > I did try "./ant run-install-seed" on an existing database (previously
> > created with "run-install"), it ran without obvious errors and the
> > number of rows changed that it reported was several thousand, but less
> > than the number with "run-install".
> >
> > So can it (usually) be safely run on a production database, and will it
> > have the intended effect of updating the seed data (if necessary)
> > without deleting/overwriting the production data that may refer to that
> > seed data?  From previous database experience, I know that
> > updating/removing/replacing data to which other data points is often a
> > problem, to say the least.
> >
> > Also, are there any pros and cons for putting the OLAP datasource in a
> > separate database from the main data source?  The existing derby demo
> > uses two, but most of the setup tutorials I find are pretty vague on
> > this point, but if I point both data sources to the same postgresql
> > database, I see no obvious errors.  Am i asking for trouble down the
> > road?  What is the difference between the two, and are there data
> > collisions I'm not seeing yet?
> >

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

then I suggest best practices is not to do it till a release.
as your db gets larger the processes of verifying everything can take 
weeks or months.

do your testing against a copy of your production.

=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Matt Warnock sent the following on 8/30/2010 5:28 PM:


> Thanks, BJ, but I am looking for best practices on how to do it NOW, not
> the automated component under design for the future.  The emails you
> mentioned don't really address any of the questions below.  But neither
> does any of the existing docs I have found so far. :-)
>
> Pointers, anyone?
>
> I did try "./ant run-install-seed" on an existing database (previously
> created with "run-install"), it ran without obvious errors and the
> number of rows changed that it reported was several thousand, but less
> than the number with "run-install".
>
> So can it (usually) be safely run on a production database, and will it
> have the intended effect of updating the seed data (if necessary)
> without deleting/overwriting the production data that may refer to that
> seed data?  From previous database experience, I know that
> updating/removing/replacing data to which other data points is often a
> problem, to say the least.
>
> Also, are there any pros and cons for putting the OLAP datasource in a
> separate database from the main data source?  The existing derby demo
> uses two, but most of the setup tutorials I find are pretty vague on
> this point, but if I point both data sources to the same postgresql
> database, I see no obvious errors.  Am i asking for trouble down the
> road?  What is the difference between the two, and are there data
> collisions I'm not seeing yet?
>

Re: Best practices for updates from trunk

[Matt Warnock <mw...@ridgecrestherbals.com>]

Thanks, BJ, but I am looking for best practices on how to do it NOW, not
the automated component under design for the future.  The emails you
mentioned don't really address any of the questions below.  But neither
does any of the existing docs I have found so far. :-)

Pointers, anyone?  

I did try "./ant run-install-seed" on an existing database (previously
created with "run-install"), it ran without obvious errors and the
number of rows changed that it reported was several thousand, but less
than the number with "run-install".   

So can it (usually) be safely run on a production database, and will it
have the intended effect of updating the seed data (if necessary)
without deleting/overwriting the production data that may refer to that
seed data?  From previous database experience, I know that
updating/removing/replacing data to which other data points is often a
problem, to say the least.

Also, are there any pros and cons for putting the OLAP datasource in a
separate database from the main data source?  The existing derby demo
uses two, but most of the setup tutorials I find are pretty vague on
this point, but if I point both data sources to the same postgresql
database, I see no obvious errors.  Am i asking for trouble down the
road?  What is the difference between the two, and are there data
collisions I'm not seeing yet?

-- 
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.

On Mon, 2010-08-30 at 16:22 -0700, BJ Freeman wrote:
> Mat you speak of a combination of Migration conponent and Setup 
> Component now under design.
> I covered most of this under the email subject
> Migration component Ideas 8/26/2010
> also as a expansion
> see the dev list subjects
> Step to automate Setup for entityengine.xml 8/26/20010
> and
> using derby for setup controller
> 
> also
> https://issues.apache.org/jira/browse/OFBIZ-635
> 
> =========================
> BJ Freeman  <http://bjfreeman.elance.com>
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
> 
> Chat  Y! messenger: bjfr33man
> Matt Warnock sent the following on 8/30/2010 2:12 PM:
> 
> 
> > I run a small enterprise and I doubt our needs are unusual.  We would
> > like to run trunk and stay (more or less) current.  We're running
> > postgresql as a backend.  I'm hoping to automate (as much as possible)
> > the update process.  I'm hoping to implement a few things not provided
> > in the standard demo setup.
> >
> > 1) I need to backup the database nightly, so that our daily work doesn't
> > get lost (doh!).  I can use pg_dump for that, but of course it backs up
> > the entire database, including seed, admin-user-login, and site-specific
> > data.  I could also use the webtools dump, which I assume does the exact
> > same thing but in XML, which is a good deal larger in file size.
> > However, webtools won't write an XML file for an empty table, while
> > pg_dump would write a structure definition for that table.  Probably
> > pg_dump would be a good deal faster.  Size and speed issues aside, it
> > seems that neither method differentiates in any way between seed and
> > non-seed data. Am I correct here?
> >
> > 2) To effectively use the webtools backup, I would need to automate it
> > from a cron job.  Is there an easy way to call ofbiz services from the
> > command line, or do I need to schedule a job within OFBiz to do this
> > kind of thing?  What are the pros and cons of a system cron job vs. a
> > scheduled job in OFBiz?
> >
> > 3) I need a log of what version I was running when.  For example, if I
> > update weekly, and on Sunday night I roll forward to the latest trunk
> > revision 970999, and it breaks something, I need to have a log that
> > tells me that Friday (when it worked) I was running 970888, so I can
> > roll back to that revision, until I get the kinks worked out with the
> > upgrade.  Otherwise I have to restore from a dated backup, which I can
> > always do, but it seems that a simple "svn checkout 970888; ./ant build"
> > might be cleaner.  I'm assuming that after updating the code with "svn
> > checkout" I can log the date/time to a file with the output of "svn
> > info".
> >
> > 4) If a revision requires a database update or modification, I would
> > like to know about it in advance, and make sure that manual modification
> > is completed before the upgrade.  I'm assuming what I need there should
> > always be found in:
> > https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring
> > +Data+Migration
> >
> > 5) I would like to update all seed data in place (postgresql) without
> > overwriting the rest of the (non-seed) data.  Will executing "./ant
> > run-install-seed" overwrite the EXISTING seed data in a production
> > database without affecting the non-seed data?  Or it it only intended
> > for use on an empty database, as all the examples I have found do? If
> > the latter, how do you restore only the NON-seed data after a seed data
> > initialization?
> >
> > Are there any other bear traps or best practices that I should be aware
> > of?  Or is this stuff documented somewhere that I have not found?  There
> > was a discussion of it (at least the seed vs. demo data issue) about a
> > year ago on this list, but I didn't see these specific questions
> > answered.
> >
> > Or am I overly optimistic about the possibility of updating a production
> > system regularly as OFBiz trunk changes?
> >
> > Thanks in advance.
> >
> >

Re: Best practices for updates from trunk

[BJ Freeman <bj...@free-man.net>]

Mat you speak of a combination of Migration conponent and Setup 
Component now under design.
I covered most of this under the email subject
Migration component Ideas 8/26/2010
also as a expansion
see the dev list subjects
Step to automate Setup for entityengine.xml 8/26/20010
and
using derby for setup controller

also
https://issues.apache.org/jira/browse/OFBIZ-635

=========================
BJ Freeman  <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Matt Warnock sent the following on 8/30/2010 2:12 PM:


> I run a small enterprise and I doubt our needs are unusual.  We would
> like to run trunk and stay (more or less) current.  We're running
> postgresql as a backend.  I'm hoping to automate (as much as possible)
> the update process.  I'm hoping to implement a few things not provided
> in the standard demo setup.
>
> 1) I need to backup the database nightly, so that our daily work doesn't
> get lost (doh!).  I can use pg_dump for that, but of course it backs up
> the entire database, including seed, admin-user-login, and site-specific
> data.  I could also use the webtools dump, which I assume does the exact
> same thing but in XML, which is a good deal larger in file size.
> However, webtools won't write an XML file for an empty table, while
> pg_dump would write a structure definition for that table.  Probably
> pg_dump would be a good deal faster.  Size and speed issues aside, it
> seems that neither method differentiates in any way between seed and
> non-seed data. Am I correct here?
>
> 2) To effectively use the webtools backup, I would need to automate it
> from a cron job.  Is there an easy way to call ofbiz services from the
> command line, or do I need to schedule a job within OFBiz to do this
> kind of thing?  What are the pros and cons of a system cron job vs. a
> scheduled job in OFBiz?
>
> 3) I need a log of what version I was running when.  For example, if I
> update weekly, and on Sunday night I roll forward to the latest trunk
> revision 970999, and it breaks something, I need to have a log that
> tells me that Friday (when it worked) I was running 970888, so I can
> roll back to that revision, until I get the kinks worked out with the
> upgrade.  Otherwise I have to restore from a dated backup, which I can
> always do, but it seems that a simple "svn checkout 970888; ./ant build"
> might be cleaner.  I'm assuming that after updating the code with "svn
> checkout" I can log the date/time to a file with the output of "svn
> info".
>
> 4) If a revision requires a database update or modification, I would
> like to know about it in advance, and make sure that manual modification
> is completed before the upgrade.  I'm assuming what I need there should
> always be found in:
> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring
> +Data+Migration
>
> 5) I would like to update all seed data in place (postgresql) without
> overwriting the rest of the (non-seed) data.  Will executing "./ant
> run-install-seed" overwrite the EXISTING seed data in a production
> database without affecting the non-seed data?  Or it it only intended
> for use on an empty database, as all the examples I have found do? If
> the latter, how do you restore only the NON-seed data after a seed data
> initialization?
>
> Are there any other bear traps or best practices that I should be aware
> of?  Or is this stuff documented somewhere that I have not found?  There
> was a discussion of it (at least the seed vs. demo data issue) about a
> year ago on this list, but I didn't see these specific questions
> answered.
>
> Or am I overly optimistic about the possibility of updating a production
> system regularly as OFBiz trunk changes?
>
> Thanks in advance.
>
>