CC Meeting Full 20070220
croo [n=croo@213.233.138.34] ha entrado en la sala.
hengsin [n=chatzill@60.48.170.8] ha entrado en la sala.
hengsin: hi carlos
CarlosRuiz: Hi Hengsin
CarlosRuiz: Hi everybody
red1: gnite from malaysia
hengsin: Happy chinese new year, red1.
red1: mike .. i have suggested for u to speak on accounting aspects in germany conference
red1: will that be ok?
red1: gongxi hengsin
red1: btw posterita donated tons of wikis today
red1: they passed all previous marks
hengsin: carlos, for [ 1662593 ] Bad behavior of OnlineLogin Help , shall we just change that to a help button that will open the desktop browser when trigger ?
red1: good idea... kontro also gave a gud one that it be a own page shipped within the distros
red1: so it wont be some spy page
CarlosRuiz: Heng Sin, could we make that tab don't load until visited?
CarlosRuiz: like your lazy loading of tab
hengsin: yes, of course, just concern that it is not quite readable either.
red1: so it hit 3 times only when the user clicks on the Help?
red1: not whenever app starts up?
hengsin: loading a html page into the small login window and using the jeditorkit ..
hengsin: bad readability.
Mike_Judd: yes - fine on accounting topics
CarlosRuiz: yes, when I make that I must make bigger the window
CarlosRuiz: it's just that in future I want to integrate the window help also with wiki
CarlosRuiz: but maybe that's the way too -> a button to open the wiki page
CarlosRuiz: yes Hengsin, I like your idea, replace the tab with a button
hengsin: ok, will do that.
CarlosRuiz: good!
hengsin: are we on track for 315 ?
CarlosRuiz: you arrived activated from your holidays -> 10 commits :-)
hengsin: that was done before the holiday :)
karsten_ [n=chatzill@p57A08C2C.dip0.t-ipconnect.de] ha entrado en la sala.
fredtsang [n=chatzill@ADSL-TPLUS-100-50.telecomplus.net] ha entrado en la sala.
karsten_ ahora se llama karsten_thiemann
hengsin: hi, fred
fredtsang: hi hengsin
karsten_thiemann: hi all
fredtsang: hi every1
red1: fred, i was just saying how speechless i am looking at all posterita posted today in the wiki
CarlosRuiz: ok, Hengsin, maybe you have other points for the agenda
CarlosRuiz: I just want to agree with the attendants what else can we need to make Libero as a 2pack package (and possibly other modules)
CarlosRuiz: and if we an make that before 3.1.5
CarlosRuiz: Hi Fred
hengsin: no carlos, just status for 315 an 2pack
fredtsang: hi carlos
hengsin: but victor is not in
red1: i think posterita make a fine impression in any version now...
CarlosRuiz: but we can talk about "general integration" not just libero
red1: sure
hengsin: carlos, I think the modelvalidator extension needs to be implemented, also binary deployment of 2pack
CarlosRuiz: teo_sarca is here?
hengsin: I saw his name in the list :-)
teo_sarca: hi , i around
teo_sarca: basicly :)
teo_sarca: hi all
fredtsang: hi teo
CarlosRuiz: Hi Teo, we need your opinion on 2pack issues because you're an expert on xml2ad
teo_sarca: hmmm, when i played with xml2ad, my solution was to rewrite :), ok now this is not a solution because will take a lot of time...
teo_sarca: basicly we need to imp/exp all elements from AD
teo_sarca: and it would be nice to run sql scripts
teo_sarca: not just sql commands
CarlosRuiz: I was playing with 2pack a lot this weekend
teo_sarca: what you think ?
CarlosRuiz: it's really very beta, but the approach is very good
teo_sarca: and.... ?
teo_sarca: the problem with 2pack is that it has a lot of copy-paste code
red1: yes i saw carlos working very hard at it and usman also managed to put up libero on postgres with carlos help
teo_sarca: and it is not using current data
CarlosRuiz: current data?
teo_sarca: so if we will extend AD with other columns we ALWAYS need to check 2pack if it will export/import them
teo_sarca: so the risk to be out if sync (AD vs. 2pack) is bigger
karsten_thiemann: you mean we need a generic approach
karsten_thiemann: 2pack should analyze ad
teo_sarca: yes
CarlosRuiz: not agree, that was in Compiere times, now we have the control
CarlosRuiz: if we add elements to the AD we can ensure that 2pack assimilate them
karsten_thiemann: its much easier
CarlosRuiz: I see the 2pack approach very good
CarlosRuiz: really
karsten_thiemann: not so elegant but easy coding
CarlosRuiz: let me talk you my experience
teo_sarca: carlos, ofcourse we can do everything that we want (the future is wide open :) ), but why we should maintain the twice ?
red1: most important carlos point is that both codes are now within our purview .. directly under our control
teo_sarca: AD and 2pack...
CarlosRuiz: teo because you wrote -> now this is not a solution because will take a lot of time...
CarlosRuiz: and 2pack has almost all elements in AD
CarlosRuiz: is just a matter of adding a few
CarlosRuiz: and even more elements, not just AD, can export data too, and files, and sql statements ... etc
CarlosRuiz: ok, my experience was -> I developed a whole model for a customer, all in one submenu
CarlosRuiz: then I created a package with packout with only one element -> the menu
CarlosRuiz: and exported
CarlosRuiz: and "magically" the 2pack exported all below that
CarlosRuiz: menu -> windows -> tabs -> tables -> columns -> references -> fields -> processes -> ...
CarlosRuiz: that's a good approach from my point of view !!!
red1: XMPAD and 2pack is same idea originally to be a tool... it still isnt perfect.. but we now can continue it
red1: XMPAD = XML2AD
CarlosRuiz: I confronted lots of problems when importing, so I made lots of improvements for 2pack this weekend
CarlosRuiz: yes, 2pack put the easiness of use for xml2ad
CarlosRuiz: people not-geek can use 2pack
karsten_thiemann: carlos I had a compiling problem with 2Pack yesterday
hengsin: teo, I think it is ok, it is mostly just simple xml programming. I agree though we need to enhance the code to make future addition easier.
panji_alam [n=panji@202.157.207.241] ha entrado en la sala.
panji_alam: hello everybody
teo_sarca: hi
red1: we can see robert klein's argument about why he thinks XML2AD wasnt enough
CarlosRuiz: which problem Karsten?
CarlosRuiz: Hi Panji
karsten_thiemann: dbport now depends on base but base project is compiled after dbproject
panji_alam: hi teo, hi carlos
hengsin: carolos, dbport should not have dependency on base.
teo_sarca: hi panji
CarlosRuiz: and that's the way -> non-geek can develop in Adempiere -> non-people can make installers and install in other sites with 2pack
red1: which makes adoption even easier
red1: and we do more upper stuff
CarlosRuiz: ok, maybe we need to move 2pack to other package
karsten_thiemann: couldn't solve that problem of chicken and egg...
hengsin: we can move it to base
CarlosRuiz: yes, to base, agree
hengsin: and we should not have class with default package
red1: yes, since its already deployed in System
CarlosRuiz: I don't have such problems in eclipse because I have only one big package in trunk
teo_sarca: me too :)
CarlosRuiz: the class with default package was intended to run standalone, I think that we don't need it anymore
CarlosRuiz: or it can be enhanced to make a installer tool without entering to Adempiere'
karsten_thiemann: I just tried to run the build.bat...
CarlosRuiz: ?
CarlosRuiz: RUN_build? strange, I ran that tool frequently
hengsin: carlos, run_build will fail if dbport have dependency on base
CarlosRuiz: but not after my changes :-(
karsten_thiemann: If you clean everything than you will have a problem
teo_sarca: i suppose karsten run a RUN_clean first
CarlosRuiz: maybe I added such dependency because I changed lots of X_ for M
karsten_thiemann: if not it will reference the old base.jar
red1: it is ok after 2nd run rite?
karsten_thiemann: no I had circular dependencies
CarlosRuiz: but X_'s and M's are in the same package?
red1: i did run clean first too recently and no problem
karsten_thiemann: but not much time to solve the problem
red1: just last week
karsten_thiemann: so I just left it for tomorrow...
CarlosRuiz: ok, I'll test that and fix if I opened a problem, thanks for reporting :-)
CarlosRuiz: so, I think that we really NEED to enhance 2pack
CarlosRuiz: even with my improvements I had more problems when installing on client
CarlosRuiz: i.e. -> doesn't export dynamic validations
hengsin: Is libero should be use as the test case here for 2Pack ?
CarlosRuiz: created wrongly the primary key -> I changed this mechanis completely and adopted the same within Adempiere
CarlosRuiz: yes, I think libero must be the complete test case
CarlosRuiz: libero have all dictionary entries
CarlosRuiz: even workflows
teo_sarca: 2pack doesn't export wf.
red1: this is the chance to look at it then
CarlosRuiz: the problem is (same again)
CarlosRuiz: that we need team to make the enhancements on 2pack, normally the program evolves when someone need it (like me this weeked) :-)
hengsin: so what is the outstanding issue to install libero using 2pack ( other than wf ) ?
CarlosRuiz: we can expect more bugs
CarlosRuiz: BTW, I tested the patches.jar and customization.jar in my customer site, and it worked very well !!!
CarlosRuiz: I put the packin+packout classes in patches.jar - and all the customized classes (including ModelValidator for customer) in customization.jar
red1: wow great!
CarlosRuiz: it worked smoothly :-)
CarlosRuiz: my client is in 314, but using the last bug fixes of 2pack in trunk
teo_sarca: carlos, for your customization, do you modified some of the existing classes ?
CarlosRuiz: no
teo_sarca: ok
CarlosRuiz: all in ModelValidator, and new X_ and new M
CarlosRuiz: but it will work if I change existing classes and put it into patches.jar
CarlosRuiz: I made that with 2pack classes
CarlosRuiz: so, the answer is yes, excuse me, I changed existing classes
red1: ooo man.. thats briliant
hengsin: we shoud avoid that, customization by mofiying classes in core.
CarlosRuiz: yes, that's for bug fixing
CarlosRuiz: and that's what I made bug fixing on 2pack classes
CarlosRuiz: but anyway, in all projects you'll finish modifying some core classes
teo_sarca: not always, some times you really need to modify existing clasess, you have no other option !
CarlosRuiz: exactly, like VLocation
hengsin: yes, be pragmatic where necessary, but that should be one of the objective.
CarlosRuiz: so, it's better to keep your modified classes in one single point for clarity
hengsin: it often means weakness in the core
CarlosRuiz: ok, I think that adding workflows for 2pack is easy
red1: its an exit clause for developers seriously using ADempiere
CarlosRuiz: so, we're going to need -> improve 2pack, test and stabilize 2pack, add ModelValidator for packages
red1: to have customizations.jar
hengsin: customizations.jar should be an interium solution, we need better approach in future ...
red1: defintely... i meant that its just an exit clause
red1: last resort
CarlosRuiz: I don't think so
CarlosRuiz: why? In every project you construct lots of classes specific for the project
CarlosRuiz: all X_ specific customer classes can be there
red1: then it shuld be in different jar... overloading isnt it?
fredtsang: yeah carlos has a point
CarlosRuiz: yes, that's the intention of customization.jar and patches.jar
red1: so ok.. those classes in single place = custom.jar
hengsin: that's a complex topic, lets talk about that later,
red1: but as project vertical specific, not generic matters
CarlosRuiz: customization.jar for specific project classes
CarlosRuiz: patches.jar for bug fixing that will be included in next releases
red1: later as time goes by, we can know what can be factored
CarlosRuiz: ok, let's talk then
CarlosRuiz: if we allow ModelValidator for every package
CarlosRuiz: where are we going to put such ModelValidator?
CarlosRuiz: we can talk about Libero, how are we going to integrate Libero?
CarlosRuiz: libero classes as a jar?
hengsin: yes, what 2pack will do now ?
CarlosRuiz: 2pack will help with the export/import of all AD entries
CarlosRuiz: and creating views with sql statement
red1: if libero is specific .. shuld be in specific jars
CarlosRuiz: but about the libero/src classes
red1: victor is doing HR stuff too... that shuld be separate jar
hengsin: isn't 2pack also handle deployment of classes ?
CarlosRuiz: that's my point, I would prefer a clean installation, where people must not look for changes on classpath
CarlosRuiz: yes hengsin, but it will need compiler and sources
CarlosRuiz: I think that with a jar you just drop the jar and the thing will work, without compiling
CarlosRuiz: the easy path for final users :-)
red1: easier to communicate
karsten_thiemann: but only for optional modules
hengsin: you need a more managed approach when you have multiple extensions ...
CarlosRuiz: exactly
CarlosRuiz: how can we make that without user changing the classpath?
hengsin: think of you need to install libero, posterita etc ...
CarlosRuiz: good example, posterita + libero
hengsin: so one single customization.jar approach will have limitations
CarlosRuiz: we need a ModelValidator for posterita and other for libero
panji_alam: carlos, so u suggest that libero and posterita as different jar files?
karsten_thiemann: and maybe two modules need to modify the same core class...
CarlosRuiz: if we put them in different jars, suppose posterita.jar and libero.jar
CarlosRuiz: how are we going to use it without changing the RUN_Adempiere to add jars to the classpath?
CarlosRuiz: Karsten, that's what we look with ModelValidator for package
CarlosRuiz: allow packages to extend core classes without touching them
karsten_thiemann: ah ok
karsten_thiemann: good
CarlosRuiz: but it must be tested :-) it's just an idea
hengsin: you need some sort of extension manager to manage and automate the installation of extensions, dynamic loading etc ... but thats for the future :)
CarlosRuiz: it can be easier meanwhile to make an installer that put classes into customization.jar ?
CarlosRuiz: or we can add a new packages.jar
CarlosRuiz: and install there
CarlosRuiz: to keep the customization.jar clean for customer classes
hengsin: or a script to package everything into Adempiere.jar ( assuming no conflict of classes ) ...
hengsin: of course customization.jar should work just fine too.
CarlosRuiz: my point is to keep Adempiere.jar clean, Adempiere.jar must be specific for the release
hengsin: yes, packages or extension.jar for add on modules would be good
CarlosRuiz: and the "installer" can drop the classes from posterita.jar to packages.jar and then the classes from libero.jar there too
hengsin: ideally we should incorporated that into the '2pack installer'
karsten_thiemann: wouldn't it be enough to have an extension (jar) folder
karsten_thiemann: and put more than one jar in there?
hengsin: karsten, good point
hengsin: like jre/lib/ext
teo_sarca: agree with karsten !
CarlosRuiz: yes, if this can be done it will be good
panji_alam: so, we create specific folder for vertical module package jar files?
red1: this makes all the jars look logical
CarlosRuiz: how do you make the classpath to look all files that we drop there?
CarlosRuiz: and visually you know which packages are installed !!!
red1: in eclipse this is automatic isnt it?
CarlosRuiz: but for final users
CarlosRuiz: I mean for Adempiere client
hengsin: red1, yes
teo_sarca: carlos, you can add the jars to the jnlp file
CarlosRuiz: that's what I'm trying to avoid
karsten_thiemann: I think you can specify a folder in classpath - but I'm not shure
panji_alam: sorry to think this stuff too further, i just wonder if we will use soa style to integrate different modules for the future architecture
CarlosRuiz: we must avoid instructions for users to change RUN_Adempiere or jnlp files
teo_sarca: then we need a jnlp file generator
CarlosRuiz: and a RUN_Adempiere.bat .sh generator?
CarlosRuiz: and an Adempiere.exe generator?
teo_sarca: NO!
teo_sarca: for the .bat and .sh is easy
teo_sarca: parse the directory and look for jars, add to CP and then run java
teo_sarca: a lot of java oss do this is the same fashion....
CarlosRuiz: an environment variable can serve for that?
CarlosRuiz: I mean, an environment variable can work for .bat .sh .jnlp and .exe ?
teo_sarca: why not ?
teo_sarca: look, for example, this is a part of the iReport runner:
teo_sarca: set CLASSPATH=%CLASSPATH%;.\classes\
teo_sarca: rem Add all jars....
teo_sarca: for %%i in (".\lib\*.jar") do call ".\bin\cpappend.bat" %%i
teo_sarca: for %%i in (".\lib\*.zip") do call ".\bin\cpappend.bat" %%i
teo_sarca: ......
CarlosRuiz: looks good
CarlosRuiz: and easy
teo_sarca: (can be simplified a little)
CarlosRuiz: the jnlp can have that logic?
karsten_thiemann: with java 6 you can use wildcards in classpath: java -cp 'lib/*'
teo_sarca: hmm, you need to generate an xml file....
teo_sarca: good one, karsten
hengsin: or use environment variable
teo_sarca: hengsin, what do you mean ....?
karsten_thiemann: right
red1: env vari is for windows isnt it?
CarlosRuiz: I think the easier can be the environment variable
CarlosRuiz: just wonder if it works with jnlp too
CarlosRuiz: and for linux too red1
teo_sarca: sorry but i can figure out how can work env vars. and web start. what to do with that env vars ... the java web start need to download the jars
CarlosRuiz: yes, you're right
hengsin: yes, jnlp doesn't seesm to work with env variable
CarlosRuiz: :-( so maybe the best will be a packages.jar
hengsin: so, you need a script to update the jnlp file
panji_alam: so, we have to set env and jnlp seperately?
CarlosRuiz: if we add a packages.jar we don't need that
teo_sarca: carlos, packages.jar is a solution, but web start likes more jars ... then one big fat jar like Adempiere.jar
teo_sarca: in this way you optimize your download time....
CarlosRuiz: I don't understand
teo_sarca: if you have to change one class
teo_sarca: (in libero for example)
CarlosRuiz: one Adempiere.jar with posterita+libero included must have same size that Adempiere.jar + posterita.jar + libero.jar
CarlosRuiz: excuse me
CarlosRuiz: Adempiere.jar + package.jar (with posterita and libero included)
red1: yes.. u can update only one jar instead of a big one rite?
teo_sarca: yes, true!
red1: i tried that and it worked
teo_sarca: but you don't need to download the untouched jars
red1: u need not redeploy javaclient
CarlosRuiz: ah, understand
teo_sarca: web start will download just what have been changed
red1: yes thats auto too
teo_sarca: true!
red1: it makes deployment much faster for new developments
CarlosRuiz: even better, more arguments for customization.jar and patches.jar
teo_sarca: red1, and updates much faster too :)
CarlosRuiz: Hengsin, maybe is better not integrate customization.jar and patches.jar in Adempiere.jar
red1: sorry teo... i meant that too :D
red1: i think the logical view is good.. adempiere.jar as a horizontal one.. the others as verticals
CarlosRuiz: in a typical installation, Adempiere.jar won't change but customization.jar can change daily while you're stabilizing
red1: as time goes by, those within custom and patches that affect core when stable can be moved to adempiere.jar
hengsin: carlos, you have a problem here if customization.jar is one single jar that is constantly chaning from time to time ...
CarlosRuiz: ???
red1: or we can have two adempiere.jars - 2 layers view
red1: just a tot
hengsin: you can forgot what is already in there :)
CarlosRuiz: :-) bad implementor if you forget what is in customization.jar
kontro [n=tko@e82-103-220-167.elisa-laajakaista.fi] ha entrado en la sala.
CarlosRuiz: in every release migration you need to look for customization.jar and patches.jar to see what applies and what not, and what must be modified
teo_sarca: (brb)
hengsin: yes, but what you describe is a very manual process which can be error prone especially when it is dedicated out.
red1: maybe a list of packages is stated somewhere?
red1: xml based?
CarlosRuiz: I think is more dangerous to integrate customization.jar and patches.jar into Adempiere.jar, that is not clear
panji_alam: carlos, u mean we can focus to each jar files for different purposes?
CarlosRuiz: yes, we need that too, red1
red1: we need new stuff to apply for proper naming convention
CarlosRuiz: yes, customization.jar - patches.jar - and now packages.jar
CarlosRuiz: and the order in classpath is very important, because overloading
hengsin: carlos, another issue is possible duplication of classes, depending on order of classpath is dangerous.
CarlosRuiz: yes, is dangerous but powerful
CarlosRuiz: bad used will be a mess, well used is very powerful
karsten_thiemann: customization needs to excell all others
CarlosRuiz: yes, currently the order is 1 - customization 2 - patches 3 - Adempiere
red1: the CC shuld dictate the proper naming and listing of order
CarlosRuiz: packages.jar must be 2.5 ?
karsten_thiemann: right
karsten_thiemann: patches can include patches for packages
CarlosRuiz: yes, good for that too
red1: or 2b... package shuld apply different qualified names
hengsin: carlos, jnlp might load things in different order
CarlosRuiz: jnlp doesn't take account of the order of jars defined there?
croo: it just needs to be consistent in how it loads .. then we can ensure the order is right
hengsin: I remember the main jar is always loaded first ...
CarlosRuiz: hmm, just found a bug in jnlps
CarlosRuiz: CompiereJasperReqs.jar was added on adempiere.jnlp but not in adempiereDirectTemplate.jnlp
hengsin: btw, any reason why we need 2 jnlp file ?
CarlosRuiz: hmmm, so jnlp acts different from java client
hengsin: teo, ayt ?
CarlosRuiz: I think you could distribute adempiereDirectTemplate without downloading jnlp from server
CarlosRuiz: I also have had problems with adempiere.jnlp not putting the sortcut on desktop, but adempiereDirect can
hengsin: ok, it just looks confusing to me
CarlosRuiz: so, your approach of integrating into Adempiere.jar for jnlp is ok
CarlosRuiz: if jnlp looks for main first
hengsin: we also need to check the behaviour for ejb ...
CarlosRuiz: ok
CarlosRuiz: what else can we need for posterita and libero as packages ?
teo_sarca: ( back, i am reading the log...)
hengsin: teo, can you comment on the jnlp jar loading sequence ?
croo: all the talk here is of jars but isn't posterita web based? and so won't the deployment be of a war?
AFalcone [n=AFalcone@190.49.84.74] ha entrado en la sala.
fredtsang: true
fredtsang: but we depend on the adempiere jars
croo: simplies the client deployment of course .... no ned for webstart
AFalcone: Hi team!
CarlosRuiz: Hi Alejandro
fredtsang: hi alejandro!
teo_sarca: hengsin, carlos, the jar that is marked as "main" is loaded first !
teo_sarca: for the rest jars, i don't know which is the order
hengsin: thanks, teo.
red1: hi Afalcone
CarlosRuiz: yes, so hengsin solved that problem with repackaging the adempiere.jar in order
CarlosRuiz: but it's needed that, users always must download the whole Adempiere.jar
teo_sarca: but if you want to overwrite a class (using patches.jar), and that class is in the main jar, you won't !
CarlosRuiz: Teo, hengsin solved that problem already
teo_sarca: how ?
CarlosRuiz: he's repackaging completely the adempiere.jar in run_build
CarlosRuiz: and he takes account of the order of jars
teo_sarca: aha, ok
fredtsang: nice one
teo_sarca: when is was using compiere, my workaround was to copy the Compiere.jar is my main customization jar ... dirty but it worked
teo_sarca: Compiere.java i mean
CarlosRuiz: ok, then we have agreement that libero must be released as a package, and that libero will be the stress test for 2pack
CarlosRuiz: right?
hengsin: yes
hengsin: posterita too
CarlosRuiz: sorry that Victor's not here
teo_sarca: one more question: there is some functionality in the libero that should be added to the base project ?
CarlosRuiz: I just want to make notice that instead of blaming 2pack problems we need to improve it
hengsin: carlos, do u know ?
fredtsang: yes we'll get that in a package
CarlosRuiz: about manufacturing and hr I think they can be complete packaged
CarlosRuiz: Victor said me that he's going to test some new functionalities in libero
CarlosRuiz: like master/detail
CarlosRuiz: vertical tabs
CarlosRuiz: that must be integrated into trunk if it works
CarlosRuiz: I'm worried too because libero branch is not being synchronized with trunk
teo_sarca: i think that the functionalities that applies to the core should integrated in the core.....
red1: agreed teo
teo_sarca: > I'm worried too because libero branch is not being synchronized with trunk
teo_sarca: i belive that we can talk with victor to sync offen :)
red1: but shuld be done in maturity stages
teo_sarca: yes
red1: cos lots of checking needed
CarlosRuiz: no, I mean libero kept in synch with turnk
red1: i.e. our 314 seems to get bugs reports that werent there in 313
CarlosRuiz: libero assimilating changes in trunk
red1: that is sure
red1: and it remain a synched branch all the time for long testing firtst
red1: cos what victor done is a lot
red1: not easy to understand if he done it well or not.. sometimes some small bug gives impression that its all chaos
red1: well guys... adempiere is becoming a monster isnt it?
AFalcone: I believe that Victor has done a sync. with trunk some days ago
karsten_thiemann: :)
AFalcone: maybe 1 week ago
red1: and this morning usman downloaded latest and able to make it run libero adempiere
karsten_thiemann: It was a monster right from the start
hengsin: red1, it is always a monster :)
CarlosRuiz: really I think that Victor has made a good job
red1: this time monster we know
karsten_thiemann: but more knights now
CarlosRuiz: but it's better to keep it as a package initially
red1: with little devils we know running around with it
teo_sarca: agree with carlos !
teo_sarca: (victor did a great job and a great contribution !)
red1: its good that we have double confirmation
red1: bazaar style
karsten_thiemann: we will get some bug-reporting trouble with all those packages
karsten_thiemann: you have to specify which modules/versions you have installed
CarlosRuiz: and patches, and customizations
hengsin: haha ... you can't even do that in SF tracker ...
karsten_thiemann: cause maybe you have side effects that causes the bug
red1: wonder if its better to release more often so that different packages get rolled out
red1: so that bugs are clearly due to different specific releases
CarlosRuiz: I think in the "report bug" link in menu
CarlosRuiz: we must add a list of customization and patches
red1: yes more list is easier to identify what causes there could be
karsten_thiemann: and combinations of them :)
hengsin: can 2 pack do uninstall or deactivation ?
CarlosRuiz: it's supposed to have an uninstall
CarlosRuiz: but I haven't tested
red1: yes
CarlosRuiz: and I think that it won't work at first
AFalcone: yes hensing, i believe that is posibble uninstall
red1: me neither
hengsin: will be good too if we can deactivate a package to test
CarlosRuiz: ok, now the problem is "who" ?
CarlosRuiz: who is going to make the 2pack enhancements?
AFalcone: I tested this feature, some months ago (with Compiere) and worked fine
CarlosRuiz: who is going to make the modelvalidator for packages?
red1: according to the manual it stores all changes so that it can undo them
hengsin: I can help on the 2pack enhancement.
CarlosRuiz: thanks hengsin, we're going to need lots of help here
CarlosRuiz: but 2pack will be the killer-app :-)
CarlosRuiz: good, do we have more themes today? or we can finish the meeting?
teo_sarca: (i don't have)
hengsin: agree to adjorn
panji_alam: hengsin, its 1.00 am in our place already
hengsin: yes, panji, time to bed ;)
CarlosRuiz: thank you very much to all attendants
AFalcone: Carlos, some news about the OnlineLoginHelp issue?
CarlosRuiz: yes, Hengsin proposed changing the tab by a button
CarlosRuiz: a button to open a window and navigate to the proper page
panji_alam: time to sleep (hengsin to), bye all
CarlosRuiz: bye
panji_alam ha salido de la sala (quit: "Leaving").
fredtsang: bye
teo_sarca: bye
hengsin: AFalcone, agree ?
AFalcone: ok, cool
hengsin: bye then
hengsin ha salido de la sala.
AFalcone: yes hengsin, i agree
karsten_thiemann: bye
AFalcone: bye all then
karsten_thiemann ha salido de la sala.
teo_sarca: bye bye
teo_sarca: i got to go too,
