Hi Juan Pablo,

It was me the one who committed the [img] project merge. I'm really 
sorry about this, I shouldn't have done it without running Synchronize 
Terminology, but I normally don't add things to the Application 
Dictionary, so I'm really not yet used to it. I will try not to make 
this mistake again in the future.

One possible solution to this problem would be to automatically execute 
the Synchronize Terminology process just before the export.database 
task. This would mean that developers wouldn't need to remember to do 
it, but it would add about 30 secs to the overall duration of the 
export.database process. We would need to carefully consider if this is 
worth it.

Anyway, sorry for the inconvenience, and I'll try to not repeat this 
error in the future. Kind regards,

Antonio.

Juan Pablo Aroztegi wrote:
> The build is still failing. Apparently the [img] project merge did not
> run the synchronize terminology process.
>
> Those who worked in that project: can you fix this please?
>
> I would to share with all of you some statistics about this build. Last
> month (From August the 1st till 13th of September):
>
>   * Failed builds: 23
>   * Successful builds: 32
>
> That is, 40% of the times the build is broken. Some of the
> inconsistencies need up to 1 week to be solve, for example this last
> one. I wonder which of the following statements is true:
>
>   1) A portion of the developers push to pi without caring about the db
>      consistency. The "let hudson check it all for me" philosophy.
>   2) A portion of the developers consider a broken build not important
>      enough as to keep it broken for 1 week.
>
> I think that following 1) sad. Because Hudson is not able to catch all
> the bugs, just a small portion. And if Hudson is able to detect so
> obvious errors, what else is pushed to the mainline?
>
> Nevertheless, if we even considered 1) as correct, its acceptance means
> fixing it very fast and therefore 2) makes it difficult to understand.
>
> Developers: why do you think this is happening? What do you suggest we
> do to fix this?
>
> I many times think that a pull-only working model would solve most of
> these problems.
>
>
> Juan Pablo
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Openbravo-development mailing list
> Openbravo-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbravo-development
>
>   


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Openbravo-development mailing list
Openbravo-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbravo-development

Reply via email to