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