PMC Meeting FULL 20071017
Session Start (Adempiere:#adempiere-team): Wed Oct 17 08:07:51 2007
[08:07] *** #adempiere-team: jsSolutions fernandoxavier CarlosRuiz usm88 vpj-cd shameem hengsin MCalderon red1 fer_luck
[08:07] *** #adempiere-team was created on Wed Oct 17 03:56:42 2007.
[08:07] *** vishee has joined #adempiere-team.
[08:08] hengsin: hi Joel
[08:08] *** croo has joined #adempiere-team.
[08:08] vishee: Hi Everyone
[08:08] croo: hi all
[08:08] *** emontenegro has joined #adempiere-team.
[08:08] jsSolutions: hi all, good group!
[08:08] shameem: Hi all
[08:09] CarlosRuiz: Hi everybody
[08:09] emontenegro: Hi everybody...
[08:09] fer_luck: howdy all again. :-D
[08:09] *** hyksos has joined #adempiere-team.
[08:09] hengsin: shall everybody introduce themself first ? This is Heng Sin from Malaysia.
[08:10] *** eliercio has joined #adempiere-team.
[08:10] fer_luck: Fernando Lucktemberg from Brazil!
[08:10] emontenegro: Eduardo Montenegro from Brazil
[08:10] MCalderon: Mario Calderon from El Salvador
[08:10] vpj-cd: Victor Perez from Mexico
[08:10] eliercio: Eliercio Zolet from Brazil
[08:10] hyksos: hyksos - germany
[08:10] fernandoxavier: Fernando Xavier from brazil
[08:10] vishee: Vishee Ghumundee from Mauritius
[08:11] croo: Colin Rooney from Ireland
[08:11] jsSolutions: joel Stangeland from California
[08:11] shameem: Peerbuccoss Shameem from Mauritius
[08:11] CarlosRuiz: this is Carlos Ruiz from the beautiful country -> Colombia !!
[08:12] *** Niraj has joined #adempiere-team.
[08:12] hengsin: cool, looks like we have a strong group from Brazil.
[08:12] fer_luck: hengsin: yes.. lots of people.. and there're still two missing
[08:12] fer_luck: :-D
[08:12] vishee: We too from Mauritius
[08:13] croo: an with red1 two from Malaysia! :)
[08:13] hengsin: Carlos: anyone else from Columbia ;)
[08:13] CarlosRuiz: Colombia
[08:13] vishee: Just missing Fred and Ashley from Mauritius
[08:13] CarlosRuiz: nobody else, supposedly tomorrow we'll get attention from Colombian people
[08:14] hengsin: carlos: oops sorry, typo.
[08:14] fer_luck: CarlosRuiz: Colombia localization is due for tomorrow?
[08:14] CarlosRuiz: yep - tomorrow 8AM GMT-5
[08:14] fer_luck: awesome.. we just released adempierelbr here
[08:14] fer_luck: to anyone who might have interest... (Link: www.sourceforge.net/projects/adempierelbr)www.sourceforge.net/projects/adempierelbr
[08:17] hengsin: probably time to start a localization pattern and best practise wiki page - The Colombia and Brazil experience.
[08:17] fer_luck: hengsin: very good idea.. We still have a lot to do for Brazilian localization, but it's a time issue
[08:17] fer_luck: Carlos, what about who has additional topics to discuss? can they get into this meeting?
[08:18] hengsin: yep, a good way to start some interesting conversation between the colombia and brazil group.
[08:19] CarlosRuiz: well, if you want we can start - do you consider is there enough quorum?
[08:19] CarlosRuiz: Proposed Agenda
[08:19] CarlosRuiz: 1. Trunk FreezeÂ
[08:19] CarlosRuiz: 2. Bug DayÂ
[08:19] CarlosRuiz: 3. 3.4 Release TargetÂ
[08:19] CarlosRuiz: 4. Libero Manufacturing IntegrationÂ
[08:19] CarlosRuiz: 5. Possible move of Fixed Assets and AjaxUI to trunk- should these be tackled simultaneous to Libero, or after?Â
[08:19] CarlosRuiz: 6. 4.1 Release TargetÂ
[08:19] CarlosRuiz: 7. Others - if time and energy allow this
[08:19] hengsin: Carlos: I think we can start now
[08:20] fer_luck: CarlosRuiz: I think it's very important for us to get some pool method for new functionalities under adempiere
[08:20] fer_luck: I mean, where we can create pools to see if people want something integrated into trunk.. this could be no. 8..
[08:20] CarlosRuiz: what's a pool method - I didn't understand the work
[08:21] fer_luck: well, pools, like who wants this into trunk.. with yes and no answers...
[08:21] fer_luck: but everyone that votes must be logged in..
[08:21] CarlosRuiz: ah, polls
[08:21] fer_luck: sorry
[08:21] fer_luck: hehe
[08:21] CarlosRuiz: yep, ok
[08:21] emontenegro: He meant Polls ..... Poor guy ..... hehehe
[08:21] fer_luck: so everyone can know what's for inclusion on trunk, and if it will or won't be included.. each poll should last 2 weeks or so..
[08:21] fer_luck: oh boy
[08:21] fer_luck: :-)
[08:22] *** X0d_of_N0d has joined #adempiere-team.
[08:22] fer_luck: I guess there must be a poll extension for wiki.. maybe on the front page..
[08:22] X0d_of_N0d: I hope no one minds if I sit in on this.....
[08:22] jsSolutions: joomla easily sopports polls
[08:22] CarlosRuiz: there is one poll mechanism in joomla adempiere.com
[08:23] fer_luck: can be that one.. I think it's better, so everyone has visibility about what's going and what's not going into trunk
[08:23] *** svanga has joined #adempiere-team.
[08:23] CarlosRuiz: that's not real
[08:23] CarlosRuiz: polls just express desire - but without contributors we can't make the work
[08:23] svanga: Hi all I apologize for the delay.
[08:23] hengsin: yep, that could be usefull for inclusion of new module. however, we should have some criteria for the inclusion of new module as part of the core.
[08:24] fer_luck: Well, I think that the voting method we have right now is not working well
[08:24] fer_luck: I completely missed the inclusion of posterita for not reading the forums.. :-/
[08:24] *** ashley_1 has joined #adempiere-team.
[08:24] jsSolutions: Carlos,, I think we can begin the agenda
[08:25] fer_luck: Let's begin..
[08:25] CarlosRuiz: 1. Trunk FreezeÂ
[08:25] hengsin: I think one of the issue is we have too many forum, confusing at time, anyway, back to the agenda.
[08:25] fer_luck: hengsin: agreed..
[08:26] hengsin: carlos: what is your proposal ?
[08:27] CarlosRuiz: well, I consider current trunk a lot unstable
[08:28] CarlosRuiz: we're 3-months old from Victoria beta - and 6-month from Mayday stable
[08:28] CarlosRuiz: I think is time for a new freeze and target a stable
[08:28] CarlosRuiz: and this idea intersected now with Sun proposal of stabilizing Victoria - and the proposal of integrating manufacturing into trunk
[08:28] CarlosRuiz: so it becomes a need at this moment
[08:29] fer_luck: Sun?
[08:29] vpj-cd: yes fer
[08:29] vpj-cd: (Link: https://sourceforge.net/forum/message.php?msg_id=4567705)https://sourceforge.net/forum/message.php?msg_id=4567705
[08:30] vpj-cd: what is the main issue current version?
[08:30] CarlosRuiz: a lot
[08:30] CarlosRuiz: a lot to stabilize
[08:30] fer_luck: well, RMA for once never worked for me, at least.. I don't know If I'm not using it right..
[08:30] CarlosRuiz: RMA
[08:30] CarlosRuiz: c3po
[08:30] CarlosRuiz: POS
[08:30] CarlosRuiz: Costing
[08:30] CarlosRuiz: dashboard
[08:31] fer_luck: WOW..!! sun? dang..
[08:31] CarlosRuiz: we're running in 218 open bugs!
[08:32] X0d_of_N0d: Yeah, that gaping security bug needs to be taken care of... but I doubt that'll be fixable by the next release
[08:32] CarlosRuiz: 31 top priority (7 or 9)
[08:32] CarlosRuiz: 100 not triaged
[08:32] hengsin: all needs to be verified again
[08:32] CarlosRuiz: that's a lot of work to get a new stable
[08:33] vpj-cd: can we then release a stable version?
[08:33] vpj-cd: or the goal is release a beta version?
[08:33] CarlosRuiz: we also have talked about releasing beta versions frequently
[08:34] hengsin: that's the problem as we are not having any regression test in the application, it is not known whether all this are new bug, regression or ...
[08:34] CarlosRuiz: but no contributors for releasing
[08:35] X0d_of_N0d: It seems that it might be wise to tag a new beta, then work on stabalizing 3.3.0
[08:36] CarlosRuiz: not one - the ideal is to release a lot of betas
[08:36] CarlosRuiz: 331, 332, 333, 334 ..... 340!
[08:36] fer_luck: As far as I understand 330 is a beta version, so we're going to stabilize it?
[08:36] hengsin: yep, more release so it is easier for people to test
[08:36] fer_luck: nice idea
[08:36] X0d_of_N0d: tag a beta, finish stabalizing the last, move on...
[08:36] X0d_of_N0d: rinse repeat...
[08:37] jsSolutions: this seems an obvious conclusion: we need to target a stable release, set a date, and do as much as we can by then
[08:37] fer_luck: I mean, with regression?
[08:37] vpj-cd: yes if we close to 334 then we can release stable version
[08:37] CarlosRuiz: or 335, 336, 337 - whatever we need
[08:38] CarlosRuiz: but again this idea is dead letter if there is no people to release - people to test - people to fix
[08:38] vpj-cd: yes and release candidate to stable version
[08:38] emontenegro: What kind of contribution are we talking about for releasing more betas, as mentioned by CarlosRuiz?
[08:38] CarlosRuiz: this type of contribution:
[08:38] CarlosRuiz: (Link: http://adempiere.com/wiki/index.php/Steps_to_Release)http://adempiere.com/wiki/index.php/Steps_to_Release
[08:38] CarlosRuiz: excuse me:
[08:38] CarlosRuiz: (Link: http://adempiere.com/wiki/index.php/Steps_To_Release)http://adempiere.com/wiki/index.php/Steps_To_Release
[08:39] hengsin: and would be great if someone can help to script some of this task. I remember Joel have a server to spare for that. Joel: is that correct ?
[08:39] CarlosRuiz: nightly builds
[08:39] jsSolutions: yes, we set up the server, and we can also make it a live demo, but we need the script for nighly build/deploy
[08:40] jsSolutions: this would be a huge step to better user/regression testing
[08:40] hengsin: Carlos: nightly builds and release can be scripted and they should be very similar.
[08:40] X0d_of_N0d: It wouldn't be hard to automate the building of something like a debian package
[08:41] X0d_of_N0d: based on the builds I mean...
[08:41] X0d_of_N0d: but there should be an offical init script and some other config stuff
[08:41] CarlosRuiz: I suppose the problem with nightly builds is to apply the migration scripts on the imported database
[08:41] hengsin: yep, but that can be scripted too
[08:41] fer_luck: Well, that is not that hard to do
[08:41] X0d_of_N0d: no, create a database install package and a application server install package
[08:42] fer_luck: but you gotta make sure the scripts are working ok before trying to apply them automatically
[08:42] CarlosRuiz: well, somebody wanting to make this idea a reality?
[08:43] hengsin: ok, I can work with Joel on that but not this week, either next week or the week after.
[08:44] X0d_of_N0d: Here at work I'm already doing a lot of this stuff, as far as completely committing to it I'd have to talk to my boss
[08:44] X0d_of_N0d: but seperating out the database stuff and the application stuff will need to be done, so I could probabbly work it into my sched
[08:44] fer_luck: I can spare some time for this too.. but the agenda is kind of full. so it might take some time.. I can prepare the script to run the migration scripts against postgresql database
[08:44] CarlosRuiz: that's exactly the problem with these meetings :-(
[08:44] CarlosRuiz: mostly ideas here are dead letter
[08:45] jsSolutions: fer_luck, that's good. demos run on postrgres
[08:45] X0d_of_N0d: how often do these meetings occur?
[08:45] fer_luck: jsSolutions: I think it won't be hard doing this, and I need to develop this anyways to automate my work...
[08:45] CarlosRuiz: Heng Sin working on nightly builds means that Heng Sin is not going to work on fixing bugs .... etc
[08:45] CarlosRuiz: same contributors all the time
[08:45] hengsin: Joel: does the server have Oracle too ? to make a release or night build, we will need both oracle and postgresql running
[08:46] hyksos: i dont wanna disturb, but who wants nightly builds? perhaps that is good for the first poll ?
[08:46] jsSolutions: oracle is available, but the live demo is running postgres
[08:46] vpj-cd: because we do not start with a version to week
[08:46] X0d_of_N0d: Perhaps it would be best to just do weekly snapshots?
[08:47] hengsin: hkysos: come on, we don't need a poll for nightly build ...
[08:47] hyksos: hengsin :ok if you need them
[08:47] CarlosRuiz: I would change the question
[08:47] jsSolutions: well, once the build is automated, it doesnt matter how often it urns
[08:47] CarlosRuiz: who wants to test?
[08:47] jsSolutions: runs
[08:47] jsSolutions: yes, nightly build calls quick attention to broken trunk
[08:47] CarlosRuiz: mostly people just sit around waiting for the next stable release - and don't help with testing :-(
[08:48] vpj-cd: we can build the nightly version
[08:48] vpj-cd: and the user can apply the migration script
[08:48] hyksos: CarlosRuiz :i would test, but i try to build adn run adempiere completly within eclipse, which is not working for now
[08:48] MCalderon: I could test noghtly builds
[08:48] X0d_of_N0d: If a nightly build is avaliable and relatively easy to install, then more people will test
[08:48] hyksos: CarlosRuiz :my things would go into point 7) other stuff
[08:48] jsSolutions: hyksos, you answered your own question :)
[08:48] vpj-cd: we can create a script to apply the migration script
[08:48] CarlosRuiz: please don't take it personal (as Tony did in forums) - I'm not mentioning any name
[08:48] CarlosRuiz: I'm trying to bring attention to a real problem here
[08:49] CarlosRuiz: ok
[08:49] CarlosRuiz: good if we can have nightly builds
[08:49] CarlosRuiz: good if we can have weekly beta releases
[08:49] jsSolutions: weekly beta?
[08:49] fer_luck: I guess if we have weekly builds it would be much better
[08:49] jsSolutions: just an opinion...
[08:49] X0d_of_N0d: that's seems unwise
[08:49] CarlosRuiz: I'm just wondering who is going to make the weekly beta releases
[08:49] jsSolutions: but I think a 'release' should be a media event
[08:49] CarlosRuiz: again
[08:50] jsSolutions: like victoria
[08:50] jsSolutions: so maybe every three months for now is a good idea
[08:50] X0d_of_N0d: beta releases should become stable...
[08:50] X0d_of_N0d: having to stabalize things weekly would be impossible
[08:50] CarlosRuiz: beta releases
[08:50] jsSolutions: a beta release should have some significant new functionality
[08:51] jsSolutions: and we should publicize it
[08:51] jsSolutions: to get attentions
[08:51] fer_luck: It would be nice to work with milestones, like the mozilla fooundation
[08:51] X0d_of_N0d: beta release with bugfix revisions weekly, maybe
[08:51] CarlosRuiz: when linux is releasing - they release several times even in the same day
[08:52] fer_luck: CarlosRuiz: we cannot compare, yet, linux with our small community
[08:52] CarlosRuiz: but they don't have to cope with the database
[08:52] vpj-cd: yes and linux is operation system
[08:52] jsSolutions: in that sense we 'release' every time a bug fix hits the trunk
[08:53] hyksos: linux doenst release several times on the same day, they release once
[08:53] vpj-cd: I think weekly beta release is a good begin
[08:53] X0d_of_N0d: I think every 3 months for beta, 3 months to stable, and weekly bug fix releases is good...
[08:53] fer_luck: I think we should have weekly patches and betas every 2 or 3 months..
[08:53] vpj-cd: I can support generate the dump to postgresql
[08:53] vpj-cd: to each weekly version
[08:54] fer_luck: to do this weekly beta things we would have to pay someone to just do that...
[08:54] jsSolutions: weekly patch would be nice, though
[08:55] hengsin: fer_luck: how you do milestone when you don't even have a release plan/road map :)
[08:55] X0d_of_N0d: betas should only be for adding functionality, that functionality should be stabalized with fixes, then when it's working it should be released as stabled...
[08:55] CarlosRuiz: look, this is just an idea for work - but what's the goal
[08:55] fer_luck: And to make things easier, we should do just like sap does, mantain the version of stuff on the db.. and that goes to migration scripts...
[08:55] CarlosRuiz: what's the goal of nightly builds?
[08:55] CarlosRuiz: what's the goal of frequent releases?
[08:55] CarlosRuiz: what's the goal of release early - update often?
[08:55] CarlosRuiz: are we in capacity of "udpate often"?
[08:56] jsSolutions: goal of nightly builds is better testing
[08:56] fer_luck: hengsin: We can plan it... but there's one thing.. We would have to stabilize and fix stuff, and forget about new stuff..
[08:56] fer_luck: one thing that never sounded right for me in the project
[08:56] fer_luck: two or more people/companies working on the same problem
[08:56] vpj-cd: I think we can test with nightly weekly
[08:56] fer_luck: like webui/AjaxUI, and the other ui that victor was doing...
[08:57] fer_luck: we gotta have focus...
[08:57] vpj-cd: we can view what is the real demand
[08:57] CarlosRuiz: exactly - nightly builds and frequent releases target more testers
[08:57] CarlosRuiz: more non-technical testers
[08:57] CarlosRuiz: what else do we need to get more testers?
[08:57] hengsin: I think a monthly or bi-monthly beta release sounds ok, weekly is just too much work. for nightly build, once it is scripted, it should be painless.
[08:58] jsSolutions: yep
[08:58] CarlosRuiz: what's the deliverable of nightly builds?
[08:58] CarlosRuiz: a new Adempiere_Trunk.jar every night?
[08:58] CarlosRuiz: totally installable?
[08:58] jsSolutions: Carlos, my idea was to build it to the build server
[08:58] jsSolutions: running with nx
[08:58] fer_luck: CarlosRuiz: for me it's a Adempiere_ddmmyyyy.zip
[08:59] jsSolutions: so everyone could just log in to the running server
[08:59] X0d_of_N0d: A better install method would be nice too
[08:59] jsSolutions: no install needed
[08:59] fer_luck: and then later it can be unzipped and ran in the server like joel thinks about..
[08:59] X0d_of_N0d: A demo server is fine, but having people be able to test on their own systems is essential
[08:59] hengsin: Adempiere_ddmmyyyy.zip with uptodate db seed. If time permit, we can script other deliverables as well.
[08:59] CarlosRuiz: Joel, I think we must target for a complete installable
[09:00] fer_luck: So do I
[09:00] *** catsapiens has joined #adempiere-team.
[09:00] CarlosRuiz: nx is restricted in the number of testers
[09:00] CarlosRuiz: and db is refreshed every night
[09:00] CarlosRuiz: not too good for long testings
[09:00] jsSolutions: a daily builds not good for that anyway
[09:00] vpj-cd: yes this is possible if is weekly
[09:00] jsSolutions: changes every night
[09:01] vpj-cd: generality
[09:01] jsSolutions: it only helps unit testing
[09:01] CarlosRuiz: yes, you simply download the latest build and start testing
[09:01] jsSolutions: because your test yesterday may no good
[09:01] CarlosRuiz: and periodically you update your nightly build
[09:01] vpj-cd: the ppl want not create the build code
[09:01] vpj-cd: but the ppl can apply the script in migration your db
[09:01] vpj-cd: generally the ppl have your date to the test
[09:01] CarlosRuiz: non-technicals can't apply patches in db - Victor
[09:02] vpj-cd: they want a new version with your same date
[09:02] jsSolutions: i think 'your same data' is missing the point of daily build.
[09:02] hengsin: Joel: another question is how many archived version of nightly build we can keep on server ? Related to that, anyone else can donate some space for that purpose ?
[09:02] hyksos: is there no way to simply test the svn code? so no builds must be done?
[09:02] vpj-cd: I think is enough if we release a Adempiere binary
[09:02] jsSolutions: IMHO, daily build is to test garden world
[09:03] jsSolutions: it's trunk testing, not integration testing
[09:03] hengsin: hyksos: we are talking about making it easier for non-developer to test or try adempiere.
[09:03] hyksos: yes i know
[09:04] fer_luck: ok.. I have one idea for all this testing stuff.. what if we created a new disk for ava, like installdir, and this directory is mounted as the ava /opt directory and the db directory? then people shouild just download app.vmdk virtual disk and replace by the other day disk.. it would involve some work with ava thing, but it would be easier to end user for testing..
[09:05] hyksos: i wrote a picture-book like howto install and test adempiere svn code, so every admin who wants to test ,can install eclipse,subclipse, but the thing is, it doesnt run out-of-box within eclipse, you must build it and then install the .zip ,circumstansive
[09:05] CarlosRuiz: ok, suppose we can have nightly builds - release it to NX - and release an Adempiere_Trunk_yyyymmdd.tar.gz
[09:05] fer_luck: then weekly someone could rebuild the stuff against this ava disk...
[09:06] X0d_of_N0d: what's ava?
[09:06] fer_luck: ava = adempiere virtual appliance, vmware
[09:06] hengsin: fer_luck: we can release ava on top of that, just someone have to script that as well :)
[09:06] X0d_of_N0d: oh, nm
[09:06] X0d_of_N0d: ick, vmware sucks
[09:06] jsSolutions: Carlos, sounds good. Back to the agenda. Are we agreed we should set a goal for stable release?
[09:06] fer_luck: hengsin: so it would be better for people to test...
[09:07] CarlosRuiz: is there agreement to target a new stable?
[09:07] croo: sorry I had to take call and missed fro start ... just speed read through ... are we still on Freeze ?? - lol
[09:07] hengsin: fer_luck: not necessary, there are disadvantage for ava too, for e.g, the size issue.
[09:07] X0d_of_N0d: I don't disagree that a vmware appliace should be avilable, but it shouldn't be a form of distribution
[09:07] fer_luck: hengsin: but if we just make opt and data dir of postgresql as downloadable, this solves the size issue
[09:07] fer_luck: :-D
[09:08] X0d_of_N0d: hengsin: yeah, and the fact that it's an incredibly slow resource hog
[09:08] CarlosRuiz: I suppose all this exercise of nightly build - AVA, daily release, etc
[09:08] CarlosRuiz: is about learning from our previous experience with mayday
[09:08] CarlosRuiz: very few testers
[09:08] CarlosRuiz: so, ok, we agree that we need to work on this for this stable release
[09:08] jsSolutions: oh, yes sorry colin. only on trunk freeze
[09:08] fer_luck: I agree..
[09:08] hengsin: sure...
[09:08] jsSolutions: does anyone have anything they need in before a trunk freeze?
[09:09] fer_luck: I do
[09:09] fer_luck: I developed an extension for product info window
[09:10] jsSolutions: can it go in this week, two weeks?
[09:10] fer_luck: this extension allows the user to see the stock for each warehouse, see the documentnote of the selected product and see the similar products
[09:10] CarlosRuiz: summarizing
[09:10] CarlosRuiz: - we all think that we need to target a new stable -> 3.4.0
[09:10] CarlosRuiz: - we would need a beta release 3.3.1 at this moment
[09:10] CarlosRuiz: - we need to solve some problems to get more beta testers than mayday had -> nightly builds - nightly release - nightly NX - possibly nightly AVA
[09:11] CarlosRuiz: can we talk about what the 3.4.0 must stabilize
[09:11] CarlosRuiz: and what else can we allow to enter?
[09:11] fer_luck: If my extension can go into trunk, I can commit it until tomorrow
[09:11] CarlosRuiz: I think 3.4.0 must have all type of testings - lot of focus needed on RMA, c3po, dashboard and costing
[09:11] CarlosRuiz: and what else can we allow to enter?
[09:12] vpj-cd: soory carlos what is c3po?
[09:12] fer_luck: c3po is the loggin thing for posterita, right?
[09:12] MCalderon: we have tested RMA
[09:12] croo: review all te patchs & contributions to include too otherwise people won't bother any more!
[09:12] CarlosRuiz: the new pooling and caching mechanism for database
[09:12] croo: I tested RMA too
[09:12] vpj-cd: haaa thank you
[09:13] MCalderon: complicated, but correct
[09:13] CarlosRuiz: and what else can we allow to enter?
[09:13] CarlosRuiz: PERSONALLY -> I would like to see if we can have AJAX web UI
[09:13] fer_luck: CarlosRuiz: Count me in..
[09:13] fer_luck: :-D
[09:13] X0d_of_N0d: A trunk freeze probabbly isn't a bad idea right now
[09:13] croo: AJAX UI sounds big?
[09:13] vishee: Yes we can have AjaxUI in trunk
[09:14] CarlosRuiz: there are A LOT of contributions and feature requests not integrated also
[09:14] CarlosRuiz: in sf trackers
[09:14] fer_luck: CarlosRuiz: I think we should stabilish milestones for the project, what do you think carlos?
[09:14] fer_luck: vishee: You worked with the Web ui right?
[09:14] X0d_of_N0d: What's the numbering scheeme?
[09:14] fer_luck: vishee: ajaxwebui
[09:14] CarlosRuiz: yes fer, that's what we're trying to do now, what's the milestone for 3.4?
[09:14] *** usm88 has signed off IRC ("Leaving").
[09:14] X0d_of_N0d: when 3.3.0 becomes stable it becomes 3.4.0?
[09:14] hengsin: yes
[09:15] vishee: Niraj can reply on that as he has been working on WebUI
[09:15] hengsin: odd for beta, even for release
[09:15] fer_luck: CarlosRuiz: AjaxUI still lacks the choose language dropdown menu...
[09:15] X0d_of_N0d: ok, just checking
[09:15] fer_luck: as does the posterita pos
[09:15] fer_luck: the milestones for 3.4.0 should be....
[09:15] fer_luck: Integrate AJAX WebUI with the possibility to choose the language in the main screen
[09:15] vishee: Normally we are still working on the AjaxUI
[09:15] CarlosRuiz: yes, fer -> that must be part of stabilizing
[09:15] X0d_of_N0d: so there will be no functionality added between 3.3.0 and 3.4.0 (not stupid, just want to verify)
[09:16] hengsin: fer_luck: I think what is in trunk now is not updated.
[09:16] fer_luck: Allow users to choose language in posterita Pos..
[09:16] ashley_1: Choose language in AjaxUI is easy, but not for posterita pos
[09:16] CarlosRuiz: I suppose we're going to release 3.3.1
[09:16] CarlosRuiz: determine what else are we going to allow entering before 3.4.0
[09:16] CarlosRuiz: and targeting stable 3.4.0
[09:16] X0d_of_N0d: and the current trunk when frozen will become 3.5.0 until stable?
[09:17] vishee: We haven't worked on Internationalisation for Posterita POS
[09:17] vishee: but definitely its on our list of features to integrate that too
[09:17] fer_luck: and as carlos said work in cp3o, costing, dashboard, and RMA
[09:17] fer_luck: vishee: would it be to hard to do that?
[09:17] hengsin: X0d: yep, that's the idea. I don't like that but that is how it means to work now.
[09:17] fer_luck: vishee: how long can it be done, I mean, choose the language for the WebUI?
[09:18] fer_luck: CarlosRuiz: Should we ditch the actual WEBUI?
[09:18] X0d_of_N0d: hengsin: I think it's a good way of doing things, makes things more stable when they're released
[09:18] vishee: Niraj can you reply to fer_luck
[09:18] X0d_of_N0d: It would be nice to fix the existing webui, even if we're workin on an ajax one
[09:18] fer_luck: X0d_of_N0d: we gotta have a stable product, not like the old inc does, add stuff and say it's ready...
[09:18] X0d_of_N0d: because no everyone likes ajax...]
[09:18] Niraj: well..i guess it should take 1 or 2 days
[09:18] fer_luck: X0d_of_N0d: I completely disagree
[09:19] fer_luck: We're making a double effort
[09:19] fer_luck: we gotta stick with one option and make it a good one
[09:19] jsSolutions: fer_luck, absolutely agree
[09:19] X0d_of_N0d: fer_luck: ok, but what about a way to disable some of the ajax stuff?
[09:19] hengsin: yep, if no one is actively using it and more importantly maintaining it, we should drop it.
[09:19] fer_luck: X0d_of_N0d: that's not the point
[09:19] X0d_of_N0d: hengsin: since no one is developing it, it should be dropped...
[09:20] vpj-cd: is better deprecate
[09:20] vpj-cd: and do not drop
[09:20] vpj-cd: other ppl can finis the work
[09:20] fer_luck: the point is, someone says he/she is going to develop something.. someone finds this idea nice, and then goes and develop his onw poc for that, instead of working as a community for the greater good
[09:20] hengsin: victor: no point deprecating beta stuff ...
[09:20] vpj-cd: but need are here to can be look
[09:20] fer_luck: hengsin: agree
[09:21] CarlosRuiz: I would ask to Rob Klein the status of his work
[09:21] fer_luck: then, after something is stabilized, someone should go and say, oh, why not add that..
[09:21] fer_luck: We have too many interfaces already.. one for delphi, one pure html, one with ajax, swing...
[09:21] CarlosRuiz: anyways, what I understand currently is both webUI can coexists (at this moment)
[09:21] hengsin: another way is to archive it, i.e move it to separate project.
[09:21] fer_luck: see, that's at least 3 times the same job...
[09:22] CarlosRuiz: AFAIU (correct me if necessary) is that AJAX webUI from posterita is not disruptive
[09:22] CarlosRuiz: it doesn't require changes in core
[09:22] fer_luck: Niraj, vishee, ashley_1, shameem is that right?
[09:22] croo: t's just a UI what does it matter how many there are? if someone wants to use it they can if not they don't have to
[09:22] vishee: no
[09:22] croo: I see no advantage is simply removing it
[09:23] vishee: croo: Yes
[09:23] ashley_1: yes, AjaxUI is just an extension
[09:23] vpj-cd: is a good practique that beta module can be install via 2pack
[09:23] hengsin: carlos: yes, I spend quite a bit of time with Posterita to achieve that.
[09:23] ashley_1: no core changes
[09:23] CarlosRuiz: and currently Ajax WebUID is using another web context to show that
[09:23] shameem: Posterita POS is simply a plugin
[09:23] vishee: Croo: I meant that it does not disrupt core
[09:23] shameem: No core changes
[09:23] CarlosRuiz: so, I don't see problems currently having both
[09:23] CarlosRuiz: but if Rob Klein is not wanting to maintain current webUI - I think better to drop it
[09:23] fer_luck: CarlosRuiz: Agreed
[09:23] vpj-cd: when new contribution get a good version then we can include
[09:24] fer_luck: let's move on, what's the next feature?
[09:24] hengsin: shameem: I remember there is still an issue with the callout API, is that solve now ?
[09:24] croo: indeed so if it's old or new ... it matters not people can choose to use or work on which ever they wish
[09:24] CarlosRuiz: milestone for 3.4
[09:24] CarlosRuiz: what else we can include in 331, 332 before 340 ?
[09:24] hengsin: Carlos: is your ID management thing ready ?
[09:24] ashley_1: hengsin: I think that's for webui, I think that callout has been solved
[09:25] ashley_1: can you confirm Niraj!
[09:25] CarlosRuiz: Heng Sin, the ID management is working - not tested with big load
[09:25] fer_luck: Well, fixed assets would be nice... as well as your new id management thing.
[09:25] fer_luck: CarlosRuiz: did you do the 2pack import to test it?
[09:25] CarlosRuiz: and as is not a NASA app - I think we can accept the lack of security
[09:25] Niraj: ya..the callout APi is now ok
[09:25] hengsin: fer_luck: we will come to that later ...
[09:26] fer_luck: hengsin: ok. :-D
[09:26] CarlosRuiz: no fer, no 2pack- but I'm pretty sure it will work with 2pack also
[09:26] croo: I've never looked closely into 2pack... but I don't understand the need for this centralised ID? ok I know we use static ID nows but can we just use offset vales for packages ... so it doesn't matter what the ID is?
[09:26] fer_luck: CarlosRuiz: just tell me if I'm wrong, the ID management thing you're talking about is the 2pack export of the entire db?
[09:26] hengsin: Carlos: we can probably announce it on forum and have a two week buffer before freeze.
[09:26] CarlosRuiz: nope
[09:27] fer_luck: Oh, the other one thatI haven't seen
[09:27] CarlosRuiz: ok, let's organize :-)
[09:27] hengsin: I would still like to complete the ad_modelvalidator enhancement if time permit.
[09:28] CarlosRuiz: agree to release a 3.3.1 called XXX
[09:28] CarlosRuiz: agree to look for nightly builds, installers, NX, and AVA - to ease non-technical testers work
[09:28] CarlosRuiz: agree to target a new 3.4.0 - this implies a trunk freeze
[09:28] CarlosRuiz: and agree to include in 3.4.0:
[09:28] CarlosRuiz: here comes the list:
[09:28] hengsin: and maybe some unit testing enhancement - althought that may be not conflict with trunk freeze.
[09:28] vpj-cd: the centralized ID is only the ad change to go trunk
[09:28] CarlosRuiz: AJAX webUI from posterita - if posterita and we agreed here
[09:29] CarlosRuiz: anything else - I mean big things
[09:29] CarlosRuiz: the little things can enter these two weeks of buffer as Heng Sin adviced
[09:30] vishee: yes
[09:30] CarlosRuiz: one question: is there agreement on ajax webUI?
[09:30] CarlosRuiz: I don't like to see Victor saying I have preference with Posterita :-(
[09:30] fer_luck: I agree...
[09:30] croo: big things as in libero? :-)
[09:30] croo: and fixed assets?
[09:31] fer_luck: those are probably going in for 350. :-D
[09:31] croo: I thnk fixed assets is core functionality that every business needs
[09:31] CarlosRuiz: fer -> 4.0
[09:31] vishee: yes agree for Ajax UI
[09:31] hengsin: yep
[09:32] jsSolutions: croo, we're targetting a stable release, so we have a platform for adding libero and FA
[09:32] CarlosRuiz: ok - I think the 2 week buffer after announcing in forums is ok to allow small things to enter
[09:32] CarlosRuiz: also we can see the patches and contributions and small things can enter into trunk before 3.4.0
[09:32] jsSolutions: +1
[09:32] hengsin: +
[09:32] fer_luck: +1
[09:32] hengsin: +1
[09:33] vishee: +1
[09:33] ashley_1: +1
[09:33] *** X0d_of_N1d has joined #adempiere-team.
[09:33] shameem: +1
[09:33] eliercio: +1
[09:33] croo: ok 2 weeks to 3.4 is that right?
[09:33] CarlosRuiz: nope
[09:33] fer_luck: croo: 2 weeks for freeze
[09:33] CarlosRuiz: :-) optimistic
[09:33] CarlosRuiz: neither
[09:33] CarlosRuiz: wait a minute
[09:33] vpj-cd: think we need more time to 3.4
[09:34] croo: ok I saw references to 3.3.1, 3.3.2 etc and thought perhaps this was a 3 month plan :)
[09:34] CarlosRuiz: we need to release a 3.3.1 - when?
[09:34] Niraj: +1
[09:34] CarlosRuiz: then we possibly are going to release a 3.3.2
[09:34] CarlosRuiz: and start the real freeze and bug fixing work targeting 3.4.0
[09:34] jsSolutions: Carlos, I thought you were saying 2 weeks then freeze?
[09:34] CarlosRuiz: exactly
[09:34] vpj-cd: i think is good if we release each 2 week
[09:34] CarlosRuiz: 3.3.1 when?
[09:35] fer_luck: 2 weeks from now..
[09:35] jsSolutions: Nov 1 Freeze trunk except bug fixings
[09:35] CarlosRuiz: I think is important if Sun wants to help with stabilizing work with 3.3.1 or 3.3.2 frozen
[09:35] vpj-cd: and i think need voting to release a version is stable
[09:35] CarlosRuiz: ¿?
[09:36] CarlosRuiz: voting? what are we doing here?
[09:36] X0d_of_N1d: Ok, Nov 1 trunk freeze and release 3.3.2 beta, which then becomes 3.4.0 when stable?
[09:36] CarlosRuiz: so, on nov 1 we release 3.3.1 and freeze?
[09:36] vpj-cd: we need ask the community to say if are stable version
[09:36] vpj-cd: or what is the way to define a stable version?
[09:37] X0d_of_N1d: acutally, I'm leaning toward what vpj-cd is saying
[09:37] croo: well it's stable when all the priority bugs are fixed right? that's what we did for mayday?
[09:37] CarlosRuiz: I understand we're defining this here
[09:37] jsSolutions: croo is right
[09:37] CarlosRuiz: nov 1 -> release 3.3.1b
[09:37] *** X0d_of_N0d has signed off IRC (Remote closed the connection).
[09:37] hengsin: Carlos: I think what victor mean is say when we have version 3.3.5 which we feel is stable to be declare as stable, we can have voting on forum whether that is agreeable by the majority.
[09:37] CarlosRuiz: vishee - can Ajax webUI enter into 3.3.1b or we need another 3.3.2b for webui
[09:38] *** X0d_of_N1d is now known as X0d_of_N0d.
[09:38] vpj-cd: yes this i try say Low thank to clear my point
[09:38] CarlosRuiz: I don't see community voting if a version is stable - that's a work from testers
[09:38] vishee: right now as it is it is based on trunk
[09:38] croo: hengsin & vpj-cd - ok :) but we ask when we have all the priority bugs fixed :)
[09:38] jsSolutions: yeah, we have a standard for stable release already
[09:39] X0d_of_N0d: fixed bugs should be the metric for stability
[09:39] vpj-cd: ok only ask if the community is agree with stable version
[09:39] CarlosRuiz: yes, we need first a triage of sf trackers
[09:39] CarlosRuiz: I don't understand the point Victor
[09:39] CarlosRuiz: asking to community if they want a stable?
[09:39] vpj-cd: some ppl can say you version stable have this big issue
[09:40] CarlosRuiz: the current procedure is:
[09:40] CarlosRuiz: - triage
[09:40] CarlosRuiz: - fix
[09:40] CarlosRuiz: - when no critical bugs in core - we call it stable
[09:40] vpj-cd: we can go to 3.3.7 and we set as stable version
[09:40] CarlosRuiz: that's what we defined in mayday (and worked with little problems)
[09:41] croo: yes if someone thinks here is an issue they log a bug report and raise priority!
[09:41] X0d_of_N0d: shouldn't we just continue to have minor releases until all the bugs are fixed, then call it stable after the last minor fix has gone for aweek or so without a bug?
[09:41] croo: then it's not stable and no releasd!
[09:41] jsSolutions: the targets are to motivate us
[09:41] croo: X0d_of_N0d: we never have ALL he bugs fixed
[09:42] jsSolutions: bugs sit and sit until we have a release date
[09:42] vpj-cd: agreed the via is bug report
[09:42] CarlosRuiz: with mayday we were a little lazy in some cases and allowed to enter some minor enhancements after freeze - this is not a straightjacket
[09:43] CarlosRuiz: but every new inclusion is reviewed and voted between developers
[09:43] croo: yes and it was a good policy I think
[09:43] jsSolutions: now we have a big opportunity. if we insist on all priority bugs fixed before taking on libero, then all those +1's can get into action!
[09:43] CarlosRuiz: yes
[09:43] CarlosRuiz: hopefully
[09:43] vpj-cd: but I think is good practice go to 331,332, 333, 334, 335 the necessary and
[09:43] vpj-cd: release stable
[09:43] CarlosRuiz: yep Victor, if we get the resources to release that's not a problem
[09:44] jsSolutions: carlos, do we need to release Nov 1?
[09:44] CarlosRuiz: why?
[09:44] fer_luck: Niraj: The trunk version for AjaxUI is the latest one?
[09:44] Niraj: no
[09:44] jsSolutions: aren't there extra steps to release that are not necessary for trunk freeze?
[09:44] hengsin: Joel: I think is good to have a date now
[09:44] Niraj: some changes have been brought to the ajaxUI
[09:45] jsSolutions: hengsin, not questioning the date, just saying we could freeze without release
[09:45] Niraj: we are adding new features
[09:45] croo: jsSolutions, good to release so as many can join testing for stable
[09:45] jsSolutions: ok
[09:45] fer_luck: Niraj: when can you upload the latest version to the contrib directory?
[09:45] Niraj: and improving the performance
[09:45] vpj-cd: now what should are the average intervals in time between vestions
[09:45] CarlosRuiz: agree, the freeze is not related with the release Joel
[09:46] X0d_of_N0d: croo: what level of severity should we focus on then?
[09:46] X0d_of_N0d: I mean, anything that has a priority 9 bug open shouldn't be stable, right?
[09:46] X0d_of_N0d: the priority should be dropped if it's not really that high priority, or it should be fixed...
[09:46] hengsin: Niraj: just curious, any reason why it is not sync ? or your guy is just too busy ?
[09:46] CarlosRuiz: 7 and 9 are real problems
[09:46] CarlosRuiz: 3 - have workarounds
[09:46] croo: I think (carlos can remind me) we said 7 & 9 were priority issues
[09:46] CarlosRuiz: 1 - minor - presentation, etc
[09:46] CarlosRuiz: 7 is for security
[09:46] Niraj: in fact..we are actually having some performance probs
[09:46] vishee: normally we have been busy with Posterita POS
[09:46] CarlosRuiz: 9 is for critical - data corruption - broken
[09:46] Niraj: which are related to ZK
[09:47] fer_luck: the date for the freeze should be november 1st.. the date for release of 331 should be like 13th of november
[09:47] fer_luck: :-
[09:47] croo: I think 7 was securuity & performance
[09:47] X0d_of_N0d: so all priority 9 should be fixed before the release
[09:47] X0d_of_N0d: what about 8?
[09:47] croo: 7 & 9
[09:47] CarlosRuiz: there is no 8
[09:47] CarlosRuiz: there is another variable
[09:47] CarlosRuiz: the grouop
[09:47] CarlosRuiz: the group -> Core
[09:47] hengsin: we don't like 8 :)
[09:48] croo: we just used 1,3, 7 & 9 ... 5 is an report that has not been evaluatd
[09:48] CarlosRuiz: all priority 9 affecting Core must be fixed to call this stable
[09:48] X0d_of_N0d: erm.....
[09:48] CarlosRuiz: we can have priority 9 for a beta module - that's no problem
[09:48] X0d_of_N0d: priority 8?
[09:48] fer_luck: that's odd.. :-D
[09:48] croo: fer_luck, he he :)
[09:48] fer_luck: I never knew why just use odd numbers.. :-D
[09:49] croo: we are an odd project :)
[09:49] X0d_of_N0d: (Link: http://sourceforge.net/tracker/index.php?func=detail&aid=1737858&group_id=176962&atid=879332)http://sourceforge.net/tracker/index.php?func=detail&aid=1737858&group_id=176962&atid=879332
[09:49] X0d_of_N0d: ?
[09:49] hengsin: shall we clean up the category thing in the tracker ? anyone can help on that ?
[09:49] CarlosRuiz: :-) one wrong 8
[09:49] X0d_of_N0d: 3 8s
[09:49] CarlosRuiz: no, categories can't be deleted
[09:49] X0d_of_N0d: erm... 4
[09:49] CarlosRuiz: well - another big task triage
[09:49] croo: hengsin, I don't think categories can be deleted ... which maks maintenance difficult :(
[09:50] hengsin: ok, nvm, I've give up on that.
[09:50] croo: X0d_of_N0d, that's just people assigning their own priorities
[09:50] CarlosRuiz: are we going to make a triage again like we did in mayday - distributed between volunteers
[09:50] X0d_of_N0d: shouldn't category be used for organization and priority refer to severity of the issue?
[09:50] hyksos: is there a wiki-page were these priorities are noted?
[09:51] X0d_of_N0d: this organization method seems nonstandard....
[09:51] CarlosRuiz: not sure, it will be good to clarify the procedure, then ask for volunteers for the triage
[09:51] croo: X0d_of_N0d, yes that's what is should be
[09:51] X0d_of_N0d: why are we not doing things that way?
[09:51] CarlosRuiz: what's the standard? suggestions for improvement?
[09:52] X0d_of_N0d: it seems that it would make things easier for people trying to submit bugs
[09:52] croo: X0d_of_N0d, I thnk we are?
[09:52] hyksos: that would be point 7
[09:52] X0d_of_N0d: people who don't know our special method
[09:52] croo: maybe .. I think it's in he wiki though
[09:52] CarlosRuiz: yep, people submit bugs with priority 5 as default - they don't do the triage
[09:53] jsSolutions: +1 for triage
[09:53] vpj-cd: i think is necessary this info is visible in wiki
[09:53] vpj-cd: in main page
[09:53] croo: triage means evaluation?
[09:53] hengsin: +1 for regular triage of bug
[09:53] X0d_of_N0d: croo: yes
[09:53] croo: ok sorting, qualify ... got it :)
[09:53] CarlosRuiz: again -> volunteers?
[09:53] jsSolutions: i can help with triage
[09:54] croo: I will help
[09:54] hengsin: hmm ... Teo not around ...
[09:54] vpj-cd: what task Carlos?
[09:54] X0d_of_N0d: ok, but what about the category vs priority thing?
[09:54] CarlosRuiz: triage Victor
[09:55] hengsin: the category is mess up beyong repair, lets forget that ...
[09:55] X0d_of_N0d: I think that needs to be determined before triage is possible
[09:55] CarlosRuiz: I mean the group
[09:55] X0d_of_N0d: ?
[09:55] croo: priority is the only important bit ... unless a category is a beta functionality
[09:55] CarlosRuiz: no the category
[09:55] croo: as hengsin says ... the categories are pretty much useless
[09:55] CarlosRuiz: group is: Beta - Core - Module specific - Report
[09:56] CarlosRuiz: the triage must set the priority (1,3,7,9) and the group (Core, Beta, Module, Report)
[09:56] croo: group is ok right? just info on what version it was found .. I guess we could update that as we triage
[09:56] CarlosRuiz: 1 - minor
[09:56] CarlosRuiz: 3 - problem with workaround
[09:56] CarlosRuiz: 7 - security
[09:56] CarlosRuiz: 9 - critical, data corruption, stoppage
[09:57] croo: was 7 not updatedto include performance?
[09:57] X0d_of_N0d: why not make 8 performance
[09:57] CarlosRuiz: don't remember Colin
[09:57] CarlosRuiz: if you want we can put a target date for 3.4.0 - but mostly is dead letter - is just a desire
[09:57] CarlosRuiz: IMHO performance can be 9 or 3
[09:58] X0d_of_N0d: wait... priority should be for severity of the issue
[09:58] jsSolutions: 3.4.0 Nov 19
[09:58] X0d_of_N0d: This is really confusing to anyone not well versed in this method
[09:58] croo: ok I thought we talked about that after the initial priorities I will check
[09:58] fer_luck: 340 nov 13 and name it fer_luck.. it's my bday
[09:58] fer_luck: haha
[09:58] CarlosRuiz: mayday bug fixing was > 2 months
[09:58] X0d_of_N0d: that drives away testers and makes maintence of the bug tracking system more difficult
[09:59] croo: it took two months because nobody fixed ... only the community canhelp that !?
[10:00] hengsin: X0d: yes, we are using priority for the severity of the issue
[10:00] croo: X0d_of_N0d, what is confusing ... we have 4 types of bugs a bug that corrupts data
[10:01] CarlosRuiz: testers don't need to know about triage
[10:01] croo: a bug that is a security issue, a bug that causes corruption but there is a way of using the app so it doesn't occur
[10:01] hengsin: realistically, this will take 1 to 3 month.
[10:01] croo: and a UI isue
[10:01] X0d_of_N0d: ok, but you can have a security issue where a user can change one field in the ui, which is maybe low priority...
[10:01] CarlosRuiz: I suppose with good testers the numbers of bugs will tend to raise - in mayday we had very few testers
[10:01] X0d_of_N0d: and a security issue where a user can wipe out the entire database with some arbitrary string
[10:02] X0d_of_N0d: one should be priority 9, one should be priotiry 2 or 1...
[10:02] CarlosRuiz: security is a big problem, always considered important
[10:02] CarlosRuiz: although nobody wants to fix :-)
[10:02] hengsin: X0d: yes, 1 for low priority, what's the problem ?
[10:02] X0d_of_N0d: hengsin: croo just said that wasn't the way things are organized..;
[10:02] X0d_of_N0d: that's what's confusing about this thing
[10:03] X0d_of_N0d: I have to do something, I'll be back in a bit
[10:03] croo: X0d_of_N0d, wipe of the DB is data corruptions ... but there are always exception we just wanted something straight forward
[10:03] croo: X0d_of_N0d, no I didn't!!!
[10:03] croo: well I didn't mean too!
[10:03] X0d_of_N0d: croo: I must have misunderstood you
[10:03] hengsin: Security Team no here ... ok ... they like to work in the shadow ... :)
[10:04] X0d_of_N0d: ok, so major problems of all type, no matter what they are, are designated a priorty
[10:04] X0d_of_N0d: what about the categories?
[10:05] X0d_of_N0d: 7 - security
[10:05] X0d_of_N0d: ?
[10:05] fer_luck: Carlos, what's next?
[10:05] vpj-cd: yes canwe continue with agenda?
[10:05] jsSolutions: pick a date for 3.4
[10:05] X0d_of_N0d: I'll just reread this later...
[10:06] hyksos: jsSolutions :why
[10:06] vpj-cd: Joel I think to 3.4 is whe the bug are solve
[10:06] vpj-cd: then i think is complex set date
[10:06] CarlosRuiz: but we can have a target date - as the desire
[10:06] fer_luck: CarlosRuiz: just state 25th of december to the 3.4 release.. and all is fine..
[10:06] jsSolutions: yes, without a date, nothing will happen
[10:06] CarlosRuiz: christmas gift
[10:06] fer_luck: rite
[10:07] hengsin: ok, christmas gift then
[10:07] hengsin: so here we go, ADempiere 3.4, Christmas Edition
[10:07] vpj-cd: yes 3.4 is good to december
[10:07] CarlosRuiz: although I'm almost sure that it needs 2-3 months
[10:07] hyksos: without date nothing will happen, does the developers dont solve the bugs if there is no date?
[10:08] jsSolutions: that's the way devs are :)
[10:08] fer_luck: Ok then.. We have a christmas gift to community already
[10:08] hyksos: not all
[10:08] CarlosRuiz: I think we can call 3.4 Posterita - because of the POS and Ajax webUI
[10:08] jsSolutions: i have two problems with this...
[10:08] fer_luck: oh my
[10:08] jsSolutions: 1. can't tell Sun not to start until January
[10:09] jsSolutions: so the goal of stable release for sun is not met
[10:09] CarlosRuiz: Joel, Sun can work together with us with 3.3.1
[10:09] jsSolutions: 2. also no libero until Jan
[10:09] CarlosRuiz: nov - 1
[10:09] MCalderon: yes
[10:09] CarlosRuiz: I repeat Jan is a very optimistic date
[10:10] CarlosRuiz: mayday showed us that
[10:10] hengsin: Is Posterita a company name ? I would prefer to not name any of our release with a company name since it is always the cumulative work of many
[10:10] fer_luck: hengsin: agree with you
[10:10] MCalderon: jsSolutions: can sun be involved in 3.4?
[10:10] emontenegro: If I may, I would suggest postponing 1 week, to Jan. 1st, just to choose a worldwide non religion related holiday .....
[10:10] CarlosRuiz: yes, but I think we must show the names of TOP CONTRIBUTORS
[10:11] jsSolutions: my request for stable was not so big as that... just finish up the Priority 9's and turn over a stable
[10:11] croo: i think we can better decide a target date when we have done the triage
[10:11] CarlosRuiz: for 4.0 we can call it Adempiere Libero - or Adempiere e-evolution
[10:11] vpj-cd: i also agree with low
[10:11] hyksos: i think sun is fixing bugs and enhance code, so why should they not work now with ADempiere?
[10:11] jsSolutions: I don't think Sun plans to put their team on bug fixes
[10:11] jsSolutions: they are working at server level
[10:12] jsSolutions: JBoss
[10:12] jsSolutions: replaced with generic j2ee
[10:12] jsSolutions: also performance tuning
[10:12] fer_luck: ok, release 3.3.1 and let them work on the performance tuning and j2ee server witht that.. we can even release 331 nov. 1st..
[10:12] jsSolutions: they don't care about whether IsSoTRX is set right
[10:12] hyksos: whats server level? coulnt i install it on my i383 then?
[10:13] CarlosRuiz: yes, I think Sun can work with 3.3.1 nov-1
[10:13] vpj-cd: Carlos the will be issue with some branding
[10:13] jsSolutions: fer_luck, that's probably what we have to do
[10:13] fer_luck: For me that's ok...
[10:13] CarlosRuiz: Agenda
[10:13] CarlosRuiz: 2. Bug DayÂ
[10:13] CarlosRuiz: 3. 3.4 Release TargetÂ
[10:13] jsSolutions: well, they might be worse off with 3.3.1 than 3.3.0
[10:13] fer_luck: We could use lord of the rings names on the releases, if names are lacking.. or get int contact with mark shuttleworth to come up with some weird names for us
[10:13] fer_luck: :-D
[10:13] fer_luck: hehe
[10:14] jsSolutions: because we are rusing to sitck a bunch of stuff in before a freeze
[10:14] jsSolutions: rusing=rushing
[10:14] jsSolutions: better that we freeze right now, fix priority 9's then give them something Nov 1
[10:15] croo: jsSolutions, if they plan to make the app j2ee compliant they are in for a shock and 3.30 or 3.3.1 will be the least f their problems :)
[10:15] CarlosRuiz: ok, for the name I would prefer to hear Redhuan opinion and more council opinions
[10:15] CarlosRuiz: I think names are a strategical + tactical thing
[10:15] fer_luck: croo: good one
[10:15] jsSolutions: croo, i agree
[10:15] jsSolutions: that part of the issue came because Carlos warned not to use 3.3.0
[10:15] CarlosRuiz: but sure I think we can invite Sun to work in our trunk
[10:16] jsSolutions: so we said, can we get something more stable
[10:16] fer_luck: they could do the nasty work and port everything to jpa or hibernate for us
[10:16] fer_luck: :-D
[10:16] CarlosRuiz: my worry is this
[10:16] CarlosRuiz: if they stabilize 3.3.0 and certify it to run in Sun machines
[10:16] vpj-cd: yes i think is good idea of carlos
[10:16] CarlosRuiz: the certification is that it run
[10:16] CarlosRuiz: but 3.3.0 and 3.3.1 are unstable
[10:16] vpj-cd: I tested adempiere in glasfish
[10:17] vpj-cd: and this work without issue
[10:17] CarlosRuiz: so, I think we could join to look for 3.4.0 certified and stable
[10:17] croo: once we review the bugs status perhaps we can say 3.2 is not far ... so a Nov1 freeze is 3.1 and with immediate top bugs done is 3.2 and they can use that ... I say wait until we look at where we stand
[10:17] vpj-cd: yes i agree with carlos
[10:17] vpj-cd: we can create a tracker as posterita or libero
[10:18] vpj-cd: to have control the sun certified
[10:18] vpj-cd: I think sun need work with the trunk
[10:18] vpj-cd: and we can release adempiere with glass fish configuration
[10:19] vpj-cd: do only with jboss
[10:19] CarlosRuiz: that's something we need to talk with Sun
[10:19] CarlosRuiz: they can work in trunk - ideally
[10:19] CarlosRuiz: or we can set up a branch for them
[10:19] CarlosRuiz: or they can work in private repository - but then how to integrate?
[10:20] croo: they probably have their own policy ... so we most probably
[10:20] croo: cant decide here
[10:20] CarlosRuiz: anyways - since 3.3.0 the jboss and db configuration has changed - that's why I think we need to work with a newer version
[10:20] jsSolutions: how about... Nov 1-3.1; Nov 19-3.2; Jan 1-3.4
[10:20] hengsin: Joel: what would the scope of their work ? Just performance testing and make it run on glassfish ?
[10:21] CarlosRuiz: they said they're going to make j2ee app server agnostic
[10:21] croo: I did application performance testing as they plan with AT&T once and it took months to set up the scripts!
[10:21] CarlosRuiz: :-) is agnostic the right word :-D
[10:21] hengsin: haha ... they will always say that - j2ee app server agnostic
[10:21] vpj-cd: yes but sun to go with glassfish it is sure
[10:21] hengsin: in reality, they will just test it on glass fish
[10:22] vpj-cd: yes
[10:22] CarlosRuiz: but as Colin pointed, we can't decide that - what I think is we need to offer them better options
[10:22] jsSolutions: this is really all I know about scope
[10:22] jsSolutions: (Link: https://sourceforge.net/forum/message.php?msg_id=4567705)https://sourceforge.net/forum/message.php?msg_id=4567705
[10:22] vpj-cd: I think not they never test with heronimo
[10:22] vpj-cd: :-)
[10:22] hengsin: I suppose we need to have a meeting with the sun team then
[10:23] fer_luck: hengsin: that will solve this issue
[10:23] CarlosRuiz: ok - 3.4.0 target date - as a wish - dec-25 (I really doubt it, but ok, we need a target date)
[10:23] *** svanga has signed off IRC ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]").
[10:23] fer_luck: then just put another month over it.. no problems Carlos
[10:23] CarlosRuiz: dec-25 is feasible if all those who vote in forums help testing and bug fixing :-D
[10:23] croo: who will be around to release on christmas day?
[10:24] fer_luck: I'd prefer having 3.4 freezed by dec-25
[10:24] hengsin: Joel: 1-4 is clear, 5 will need more info from them. anyway, a meeting is needed.
[10:24] croo: maybe we could ask santa? as in santa claus that ais
[10:25] vpj-cd: the dec - 25 is a good forcast
[10:25] vpj-cd: forecast
[10:25] fer_luck: ok then.. the date is dec. 25 for 3.4 stable...
[10:25] CarlosRuiz: really, don't blame the contributors for not achieving dates - please blame all those who don't contribute :-D
[10:25] *** xp_prg has joined #adempiere-team.
[10:25] xp_prg: hi all! :>
[10:26] hengsin: hi Tim
[10:26] CarlosRuiz: ok, for Bug Day
[10:26] jsSolutions: yes, it's ok. just a tool to organize and coordinate
[10:26] fer_luck: and we release weekly the in between versions (3.3.1, ...)
[10:26] fer_luck: Carlos, just one more thing
[10:26] CarlosRuiz: I suppose is easy - after the trunk freeze Heng Sin can call for it
[10:26] fer_luck: we freeze trunk next Wednesday
[10:27] jsSolutions: Carlos, yes
[10:27] CarlosRuiz: no, on nov-1
[10:27] croo: ok
[10:27] fer_luck: good.. let's vote or no need?
[10:27] CarlosRuiz: ok, so we have the first three points on the agenda solved:
[10:27] CarlosRuiz: 1. Trunk FreezeÂ
[10:27] CarlosRuiz: 2. Bug DayÂ
[10:27] CarlosRuiz: 3. 3.4 Release TargetÂ
[10:28] fer_luck: not the bug day..
[10:28] fer_luck: Or is the bug day solved
[10:28] fer_luck: ?
[10:28] vpj-cd: yes the rigth is bug day solve
[10:28] CarlosRuiz: I propose the bug day must be called by Heng Sin after the trunk freeze
[10:28] CarlosRuiz: excuse me - not must - if Heng Sin agrees
[10:28] fer_luck: Oh.. ok..
[10:28] fer_luck: good..
[10:29] hengsin: well, can we have that as a regular event ?
[10:29] CarlosRuiz: yep, it will be great
[10:29] hengsin: maybe twice or once a month ?
[10:29] fer_luck: it's nice..
[10:29] *** b0b has joined #adempiere-team.
[10:29] fer_luck: once a month
[10:29] fer_luck: to solve 9 bugs
[10:29] CarlosRuiz: we'll learn from the first one
[10:30] CarlosRuiz: ok - then next points in the agenda:
[10:30] CarlosRuiz: 4. Libero Manufacturing IntegrationÂ
[10:30] CarlosRuiz: 5. Possible move of Fixed Assets and AjaxUI to trunk- should these be tackled simultaneous to Libero, or after?Â
[10:30] CarlosRuiz: 6. 4.1 Release TargetÂ
[10:30] fer_luck: 4 - Libero is one of my top priorities after we stabilize adempierelbr
[10:31] xp_prg: me too fer_luck :)
[10:31] hengsin: guys, lets put up some proposal here
[10:31] CarlosRuiz: AFAIU there are two waves proposed here
[10:31] CarlosRuiz: 1 - integrate directly into trunk
[10:31] CarlosRuiz: 2 - make adempiere more pluggable and keep libero as a package
[10:32] CarlosRuiz: the 2nd is looking adempiere as a kernel
[10:32] fer_luck: I guess it's no. 1
[10:32] vpj-cd: Carlos the issue with 2
[10:32] vpj-cd: is the sequences
[10:32] CarlosRuiz: the "distributions" must decide what is packaged or not
[10:32] fer_luck: a true erp must has a mfg module
[10:33] fer_luck: As a package, it will only make it harder for mfg companies to test it..
[10:33] xp_prg: I am new to this team meeting stuff so I hope I am not talking out of turn, with regards to libero I am writing functional tests and I am having extreme difficulty getting a process to run outside of Adempiere, can anyone assist? (Link: http://adempiere.svn.sourceforge.net/viewvc/adempiere/branches/libero/extend/src/test/functional/)http://adempiere.svn.sourceforge.net/viewvc/adempiere/branches/libero/extend/src/test/functional/ this would contribute greatly to libero's stability etc...
[10:33] fer_luck: and maintenance just gets harder to do
[10:33] CarlosRuiz: I suppose we must analyze the benefit/cost of each proposal
[10:34] xp_prg: in my humble opinion writing functional and unit tests will greatly soothe the concerns of stability and integration into trunk yes?
[10:34] CarlosRuiz: what I see is majority is wanting the 1st
[10:34] CarlosRuiz: and Heng Sin and me are proposing the 2nd
[10:34] jsSolutions: hi tim, most important is stay on topic, in this case, should libero be trunk or package :)
[10:34] xp_prg: oh ok :>
[10:34] CarlosRuiz: are there anybody else with the 2nd (here - I see in forums there are people with the 2nd)
[10:35] xp_prg: I am here to assist in any way I can to help put Libero into the trunk and 100% commit to wanting that to occur :>
[10:35] hengsin: that is sam, don't think he is here.
[10:35] vpj-cd: Joel set the code in the trunk do not is issue
[10:35] vpj-cd: ii is easy
[10:35] CarlosRuiz: well - let me put some example
[10:35] vpj-cd: the issue is with Application dictionary
[10:35] CarlosRuiz: Linux has KDE and GNOME - they could say that a real op sys must have a desktop
[10:35] CarlosRuiz: and include one of those in the kernel
[10:35] CarlosRuiz: or they can become pluggable
[10:36] CarlosRuiz: and allow any desktop following certain standards
[10:36] CarlosRuiz: to integrate with the kernel
[10:36] CarlosRuiz: that doesn't imply that linux don't have desktop
[10:36] CarlosRuiz: or that linux don't allow contributions
[10:36] vpj-cd: Carlos but the pluggable no is viable
[10:36] CarlosRuiz: is just another way to architect the thing
[10:36] hyksos: in kernel only drivers are located, nothing with desktops
[10:36] vpj-cd: because we have great issue with sequences
[10:36] CarlosRuiz: what do we need to make adempiere pluggable
[10:37] vpj-cd: let give a example i siad to red1
[10:37] CarlosRuiz: do we need to push the Victor's proposal (ID's for extensions) to make it pluggable?
[10:37] vpj-cd: sai
[10:37] croo: yeah but we don't have a kernel! I have lots of experience with compiere & adempiere and I have hardly managed to get FA or libero installed ... I don't need it so I don't spend tim eon it but if it wa there I woudl review
[10:37] hengsin: maintenance of trunk is easier if it is smaller. I mean a big hair ball is no easy beast to maintain and improve
[10:37] jsSolutions: I am 100000% behind pluggable
[10:37] croo: and its not like there is another Mfg module hanging about
[10:37] vpj-cd: this is the swample
[10:37] vpj-cd: sample a user want test libero or FA
[10:38] vpj-cd: then he install via 2pack
[10:38] jsSolutions: but in the meantime, there are good reasons to have libero in the trunk
[10:38] vpj-cd: now he have take a desition
[10:38] jsSolutions: the current production is not appropriate for anybody
[10:38] CarlosRuiz: look, I'm not against libero (and I think neither Heng Sin) - we're trying to look what's the best way to have libero in adempiere
[10:38] vpj-cd: import with system sequences
[10:38] vpj-cd: or user sequences
[10:38] CarlosRuiz: if we don't have a kernel
[10:38] vpj-cd: he import with user sequences is more logic
[10:38] CarlosRuiz: what can we do to have a kernel?
[10:39] vpj-cd: next the take desition to go in production with libero
[10:39] croo: to hav a kernel ... start again
[10:39] vpj-cd: Tim or me release a script migration to fixed a ad bug
[10:39] vpj-cd: we have a issue great issue
[10:39] CarlosRuiz: I think the ideal is to have a kernel - and allow EASY (not currently) integration of add-ons
[10:40] vpj-cd: it fixed only work to me
[10:40] vpj-cd: because each user have you our sequences
[10:40] CarlosRuiz: because Adempiere is not pluggable doesn't mean that we need to integrate everything in the trunk - we need to make it more pluggable
[10:40] jsSolutions: i agree with Carlos, but we shouldnt hold libero in the short term
[10:41] CarlosRuiz: so, if the way is the Victor's proposal of having assigned static sequences for add-ons - then we must find how to make it
[10:41] vpj-cd: then the migration version to pluggable is complex
[10:41] fer_luck: Ok.. let's state something.. one of the primary goals of adempiere was to have libero and FA...
[10:41] fer_luck: We're acting like the Inc., because we have none of them yet...
[10:41] CarlosRuiz: no
[10:41] CarlosRuiz: fer
[10:41] CarlosRuiz: please don't compare
[10:41] CarlosRuiz: the Inc don't allow contributions
[10:41] CarlosRuiz: we're here discussing what's the best way to allow contributions
[10:41] CarlosRuiz: to EASE contributions
[10:42] CarlosRuiz: there's not only one solution for this problem
[10:42] xp_prg: what is confusing me is, I thought the strategy was to have a contribution start out as a package, then as it matures, put it in the trunk, is that not true?
[10:42] vpj-cd: if user that install libero and used the user sequences and are in production
[10:42] jsSolutions: not necessarily tim
[10:42] CarlosRuiz: it depends Tim - like GNOME/KDE
[10:42] jsSolutions: is better strategy for packages to work easily
[10:42] fer_luck: CarlosRuiz: Not allowing libero to go into trunk looks like that sometimes for me.. I'm sorry, but that's how I feel when I see this...
[10:42] vpj-cd: he have a great issue to support migrations
[10:43] CarlosRuiz: yes Fer - you're missing the point - we're not stopping libero
[10:43] jsSolutions: we're really confusing three issues here!
[10:43] CarlosRuiz: we're looking the best way to get it integrated
[10:43] jsSolutions: 1. libero integration
[10:43] jsSolutions: 2. sequence #s
[10:43] jsSolutions: 3. plugable architecture
[10:44] vpj-cd: if we integrate in AD the sequences are assign
[10:44] fer_luck: I see, but I think that if Libero is not going into trunk, we'll have a lot of work from victor and tim in fixing it to be able to work with each and every single release of adempiere...
[10:44] fer_luck: it might happen...
[10:44] vpj-cd: and this let the user to migrate
[10:44] xp_prg: fer_luck I agree with you, it has been quite alot of work at least for me to figure out how to make it work with every release
[10:44] vpj-cd: libero as pluings the user have not future to migration
[10:44] emontenegro: IMHO, just to stay "on topic" I do believe an ERP solution should have a set of functionalities like the ones provided by Libero as part of its core ....
[10:44] CarlosRuiz: fer - that's what we need to solve
[10:44] *** shameem has left #adempiere-team.
[10:45] jsSolutions: emontenegro, agreed
[10:45] xp_prg: emontenegro, I agree mrp is core erp functionality
[10:45] fer_luck: emontenegro: completely agree with you!
[10:45] croo: vpj-cd, yes this is the issue ... who knows what will happen in the future .. at least when it's in the truk people will believe in it!
[10:45] CarlosRuiz: I'm thinking if we simply surrender to the job - and go for the easy path - integrate everything that we can't make as a package
[10:45] CarlosRuiz: or improve adempiere to allow packaging
[10:45] croo: emontenegro, I agree too ... I think it's a basic if you want ERP in your name
[10:46] xp_prg: I think improving the packaging is a longer process to get libero in then putting in the trunk, would anyone else agree with that?
[10:46] fer_luck: We should improve adempiere to allow packaging carlos, but we should also have a core set of funcitonalities
[10:46] emontenegro: This is my 1st meeting and I do have some experience with MRP (used to work with SAP) and I am available to help integrate Libero into the "Core"
[10:46] CarlosRuiz: it's a need to have a desktop to call linux an op sys - but GNOME and KDE are packages
[10:46] CarlosRuiz: nobody discuss that linux is not an op sys
[10:46] croo: xp_prg, yes I do ...
[10:46] fer_luck: and that, for me at least, includes mrp.. not everyone needs a pos for example, and we already have 2 into the core
[10:46] CarlosRuiz: because desktops are packages
[10:46] jsSolutions: Carlos, you are thinking right strategically.
[10:46] hengsin: we are in the danger of keep adding stuff to the application but not improving the core.
[10:46] croo: it's still an OpSys without a desktop!?
[10:47] jsSolutions: but better manufacturing is a core need for an erp
[10:47] xp_prg: I agree with jsSolutions
[10:47] hyksos: only windows users say that linux is a op sys with desktop
[10:47] vpj-cd: Carlos gnome and kde is only code
[10:47] vpj-cd: with libero and FA the issue is AD
[10:47] vpj-cd: no the code
[10:47] CarlosRuiz: again - what do we need to solve?
[10:47] fer_luck: how to include libero into trunk or pluggable module? I vote for trunk...
[10:48] vpj-cd: how the user that install libero , FA via 2pack
[10:48] croo: we don't have a plugable architecture so we want to put core functionality in the trunk
[10:48] croo: that's the issue as I see it
[10:48] xp_prg: well I think we need to decide if we want to go through all the work to improve packaging good enough to keep libero as a package, or just put Libero into the trunk and work on packaging to someday maybe use that appraoch
[10:48] jsSolutions: if we bring libero and FA to the core, are there any other signifcant ERP modules missing?
[10:48] vpj-cd: the can migrate the future migration
[10:48] jsSolutions: tim, that's my vote
[10:48] vpj-cd: we can not create script migration
[10:49] CarlosRuiz: as Joel said, I'm trying to think strategically
[10:49] fer_luck: jsSolutions: BI? :-D
[10:49] CarlosRuiz: if we surrender now - we loose a big opportunity to improve adempiere as pluggable architecture
[10:49] hengsin: ok, just to be safe, maybe we should create a branch to test the integration first ?
[10:49] jsSolutions: BI is usually 'on top of' like a plug-in
[10:49] CarlosRuiz: 2pack evolved thanks to Libero
[10:49] CarlosRuiz: nothing else
[10:49] vpj-cd: Many will have trouble maintaining the issue is the migration
[10:50] CarlosRuiz: without Libero 2pack would be nothing
[10:50] xp_prg: CarlosRuiz, true, but it will continue to evolve even without libero :>
[10:50] vpj-cd: and synchronize with AD
[10:50] vpj-cd: and migration script
[10:50] jsSolutions: this is just personal Carlos, but pluggable is critical to idalica business model...
[10:50] jsSolutions: we won't drop it
[10:50] emontenegro: I believe that what we have in our hands now is Libero and FA and in my opinion these will greatly enhance ADempiere...
[10:51] fer_luck: Ok.. I believe that for the integration of libero and fa, we should do it in the core.. and then we can improve 2pack or whatever
[10:51] vpj-cd: yes but the sequences is a issue of adempiere
[10:51] vpj-cd: no is the 2pack and libero or FA
[10:51] jsSolutions: my priorities would be: stable release, libero, pluggable architecture
[10:52] CarlosRuiz: well, I think my point is enoughly clarified (I hope)
[10:52] CarlosRuiz: now that you know my point
[10:52] CarlosRuiz: if finally we need manufacturing and fa in trunk
[10:52] CarlosRuiz: then let me ask 2 questions:
[10:52] xp_prg: I agree with jsSolutions
[10:52] vpj-cd: Joel the issue we can real solution pluggable architecture when solve the issue with sequences
[10:52] CarlosRuiz: 1 - how are we going to improve adempiere as pluggable?
[10:52] CarlosRuiz: tomorrow people will ask us to integrate subscription module because it can't be integrated as a package
[10:52] emontenegro: I agree with Joel ....
[10:53] vpj-cd: I have some questiones
[10:53] CarlosRuiz: 2 - what conditions must accomplish a new module to get his way into trunk (functional, technical, tactical)
[10:53] vpj-cd: we release libero as 2pack via
[10:53] hengsin: victor: that is not the issue
[10:53] vpj-cd: what is the way to migrate new version
[10:53] vpj-cd: what is the may to mad script migration
[10:54] fer_luck: CarlosRuiz: I guess that with libero and fa we finish the base core for an ERP.. so then we can talk about a pluggable modules
[10:54] vpj-cd: how i apply a patch in dictionary if each user have different sequence
[10:54] croo: I think 2pack is roberts has been an attempt to make it pluggable given the restrictions that he could not change the core ... now we can I believe a truely config arch will require changes the core itself
[10:54] vpj-cd: in you environment
[10:54] hengsin: victor: lets look at that later since we don't need it now :)
[10:54] fer_luck: what's the problem of including libero and fa on trunk right now and then later making the architecture pluggable?
[10:54] vpj-cd: yes i need
[10:54] CarlosRuiz: fer - 2pack would be nothing without libero
[10:54] vpj-cd: because my customer or the end user
[10:55] CarlosRuiz: Victor - we can assign static sequences for EE
[10:55] vpj-cd: need have the warranties they can migrate to future version
[10:55] fer_luck: I mean, even kontro has given up on tang... now he wants to do a completely rewrite..
[10:56] hengsin: victor: isn't that obvious, don't depends on sequence, use business key like value or name
[10:56] vpj-cd: if some customer or end user use libero in production
[10:56] vpj-cd: what is your warranties to the migration
[10:57] CarlosRuiz: Fer, I have strong doubts that adempiere evolve without a real need
[10:57] MCalderon: I understand including Libero has technical reasons?
[10:57] vpj-cd: again what is the way i can apply a migration script
[10:57] CarlosRuiz: that can be solved also Mario
[10:57] vpj-cd: what is way to apply the migration script
[10:57] jsSolutions: Mario, they are not too bad. solvable
[10:57] CarlosRuiz: I suppose is a similar effort to make adempiere pluggable, than including libero into trunk
[10:57] MCalderon: we should talk first tactically then technically
[10:58] CarlosRuiz: look what we had in adempiere 310
[10:58] CarlosRuiz: nothing
[10:58] vpj-cd: yes Mario to me libero is strategical also
[10:58] CarlosRuiz: we didn't have 2pack
[10:58] CarlosRuiz: we didn't have events in model validator
[10:58] CarlosRuiz: we didn't have lots of things
[10:58] CarlosRuiz: that we have now thanks to libero
[10:58] vpj-cd: yes Carlos but we do not solve the main issue
[10:59] * xp_prg wishes red1 was here, he is good at managing meetings and ideas :>
[10:59] CarlosRuiz: without libero I'm pretty sure we won't have 2pack and model validators and many other things at this moment
[10:59] vpj-cd: overlap sequences in adempiere
[10:59] CarlosRuiz: and I feel
[10:59] CarlosRuiz: that we're 98% in the path
[10:59] MCalderon: what do you mean Carlos?
[10:59] CarlosRuiz: and we're going into trunk when we need just 2% of the needed effort
[10:59] CarlosRuiz: to make it pluggable
[10:59] vpj-cd: i hope do not include libero in trunk
[11:00] vpj-cd: is politic desition
[11:00] CarlosRuiz: no, Victor is not politic
[11:00] jsSolutions: about pluggability... it seems Carlos has good ideas, Victor has ideas, Marco has ideas. but not a lot of coordination
[11:00] jsSolutions: maybe the meetings should be in Spanish :)
[11:00] CarlosRuiz: and what I've seen
[11:00] MCalderon: just a question Victor, your main problem are the sequences?
[11:00] CarlosRuiz: is that here ideas don't become reality without a strong need
[11:00] vpj-cd: integrate libero in trunk is reality easy
[11:01] vpj-cd: the codi is only copy and add a new directory in trunk
[11:01] CarlosRuiz: 2pack is a reality now thanks to libero (again, excuse me of being repetitive)
[11:01] CarlosRuiz: without the need of libero - 2pack wouldn't evolve
[11:01] vpj-cd: import libero ad core is easy with libero
[11:01] vpj-cd: create the script migration is great task but i can made
[11:02] vpj-cd: my question waht is the issue to set in trunk
[11:02] CarlosRuiz: I'm not against libero, please solve my first question:
[11:02] CarlosRuiz: 1 - how are we going to improve adempiere as pluggable without the libero need?
[11:02] croo: is 2pack a reality though? I've met a lot of people in IRC who couldn't install libero?
[11:02] croo: can I take libero and test with the trunk now?
[11:02] xp_prg: me too croo, well can we decide on the issue CarlosRuiz is bring up, who here agrees that 2pack will not evolve without libero?
[11:03] MCalderon: so Carlos, you are afraid of "losing" 2pack?
[11:03] vpj-cd: 2pack continue your evolve with other contribution
[11:03] CarlosRuiz: yep, redhuan said yesterday he had no problems with installing it into trunk
[11:03] CarlosRuiz: not just 2pack Mario
[11:03] CarlosRuiz: we need Document and Accounting flexibilization
[11:03] jsSolutions: good question croo. Carlos says we are VERY close to having 2Pack/Libero working easily
[11:03] CarlosRuiz: we need Initial setup modifications
[11:03] jsSolutions: do others agree?
[11:03] vpj-cd: and I think that do not set libero in trunk becasue 2pack can stop
[11:03] xp_prg: jsSolutions, installing libero is not easy currently trust me
[11:04] vpj-cd: this do no is enough reason
[11:04] xp_prg: red1 has not completed his installation by the way
[11:04] CarlosRuiz: what did say Redhuan yesterday in forums?
[11:04] xp_prg: CarlosRuiz, I am helping him, I know what he is doing
[11:04] xp_prg: it is not complete yet
[11:04] CarlosRuiz: so, the way to solve 2pack and pluggable problems - is putting everything in trunk
[11:05] CarlosRuiz: I feel that we're 98% on the way
[11:05] xp_prg: CarlosRuiz no, I think we need to identify the 2pack problems and work on them, but not deny entry into trunk just because of a need for 2pack functionality yes?
[11:05] fer_luck: even tim says it's hard to install.. tim is workin on libero for months now..
[11:05] hengsin: Tim: is there 2pack related bug report for that ?
[11:05] xp_prg: hengsin please let me illustrate some of the problems I am seeing ok?
[11:05] vpj-cd: but reality 2pack do not is viable until we solve the issue with sequences
[11:05] MCalderon: Carlos: what are the 2% left?
[11:06] xp_prg: 1. LiberoValidator does not work so I have to setup all the AD list types etc... manually
[11:06] vpj-cd: if you want that 2pack teste more
[11:06] hengsin: LiberoValidator doesn't work is not because of 2pack
[11:06] vpj-cd: you should prouse that posterita
[11:07] vpj-cd: using also 2pack
[11:07] hengsin: it is a problem with the modelvalidator API
[11:07] vpj-cd: but not only libero
[11:07] hengsin: even in trunk now, it WOULD NOT work.
[11:07] xp_prg: 2. I wrote a whole bunch of code to migrate data into Libero that is now broken because the core classes no longer have the methods that were called
[11:07] vpj-cd: I am think the issue is a politic desition
[11:07] *** Niraj has signed off IRC ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]").
[11:08] xp_prg: I am just talking about how hard it is to get Libero up and going
[11:08] jsSolutions: what I understand Carlos is saying that if we could finish 2Pack just as easily as putting libero in trunk and this would be better all the way around
[11:08] xp_prg: it is not easy but hard, can we please agree on that?
[11:08] jsSolutions: xp_prg all the things you listed will be trunk problems also
[11:08] MCalderon: Am In right that maintaining Libero is very difficult for the Libero developers?
[11:08] hyksos: with ADempiere i can agree
[11:09] xp_prg: MCalderon, that has been my experience
[11:09] fer_luck: CarlosRuiz: my question is, why keep libero out to fix 2pack? there are more people here that need libero than people that need 2pack
[11:09] hengsin: guys, please do not blame all Libero issue on 2pack and "Libero not in trunk" . Anyway, I think since majority feels that's the way forward, we can create a branch to test out the integration of Libero into core, agree ?
[11:09] vpj-cd: yes Joel but the issue do not is 2pack
[11:09] xp_prg: the trunk changes, Libero breaks, we flounder trying to fix it all to work jus tright
[11:09] vpj-cd: the issue es
[11:09] MCalderon: And that the people developing Libero sees that integrating it to trunk will ease their work?
[11:09] vpj-cd: Adempiere and current architecure to management sequences
[11:09] xp_prg: yes MCalderon
[11:10] jsSolutions: hengsin: +1 we can create a branch to test out the integration of Libero into core
[11:10] jsSolutions: at the time we freeze the trunk
[11:10] fer_luck: jsSolutions: ok, but when it will be migrated into trunk? and another question.. why hasn't it been done with posterita also?
[11:11] xp_prg: jsSolutions, we already know how it works with the core, we don't need to do this I think
[11:11] hengsin: Tim: that's just not true, we always try not to drop any method to maintain backward compatibility but I'm not going to argue further on this.
[11:11] vpj-cd: Joel and Low the branch was created from 1 year]
[11:11] fer_luck: I don't want to pick a fight with anyone from posterita here, but hey, that's 2 treatments for the same issue.. I'm sorry for those that don't agrree with my Point of view, but it's the truth..
[11:11] vpj-cd: this way now as the tim and other are test
[11:12] vpj-cd: we created the branch
[11:12] xp_prg: I have tested Libero already integreated with the core, it works quite well
[11:12] vpj-cd: now the ppl want see libero in trunk
[11:12] vpj-cd: I made all necessary
[11:12] vpj-cd: fist ask to Tim to improve 2pack
[11:12] xp_prg: Victor has prepared for it to go into trunk, it is ready, lets move forward on this, I have tested it as well
[11:13] vpj-cd: Low also refactori great work
[11:13] vpj-cd: we made the bran in svn server
[11:13] hengsin: guys, this is to avoid interfering with the effort to release 3.4, Libero can be in branch first and then merge back into trunk as the base for 3.5, what's the issue with this ?
[11:14] vpj-cd: I tries to delete the dependencies
[11:14] vpj-cd: with core
[11:14] xp_prg: hengsin well my issue is that it is not necessary, we have tested it already integrated with trunk, but I guess I don't understand your concerns
[11:14] *** CarlosRui1 has joined #adempiere-team.
[11:14] vpj-cd: and now only have with acct engine
[11:14] fer_luck: I give up.. nothing that we say will change your mind... :-(
[11:14] MCalderon: people we have to concentrate
[11:14] MCalderon: please be objective
[11:14] CarlosRui1: sorry, I got disconnected from my cable connection :-( swapped to the wimax
[11:14] * xp_prg hugs fer_luck don't give up!
[11:14] vpj-cd: I go wait to 3 year to JJ integrate libero
[11:14] vpj-cd: and 1 year in adempeire
[11:15] xp_prg: right Victor, we are ready, waiting another year is inappropriate
[11:15] vpj-cd: the community need other fork to integrate libero?
[11:15] MCalderon: first the question has t be solved: Libero into trunk? yes or now
[11:15] CarlosRui1: wow, things heated while I was out there ?
[11:15] MCalderon: then when
[11:15] MCalderon: and how
[11:15] xp_prg: +1 not to put Libero into trunk and not put it into a test branch
[11:15] MCalderon: ??
[11:16] hyksos: +1
[11:16] fer_luck: why did we start this fork anyways
[11:16] fer_luck: wasn't it to have oour code into trunk?
[11:16] croo: +1 stablise and then put in .... but just because we want to make sure if there are problems that's it libero and not something else that was added
[11:16] fer_luck: we had lots of contribs that were note being accepted
[11:16] CarlosRui1: I'm lost- my connection broke after I said "!CarlosRuiz: but that's my feel simply"
[11:16] CarlosRui1: I don't know what are you voting or talking about
[11:17] hengsin: guys, I don't understand the problem, having it in branch first, you can still make AdempiereLibero release for the community. If we do it now, we would have to move all the dates we have just set ...
[11:17] xp_prg: not to be melodramatic but Victor is contemplating forking Adempiere if this is not solved, lets not splinter Adempiere further I beg of you
[11:17] CarlosRui1: again Fer is missing the point - we're not talking about not accepting contributions - but what's the best way to integrate contributions with adempiere
[11:17] vpj-cd: Low the branch are created
[11:17] xp_prg: hengsin we have already done this
[11:17] CarlosRui1: everybody is free to fork
[11:17] CarlosRui1: that's not melodramatic
[11:18] jsSolutions: and threats are not helpful to your cause
[11:18] xp_prg: I didn't threaten it :)
[11:18] fer_luck: CarlosRui1: Carlos, it's simple.. Victor is working for 1 year over this libero project.. nice.. he contributed all he had done in the pg port.. now what's going on.. why can't libero be accepted as core?
[11:18] fer_luck: what's the main problem
[11:18] *** vpj-cd has signed off IRC (Read error: 104 (Connection reset by peer)).
[11:18] fer_luck: why fork again? so we'll have another division on developers?
[11:18] xp_prg: uh, oh, where is Victor?
[11:19] CarlosRui1: I mean why you think the only way is in trunk?
[11:19] *** vpj-cd has joined #adempiere-team.
[11:19] xp_prg: fer_luck that would be bad, I don't want anyone to fork
[11:19] CarlosRui1: there is just one way to do this?
[11:19] fer_luck: why not?
[11:19] xp_prg: CarlosRui1 I think it is a matter of time, people want Libero now
[11:19] CarlosRui1: why yes?
[11:19] fer_luck: I'll make a better question then
[11:19] MCalderon: plese, lets concentrate
[11:19] vpj-cd: I undestand not the reason to do not set libero in trunk
[11:19] vpj-cd: Carlos what is the reason
[11:19] croo: i think we should stop discussing why and just start discussing how
[11:19] vpj-cd: what is your reason?
[11:19] xp_prg: me too croo
[11:19] CarlosRui1: I repeat : I think the effort to put libero in trunk is similar to the effort making adempiere pluggable - that's simply my opinion
[11:20] vpj-cd: and because we made not to posterita
[11:20] xp_prg: CarlosRui1 who agrees with you that it is not harder to make libero a package and work just right or easier to put it into the trunk?
[11:20] CarlosRui1: I'm asking you if you're open to options - there is just one option
[11:20] CarlosRui1: there is just - or you allow this in trunk or we fork?
[11:20] fer_luck: as I said once already, I'll stop discussing this...
[11:20] vpj-cd: only libero
[11:20] fer_luck: I'm not changing anyones mind
[11:20] vpj-cd: all the contribution should are pluggable
[11:20] jsSolutions: fer_luck, your input is good
[11:21] CarlosRui1: well, I missed the proposal of branch - what's that
[11:21] jsSolutions: hengsin recommended integrating to a branch, Victor says that is done
[11:21] fer_luck: jsSolutions: well, we've already voted it to commit into trunk.. we hjave a majority here that wants libero... and we've been discussing all this for how long already?
[11:22] CarlosRui1: fer, do you think is just a simple votation? don't we need to discuss the technicals? the functionals? the strategicals?
[11:22] fer_luck: I do think
[11:23] CarlosRui1: ok, another proposal we can allow fer and Tim integrate libero into trunk, and developers can work in 3.4.0 stable while the integration is finished
[11:23] fer_luck: CarlosRui1: look, this is nothing against you, I really like you as a person.. But this discussion is taking us nowhere.. unless we say, from now on, every little thing that will be added to adempire must be a pluggable module..
[11:23] vpj-cd: what technicals
[11:23] MCalderon: I think evreyone has put his arguments, don't you think
[11:23] vpj-cd: what fuctionals
[11:23] vpj-cd: what strategicals
[11:23] jsSolutions: yes, Mario, there's not more to explore here
[11:23] CarlosRui1: yes, look, I'm talking as PMC - remember that I must look for the future
[11:23] CarlosRui1: I suppose you expect from me to have vision
[11:23] CarlosRui1: and my vision is that without the need of libero
[11:23] vpj-cd: what is the criterial to include posterita in trunk e technicals? the functionals? the strategicals?
[11:23] fer_luck: I know.. but we must have a same way to act for everyne
[11:23] MCalderon: and we are diverting to personal feelings
[11:23] *** CarlosRuiz has signed off IRC (Connection timed out).
[11:23] CarlosRui1: adempiere won't become pluggable never
[11:24] xp_prg: CarlosRui1 I don't disagree that 2pack needs to be improved, but not at the expense of libero now into trunk, just my opinion
[11:24] CarlosRui1: Victor, this is not personal - I don't like your tactics
[11:24] jsSolutions: Carlos, we can fork to be pluggable :-D
[11:24] xp_prg: hahah
[11:24] jsSolutions: let's go back to sum the agenda?
[11:24] CarlosRui1: look, I made another proposal
[11:24] croo: you can make 2pack work with the libero HR :)
[11:24] CarlosRui1: do you read?
[11:25] CarlosRui1: I missed the proposal of branch - and looks like Heng Sin went out
[11:25] xp_prg: CarlosRui1 Victor tactics have been to work on this for a year and to be very patient
[11:25] CarlosRui1: Victor tactics is innuendos about unfairness
[11:25] CarlosRui1: I don't want to enter in a personal discussion
[11:25] jsSolutions: back to the agenda ?
[11:25] CarlosRui1: I'm here thinking on adempiere as you are
[11:25] xp_prg: ok, yes back to the agenda
[11:25] hengsin: no, I'm still here, feel pretty sleepy though :)
[11:25] jsSolutions: we agreed to 3.4 target
[11:25] * xp_prg hugs hengsin so he feels better
[11:26] jsSolutions: community strongly asks for libero in trunk
[11:26] CarlosRui1: well, what was the proposal of branch that heated up the environment?
[11:26] jsSolutions: carlos, it was a rejected idea
[11:26] xp_prg: I agree it was rejected
[11:26] fer_luck: CarlosRui1: it's just that victor has already done this..
[11:27] jsSolutions: after the 3.4 stable release, integrate libero to trunk
[11:27] fer_luck: Put yourself into his place... waiting for one year to have libero integrated into adempiere.. and now people want to make him wait another year... not even knowing if it will ever be into trunk
[11:27] fer_luck: that's the problem..
[11:27] hengsin: done without making any release, that is.
[11:27] CarlosRui1: look, again as PMC I think that we loose an opportunity if we don't finish the work of being pluggable
[11:27] CarlosRui1: but I can't be against community needs
[11:27] MCalderon: I do not have the technical understanding, but can both sides make a compromise?
[11:27] vpj-cd: Carlos you need give community concert reason because you want not include libero in trunk
[11:27] *** croo_ has joined #adempiere-team.
[11:28] CarlosRui1: Victor
[11:28] CarlosRui1: I did
[11:28] CarlosRui1: all this time
[11:28] vpj-cd: but I get not
[11:28] CarlosRui1: I'm saying my opinion
[11:28] fer_luck: I mean, just imagine you've spent a lot of your money and a lot of your time.. and now it iw not being accepted again.. that's the problem.
[11:28] CarlosRui1: I consider we're loosing a big opportunity for adempiere
[11:28] fer_luck: If I was in victor pants I'd be mad as hell already.. :-)
[11:28] CarlosRui1: this is not against anybody or against libero
[11:28] vpj-cd: if the reason are reasonable I can undestand
[11:28] CarlosRui1: but I can't stop community
[11:28] CarlosRui1: but there are other things I can do
[11:28] jsSolutions: fer_luck, Carlos is in the same place with pluggable architecture
[11:29] vpj-cd: but without reason then i only can think is politic desition
[11:29] jsSolutions: it has been worked on since the beginning
[11:29] fer_luck: jsSolutions: has he developed the plugabble architecture?
[11:29] jsSolutions: many hours on it
[11:29] MCalderon: please do not start being personal
[11:29] CarlosRui1: Fer, again you miss the point - is not about not accepting it - is about HOW?
[11:29] jsSolutions: we must listen to all even if we disagree
[11:30] fer_luck: CarlosRui1: I already know that it's about How. :-) but I'm trying to find a point where everyone will end up happy
[11:30] vpj-cd: all the ppl want libero in the trunk
[11:30] fer_luck: if we want a tool to allow 2pack development, make it FA..
[11:30] CarlosRui1: nope
[11:30] CarlosRui1: all people WANT LIBERO
[11:30] vpj-cd: the unique ppl want not is Calos
[11:30] vpj-cd: Carlos
[11:30] xp_prg: right fer_luck how about that CarlosRui1?
[11:30] CarlosRui1: to have it into trunk is another decision
[11:30] hengsin: fer_luck: that is not true, it is accepted, it is in svn contribution and victor have the freedom to release any time an AdempiereLibero bundle for the community.
[11:30] fer_luck: not into trunk...
[11:30] xp_prg: hengsin a majority of the users can't get it installed though
[11:30] vpj-cd: yes Low but what is the reason
[11:31] vpj-cd: to include in trunk
[11:31] jsSolutions: xp_prg, they could if there was a release...
[11:31] CarlosRui1: we're going into circles
[11:31] vpj-cd: a valid reason
[11:31] CarlosRui1: look, I also want to find a good solution for this
[11:31] CarlosRui1: I don't want to leave another meeting without a good conclusion
[11:31] xp_prg: a binary release is not conducive to code improvement I think
[11:31] CarlosRui1: so, let's hear proposals
[11:31] vpj-cd: the community want libero in trunk
[11:31] fer_luck: jsSolutions: I don't have the time to manage 4 different versions here..
[11:31] CarlosRui1: Victorç
[11:31] jsSolutions: repeating my vote... stable release, libero, pluggable architecture
[11:31] vpj-cd: what is the issue?
[11:31] CarlosRui1: community WANTS LIBERO
[11:31] fernandoxavier: sorry, but i cannot participate in this meeting.. work :-( but, about libero question, i think that is better we concentrate in architecture problems (control sequences, persistence, for example), before integrate more functions. work in architecture, thinking in the future, is more important than put more functions in core...for my customer, sure, is more important integrate trunk..but, customers dont understand about software architect
[11:31] fernandoxavier: ure..but, if majority needs libero in trunk, it's ok for me.. just my opinion
[11:31] CarlosRui1: wants an usable libero
[11:31] CarlosRui1: that's all
[11:32] CarlosRui1: to put into trunk or not is technical
[11:32] CarlosRui1: and strategical
[11:32] hengsin: tim: you miss the point, a lot of peoples here miss the point, in trunk wouldn't get you more hand in testing, you should make release for that. It have been saying Libero branch have been created for a year now but I'm not seeing any AdempiereLibero release for people to test and to verify that it is stable by many hand.
[11:32] MCalderon: people, can we recapitulate so we can maybe reach a decision?
[11:32] CarlosRui1: is like saying people wants GNOME on linux core
[11:32] vpj-cd: again carlos
[11:32] MCalderon: first, what are the questions to be answered?
[11:32] vpj-cd: libero no is gnome
[11:33] CarlosRui1: people wants a desktop
[11:33] CarlosRui1: simply
[11:33] CarlosRui1: no matters if it's in linux core or as package
[11:33] xp_prg: who here agrees that mrp is core erp functionality?
[11:33] CarlosRui1: people simply needs a desktop
[11:33] xp_prg: if it is, it should be in the trunk yes?
[11:33] CarlosRui1: who here agrees that GNOME is an important operating system functionality?
[11:33] MCalderon: PEOPLE!!!!!!!!!
[11:33] CarlosRui1: that's not the point
[11:33] CarlosRui1: please
[11:33] MCalderon: PLEASE!!!
[11:33] CarlosRui1: let's hear proposals
[11:33] MCalderon: let's behave
[11:34] jsSolutions: repeating my vote... stable release, libero into trunk, pluggable architecture
[11:34] MCalderon: what are the questions to be solved?
[11:34] MCalderon: 1st? Do we want Libero?
[11:34] croo_: well strictly speaking hnome does not run on linux but on X11 ... and there is on one option there
[11:34] emontenegro: Agree with jsSolutions ....
[11:34] CarlosRui1: 1 - to finish the pluggable work (almost finished) and ensure libero work as pluggable
[11:34] CarlosRui1: 2 - to allow libero into trunk after 3.4
[11:34] CarlosRui1: I don't think there are more proposals
[11:34] xp_prg: well a radical proposal is to do the oppositive of what Hengsin proposed, branch the current trunk and let him continue to release 3.4 on that branch, integrate libero into trunk and then migrate new functionality from the 3.4 branch into main trunk with libero integrated already
[11:34] fer_luck: my vote is like joel's vote
[11:35] CarlosRui1: I would like Tim proposal
[11:35] fer_luck: best way of doing that..
[11:35] CarlosRui1: branch 3.4
[11:35] CarlosRui1: if developers work in 3.4 and trunk is for experimenting people
[11:35] CarlosRui1: it's the same thing with other words
[11:35] fer_luck: if we want a pluggable architecture, let FA package be the one to do this.. MRP is more important than FA by now...
[11:36] fer_luck: It's doubling the effort.. again...
[11:36] MCalderon: Carlos, but I understand the wish is to BE in trunk
[11:36] fer_luck: So we have one version with libero, one without it that's trunk and one without it that is 3.4
[11:36] MCalderon: from 3.4 on
[11:36] fer_luck: I completely disagree
[11:36] croo_: FA is basic for every business! make HR pluggable !
[11:36] xp_prg: well it is a compromise that would allow libero into the trunk fer_luck, but I agree it would be duplicatation of effort
[11:36] CarlosRui1: no Mario - the wish of people is to have manufacturing
[11:36] croo_: i say stabilise, then trunk libero
[11:36] fer_luck: have you guys ever heard that thing called KISS.. I always say that to myself when trying to complicate things
[11:37] fer_luck: just keep it simple
[11:37] fer_luck: the path is
[11:37] fer_luck: stable, then libero into trunk, then pluggable architecture with liberohr or whatever you guys want to come up with to fill the gap...
[11:37] CarlosRui1: well I think Colin proposal can sounds good
[11:37] CarlosRui1: that can solve partially my main issue
[11:38] vpj-cd: who say if libero is stable
[11:38] MCalderon: Carlos: do you agree to have Libero in trunk from 3.4 onwards?
[11:38] CarlosRui1: look, the main difference of opinions here are:
[11:38] CarlosRui1: you propose: stable, then libero, then pluggable
[11:38] CarlosRui1: I think: stable, then pluggable, then libero
[11:38] CarlosRui1: is simple, we can deal with this
[11:38] croo_: vpj-cd, we mean stablise trunk... not libero
[11:39] jsSolutions: yes, stable release, 3.4 Dec 25
[11:39] fer_luck: CarlosRui1: ok, will you develop pluggable? how long will it take?
[11:39] jsSolutions: then Libero comes in
[11:39] vpj-cd: i think that libero need include in current version
[11:39] MCalderon: SO the question is NOT Libero in trunk yes or no, but when?
[11:39] CarlosRui1: so a new proposal appeared
[11:39] CarlosRui1: stable - then manufacturing - then fixed assets - then pluggable - then HR
[11:39] fer_luck: that's ok
[11:39] fer_luck: let's go this path
[11:39] jsSolutions: yes
[11:39] vpj-cd: the ppl can test and we can set how stable vesion in3.4
[11:39] xp_prg: I agree with Victor, Victor and I have tested libero with the current version, it is ready to go into trunk right now
[11:39] jsSolutions: nope
[11:39] CarlosRui1: look
[11:40] jsSolutions: 3.4 first
[11:40] CarlosRui1: agree 3.4 first
[11:40] jsSolutions: 4.1 with manufacturing
[11:40] *** vishee has signed off IRC ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007040314]").
[11:40] MCalderon: let's recapitulate
[11:40] croo_: vpj-cd, victor I would like to see it asap too but there is a lot of stuff gone into trunk ... better make sure it all works otherwise every problem might lok like a libero problem!
[11:40] CarlosRui1: look, I have one more worry
[11:40] fer_luck: 4.0 with manufacturing.. why 4.1? :-)
[11:40] jsSolutions: beta
[11:41] CarlosRui1: 3.4 is the stable version for businesses
[11:41] CarlosRui1: will be
[11:41] fer_luck: I think libero should be 3.5
[11:41] CarlosRui1: so, I think we need to ask that sponsored developments must be developed for 3.4
[11:41] CarlosRui1: not for trunk
[11:41] fer_luck: god knows how manuy core changes will be done until 4.1 that will break libero?
[11:41] xp_prg: right fer_luck
[11:41] jsSolutions: fer_luck, we're skipping 3.4 to 4.1
[11:41] fer_luck: then we get fixed assets on 3.6
[11:42] jsSolutions: so that libero gets it's own number!
[11:42] CarlosRui1: in other words, sponsored developments must work in 3.4 and be integrated in trunk
[11:42] fer_luck: and then we get 4.1
[11:42] vpj-cd: then libero have wait 4 mouth to set in trunk
[11:42] vpj-cd: and the people can test
[11:42] xp_prg: right, 4 months is too long
[11:42] croo_: can we not stick FA into 3.4?
[11:42] CarlosRui1: Victor - I think the branch is a good proposal
[11:42] fer_luck: jsSolutions: we shouldn't do that.. will only confuse users...
[11:42] jsSolutions: no, it's good to have a new number series for significant release
[11:42] jsSolutions: common practice
[11:42] fer_luck: croo_: it's the same issue that we have with libero.. I want both FA and libero...
[11:43] CarlosRui1: the branch can work parallel to the 3.4 target - and when 3.4 is released the branch can become the trunk easily
[11:43] hengsin: people, what stopping you from making an AdempiereLibero release for people to test now ?
[11:43] vpj-cd: Carlos the brach have old year
[11:43] fer_luck: not 4.1 then...
[11:43] vpj-cd: Low the issue is a customer or end user go
[11:43] xp_prg: CarlosRui1 lets do my proposal, branch the trunk now for 3.4 now, and let libero into trunk right now
[11:43] croo_: but I didn't think FA was as big or complex and yet is something everyone (manufacturere or not) needs
[11:43] CarlosRui1: can you answer please Heng Sin question?
[11:43] vpj-cd: witn this version in production
[11:43] CarlosRui1: no Tim
[11:43] jsSolutions: tim, that won't pass vote
[11:43] *** croo has signed off IRC (Connection timed out).
[11:43] fer_luck: xp_prg: no
[11:43] vpj-cd: becasue is your need how migrarate in future
[11:43] fer_luck: this is too cumbersome
[11:43] CarlosRui1: we have enough work to do with the current trunk
[11:43] jsSolutions: we have to have a stable before libero goes in
[11:44] jsSolutions: otherwise the bugs are complicated
[11:44] xp_prg: ok
[11:44] croo_: jsSolutions, yes I think so too .... if just to ensure linero doesn't get a bad rap!
[11:44] CarlosRui1: can't we set up a branch for libero and release AdempiereLiberoBeta for testings?
[11:44] xp_prg: I just think people want libero soooo bad, they will assist with bugs if libero was put in now
[11:44] jsSolutions: exactly, Victor will get blamed for everything!!
[11:44] CarlosRui1: even before 3.3.1
[11:45] fer_luck: Ok, let's do it like that.. Right now, people go working out on bugs to stabilize 3.4.. meanwhile, we can set a project to migrate libero.. we get the Dev ID's and stuff and start the work.. as soon as 3.4 comes out, libero get's in..
[11:45] vpj-cd: the bug we find are of libero
[11:45] vpj-cd: do not the adempiere core
[11:45] vpj-cd: what is the issue
[11:45] CarlosRui1: the ID's can be solved with the centralized proposal
[11:45] jsSolutions: Tim, that's my point! if we must have stable before libero, then everyone can chip into stable
[11:45] X0d_of_N0d: why not just slate libero for 3.5.0 beta...
[11:45] vpj-cd: Joel you have not issue with current fuctionality
[11:45] X0d_of_N0d: and include it in 3.6.0 stable?
[11:45] vpj-cd: the bug is only libero and Tim and me or other can help to fixed
[11:45] CarlosRui1: look, we already agreed 3.4.0 functionality
[11:45] X0d_of_N0d: I mean honestly, isn't the idea of stabalization just that..
[11:46] X0d_of_N0d: take a beta and make it stable
[11:46] X0d_of_N0d: so take 3.3.0 and fix as many bugs as possible
[11:46] CarlosRui1: and we're trying to agree the best way to get manufacturing + FA + pluggable HR
[11:46] CarlosRui1: now you're trying to change what we talked all morning :-(
[11:46] xp_prg: I agree with Victor we will solve bugs so very fast together, it will not hurt current trunk at all
[11:46] fer_luck: ok
[11:46] MCalderon: As I understand, there is an agreement that Libero should be included into trunk, the question is WHEN?
[11:46] fer_luck: let me put it as I do develop
[11:46] CarlosRui1: look
[11:46] CarlosRui1: again the question from Heng Sin
[11:46] jsSolutions: as soon as 3.4 is released, libero comes into core
[11:47] vpj-cd: Mario only Carlos say yes
[11:47] xp_prg: jsSolutions, that could be 4 months though right?
[11:47] CarlosRui1: what are stopping you from releasing an AdempiereLiberoBeta ?? do you need a branch?
[11:47] CarlosRui1: do you need developer ID's?
[11:47] CarlosRui1: done
[11:47] croo_: well I would be ok with 3.3.1 freeze, 3.3.2 stable, 3.3.3 libero, 3.4 stable release but it's just different numbering :)
[11:47] fer_luck: I have a project in eclipse with all the classes I modified, that overwrites the classpath of the original project... this is how we can make libero work with adempiere 3.4, trunk or whatever.. so, whenever 3.4 is released it's just a matter of uploading it into trunk and we have libero integrated into adempiere..
[11:48] CarlosRui1: yes, fer
[11:48] CarlosRui1: you can put that into a branch
[11:48] fer_luck: CarlosRui1: that's not for libero
[11:48] CarlosRui1: and release immediately a libero for testing
[11:48] jsSolutions: yeah, number ing is side issue. again my vote :)
[11:48] jsSolutions: yeah, number ing is side issue. again my vote :)
[11:48] fer_luck: is for my own modifications and adempierelbr
[11:48] X0d_of_N0d: shouldn't this get looked at before even thinking about libero? (Link: http://sourceforge.net/tracker/?group_id=176962&atid=879332)http://sourceforge.net/tracker/?group_id=176962&atid=879332
[11:48] CarlosRui1: you can even release a libero before 3.3.1 if you want
[11:49] vpj-cd: yes Carlos the comunnity want this
[11:49] xp_prg: CarlosRui1 please hear this from me, Victor and I have already tested libero functionality in the trunk, it works, it will not hurt the trunk to just put it in now
[11:49] CarlosRui1: yes, we agreed to look for stable first this morning
[11:49] fer_luck: xp_prg: those are things I have to evaluate and say if they are working or not.. I haven't used trunk for 2 months already.. Why don't you just do it X0d_of_N0d?
[11:49] CarlosRui1: ok Tim, can't you release that in a branch? what's the problem?
[11:49] fer_luck: X0d_of_N0d: adempiere bazaar does not pay my bills, my customers do...
[11:50] jsSolutions: let's put this in forum for vote, and close this meeting:
[11:50] jsSolutions: 3.3.1 freeze, 3.3.2 stable, 3.3.3 libero, 3.4 stable release
[11:50] X0d_of_N0d: don't your customers want a stable product?
[11:50] CarlosRui1: Joel
[11:50] vpj-cd: Carlos we have now a branch
[11:50] xp_prg: CarlosRui1 it is an inefficient unnecessary divisiion of libero that could threaten to destabalize Adempiere
[11:50] jsSolutions: numbering up for discussion
[11:50] MCalderon: Is it true? Do all difficulties come from numbering? Fer? Victor?
[11:50] xp_prg: division of labor I meant
[11:50] CarlosRui1: 3.3.1 freeze - and several 3.3.X - then 3.4.0 stable
[11:50] CarlosRui1: then libero + FA -> call it whatever you like
[11:50] vpj-cd: are are equal if you give as option the branch
[11:50] fer_luck: X0d_of_N0d: they're working with 3.2.0, besides LBR is really big work for my company to do
[11:50] fer_luck: X0d_of_N0d: why don't you evaluate them then?
[11:51] fer_luck: MCalderon: numbering currently sucks..
[11:51] fer_luck: X0d_of_N0d: you gotta be nuts to have a customer running on trunk...
[11:51] CarlosRui1: numbering doesn't matter, the strategy is the important
[11:51] * xp_prg does not understand this incredible fear of all kinds of bugs happening in Adempiere if libero is put into trunk
[11:51] CarlosRui1: Tim, Heng Sin is the main maintainer of trunk
[11:51] CarlosRui1: put in his shirt also
[11:51] MCalderon: Carlos, Hengsin, is there a quick way to easy the pain of Libero developers meanwhile the trunk is stabilized?
[11:51] CarlosRui1: branch
[11:51] X0d_of_N0d: fer_luck: yes, you would have to be nuts
[11:51] xp_prg: it has already been tested with the trunk
[11:51] fer_luck: X0d_of_N0d: I don't need to solve those bugs, they have already been solved.. If I want I can just go there and say I tested all of them.. have you at least read what's there?
[11:52] CarlosRui1: the branch can be set up immediately if they want - the ID's can be assigned immediately if they want
[11:52] CarlosRui1: they can release an AdempiereLibero immediately if they wants
[11:52] xp_prg: how about this CarlosRui1 we put libero into trunk, if in a week all kinds of bugs happen, we reverse it?
[11:52] fer_luck: Those bugs are all solved by carlos.. I just need to evaluate them, but right now, my company is spending $5k monthly to pay our employees, and customers needs things done, if we don't get it to them they stop paying.. what's more important to you X0d_of_N0d ?
[11:52] X0d_of_N0d: (Link: http://sourceforge.net/tracker/index.php?func=detail&aid=1617426&group_id=176962&atid=879332)http://sourceforge.net/tracker/index.php?func=detail&aid=1617426&group_id=176962&atid=879332
[11:52] CarlosRui1: but I reject to put more work on my shoulders than currently we need to stabilize current trunk
[11:52] X0d_of_N0d: you mean like that?
[11:52] jsSolutions: tim, the bugs are already in the trunk
[11:52] jsSolutions: we want to solve them first
[11:53] X0d_of_N0d: all those bugs are fixed?
[11:53] xp_prg: but these bugs have nothing to do with libero is that not true?
[11:53] jsSolutions: right, but we want a stable release
[11:53] fer_luck: X0d_of_N0d: I don't know.. what bugs have you fixed btw?
[11:53] xp_prg: so putting libero into the trunk would not effect them at all right?
[11:53] jsSolutions: we want a stable release first
[11:53] fer_luck: or what have you done for this project so far?
[11:53] CarlosRui1: we're at the verge of an agreement and now you changed the request :-(
[11:53] *** karsten-thiemann has joined #adempiere-team.
[11:53] karsten-thiemann: hi all
[11:53] CarlosRui1: this way we're not going to finish this meeting
[11:54] xp_prg: hi karsten-thiemann!
[11:54] CarlosRui1: please, be consistent
[11:54] jsSolutions: carlos, we need to close the meeting
[11:54] fer_luck: sorry carlos,but it just get's me sick when someone that has done nothing that I know this far gets into my feet...
[11:54] MCalderon: Victor, Fer, Tim: is the numbering proposed OK for you?
[11:54] X0d_of_N0d: None, I just started looking at the project. But it seems to me that fixing major bugs should be a higher priority than adding functionality that might cause more bugs
[11:54] X0d_of_N0d: maybe I'm just crazy...
[11:54] fer_luck: MCalderon: I already work with it.. numbering is not a problem.. don't you worry about it..
[11:54] CarlosRui1: so
[11:54] CarlosRui1: please
[11:54] CarlosRui1: agreements
[11:54] xp_prg: I don't know Victor is above me if he says ok I will, I just think the testing has been done for the trunk alredady and it is ready
[11:55] * X0d_of_N0d sits back and watches
[11:55] fer_luck: X0d_of_N0d: fix it then..
[11:55] fer_luck: it's an open source project
[11:55] xp_prg: waiting another 4 months to put it into trunk could really hurt libero
[11:55] CarlosRui1: 3.3.1 beta nov-1
[11:55] CarlosRui1: 3.3.2, 3.3.3 whatever
[11:55] CarlosRui1: 3.4.0
[11:55] CarlosRui1: then manufacturing + FA
[11:55] CarlosRui1: then pluggable HR
[11:55] CarlosRui1: if you want you can set up a 3.3.1. branch for libero
[11:55] fer_luck: CarlosRui1: I think it's ok with the proposed path
[11:55] X0d_of_N0d: I'm aware of that, but it's harder to fix something when more stuff is being put in
[11:55] jsSolutions: +1
[11:56] fer_luck: no need to setup a branch on 3.3.1.. the brunch will be based on trunk...
[11:56] vpj-cd: Carlos the ppl want not wait 4 months
[11:56] xp_prg: what does Victor say?
[11:56] fer_luck: +
[11:56] fer_luck: +!
[11:56] vpj-cd: I vote the propuse the colin
[11:56] fer_luck: 3.4.0 = 25th november
[11:56] vpj-cd: release 3.2 , include libero in 3.3
[11:56] eliercio: +1
[11:56] CarlosRui1: ok, I need to go - I think if you change the proposal just when we arrive to an agreement this won't work
[11:56] vpj-cd: and release 3.4
[11:56] eliercio: I also think that libero should come with the release after 3.4.0
[11:56] vpj-cd: and release 4.0 with libero in december
[11:57] xp_prg: CarlosRui1, don't go we are close!
[11:57] CarlosRui1: discussing numbering is useless
[11:57] CarlosRui1: no, we're not close if you change the proposal
[11:57] vpj-cd: here exist 2 option
[11:57] fer_luck: CarlosRui1: there was somethin else to be discussed, wasnt?
[11:57] CarlosRui1: I thought we arrived already to an agreement
[11:57] karsten-thiemann: :) guess I missed a hard discussion..
[11:57] vpj-cd: libero to 3.3 or after 3.4 please voting
[11:57] fer_luck: karsten-thiemann: it was fun. :-)
[11:57] vpj-cd: and close this discution
[11:57] xp_prg: 3.3 libero +1
[11:57] CarlosRui1: no Victor, I don't agree with voting for this one
[11:57] vpj-cd: I vote 3.3 Libero +1
[11:58] fer_luck: libero comes after 3.4 victor
[11:58] CarlosRui1: we need a stable
[11:58] fer_luck: it's already been decided
[11:58] CarlosRui1: is a must
[11:58] jsSolutions: libero comes after 3.4
[11:58] fer_luck: vpj-cd: I'll help you mantain trunk
[11:58] fer_luck: when 3.4 is released libero is on
[11:58] MCalderon: What is the question?
[11:58] CarlosRui1: I'm proposing that with 3.3.1 you set up a branch for libero, so after 3.4.0 is released the integration is immediate with the branch
[11:58] vpj-cd: you are not in democracy ?
[11:59] CarlosRui1: Victor, there has been enough discussion here
[11:59] vpj-cd: exist 2 option in the table
[11:59] vpj-cd: we please voting
[11:59] MCalderon: Again, Libero is to be included into trunk, it is solved how, the question is the time between now and 3.4?
[11:59] CarlosRui1: gtg, really, I'm tired, Heng Sin must be sleep :-)
[11:59] vpj-cd: 3.3 or after 3.4
[11:59] vpj-cd: is easy
[11:59] vpj-cd: the comunnity are here
[11:59] CarlosRui1: we already said 4.1
[11:59] xp_prg: CarlosRui1 5 mor eminutes please!
[11:59] vpj-cd: we solve this via democracy
[11:59] CarlosRui1: we already discussed that
[12:00] CarlosRui1: we already give all our opinions
[12:00] vpj-cd: my vote is to 3.3
[12:00] CarlosRui1: now you want to change the proposal
[12:00] CarlosRui1: this is endless
[12:00] xp_prg: CarlosRui1 but what is the vote?
[12:00] croo_: ok look 3.3 3.4 4.0 are just numbers ... I think we all agree stablise trubnnk because lots of changes made some deep like c3po ... then add libero
[12:01] X0d_of_N0d: xp_prg: If the vote is cast, doesn't that mean it has been solved through democracy
[12:01] CarlosRui1: :-) maybe I need to fork out for a 3.4.0 stable :-D just joking, not threatening
[12:01] X0d_of_N0d: ?
[12:01] fer_luck: xp_prg, vpj-cd: we'll have libero working before 3.4.0 n trunk.. I can help you all..
[12:01] MCalderon: Victor: I think it was agreed tha Libero was to be put into trunk in3.4?
[12:01] MCalderon: Fer?
[12:01] xp_prg: fer_luck how if we can't commit to the trunk?
[12:01] fer_luck: xp_prg: yes..
[12:01] CarlosRui1: strategy: first a stable - then libero - then FA - then pluggable HR
[12:01] fer_luck: dont worry
[12:01] vpj-cd: yes in 3.3 as colin said
[12:01] CarlosRui1: I supposed that we all agreed on that since the beginning
[12:01] vpj-cd: we release 3.1 now
[12:02] jsSolutions: CR, Yes write it up in the forum, and let's close the meeting
[12:02] vpj-cd: next 3.2 as stable
[12:02] fer_luck: vpj-cd: victor, you know all the classes that you changed with libero, right?
[12:02] vpj-cd: and 3.3 libero is include
[12:02] fer_luck: and the classes you added also?
[12:02] vpj-cd: and neex is 3.4 and finish 3.4 release stable
[12:02] croo_: jsSolutions, yeah quick before someone says something else :D
[12:02] xp_prg: X0d_of_N0d, there has not been a vote so far as I can tell, just discussion
[12:02] jsSolutions: :-X
[12:02] hengsin: tim: what fer_luck say it is possible and not difficult at all. like I have been saying, there is nothing stopping you releasing AdempiereLibero 3.4 when we release Adempiere 3.4
[12:02] vpj-cd: yes fer
[12:02] vpj-cd: voting please
[12:02] fer_luck: vpj-cd: then don't worry
[12:02] vpj-cd: and close the discution
[12:03] fer_luck: we'll reserve all the id's and do this
[12:03] CarlosRui1: ok, vote whatever you want and let me know what the decision was
[12:03] CarlosRui1: this is endless
[12:03] xp_prg: ok CarlosRui1 we will vote and get back to you
[12:03] vpj-cd: the option to include libero in 3.3 or after 4.0
[12:03] xp_prg: ok lets vote now ok?
[12:04] xp_prg: +1 3.3 libero trunk inclusion
[12:04] fer_luck: vpj-cd, xp_prg: the thing will be. stable (3.4), libero integrated + fa and then pluggable
[12:04] croo_: ok the plan is ... stabilse trunk, then libero in the trunk, then release ... the numbering is just symantics ... that don't matter ... right?
[12:04] fer_luck: We can't include libero right now.
[12:04] xp_prg: fer_luck why?
[12:04] xp_prg: Adempiere doesn't affect these other bugs so having it in there won't hurt anything
[12:04] xp_prg: I mean libero
[12:04] MCalderon: OMG
[12:05] fer_luck: vpj-cd: we wont wait another 4 months
[12:05] vpj-cd: to integrate libero
[12:05] fer_luck: that's the only thing
[12:05] vpj-cd: fer we wnat not wiat 4 months
[12:04] fer_luck: the problem is tim, we have to fix those bugs to get sun to work with us
[12:05] vpj-cd: yes right
[12:05] fer_luck: it's a promisse I'm doing.. we'll have a parallel project that will run as easy as normal...
[12:05] CarlosRui1: ok, if you want to know my vote is
[12:05] CarlosRui1: +1 to allow manufacturing after 3.4.0 stable is released
[12:05] jsSolutions: if you don't want to wait, then speed the stable
[12:05] MCalderon: this is interesting!
[12:05] vpj-cd: the parrall is doble work
[12:06] fer_luck: vpj-cd: I've been working like this for 1 year already...
[12:06] CarlosRui1: votation, please? I need to take decisions
[12:06] vpj-cd: + 1 to allow manufactuing in 3.3
[12:06] CarlosRui1: if you think this is a community :-)
[12:06] xp_prg: ok so far we have 2 votes for 3.3 and 2 votes for 3.4 is that right?
[12:06] hengsin: victor: there is no double work with what fer_luck describe ...
[12:06] CarlosRui1: a representative community that knows the problem we're getting in
[12:07] fer_luck: vpj-cd: don't get me wrong, but look at the source of adempierelbr
[12:07] jsSolutions: +1 the thing will be. stable (3.4), libero integrated + fa and then pluggable
[12:07] fer_luck: it's just what Im proposing to you
[12:07] CarlosRui1: look my position, if the votation goes for libero into trunk - then I'll need a branch for set up a stable release for businesses
[12:07] hengsin: +1 for Libero in trunk after 3.4
[12:07] xp_prg: hengsin, I don't think that was 1 of the possibilities, it was either 3.3 or 3.4 not after 3.4
[12:08] MCalderon: Can we start the vote all over?
[12:08] CarlosRui1: hmmmm, numbering is not important!!!!
[12:08] CarlosRui1: the issue is
[12:08] CarlosRui1: before stable or after stable
[12:08] CarlosRui1: +1 after stable
[12:08] croo_: yes!
[12:08] xp_prg: +1 before stable
[12:08] jsSolutions: yep. +1 after stable
[12:08] karsten-thiemann: maybe add libero to 3.3.5 :p
[12:08] hengsin: +1 after stable
[12:08] MCalderon: Victor asked to include Libero right now . (Is it right victor?)
[12:09] MCalderon: There is another question to include it after that
[12:09] jsSolutions: mario, yes, that's the before stable vote...
[12:09] CarlosRui1: yes Mario, and I'm rejecting to maintain trunk - there will be too much work
[12:09] vpj-cd: +1 before stable
[12:10] MCalderon: you mean you will not maintain trunk if Libero is included right now?
[12:10] xp_prg: so 2 votes for before stable and 3 for after stable so far right?
[12:10] CarlosRui1: yes, I think this is already voted, we need a stable
[12:10] hengsin: tim: yes
[12:10] croo_: I think we have to ideas on what is stable ... on is the current trunk with reported bugs fixed... another is the next release
[12:10] xp_prg: croo and MCalderon please vote!
[12:10] croo_: next official release that is
[12:10] CarlosRui1: and the current work to stabilize trunk will be hardly enough
[12:10] CarlosRui1: to add it more layers
[12:11] xp_prg: croo vote please
[12:11] fer_luck: well.. I vote for stabilization than release
[12:11] croo_: I vote to stabilise the trunk then add libero
[12:11] xp_prg: 2 to 4 now
[12:11] xp_prg: 2 to 5 now
[12:11] xp_prg: MCalderon you gonna vote?
[12:11] karsten-thiemann: first stabilize - even if this means that I have to wait to put my extensions in..
[12:11] xp_prg: 2 to 6 now
[12:12] vpj-cd: yes karsten we need
[12:12] MCalderon: no, because I lack the real knowledge
[12:12] emontenegro: +1 Stable first, then Libero ....
[12:12] eliercio: stabilize than trunk
[12:12] vpj-cd: wait to dicember to include libero
[12:12] xp_prg: 2 to 7 now
[12:12] croo_: BUT, I think we should vote in the forum ... it's the middle of the night in asia .. many are asleep!
[12:12] hengsin: yep, except me maybe
[12:12] CarlosRui1: :-(
[12:12] xp_prg: I agree croo
[12:12] karsten-thiemann: I guess colin is right
[12:12] CarlosRui1: this meetings are simply useless
[12:12] fer_luck: forum is not a good voting place
[12:13] vpj-cd: ok then voting in the forum
[12:13] fer_luck: as I already stated on the beginning of the meeting
[12:13] croo_: not at all ... we have debated
[12:13] CarlosRui1: again people expect that PMC and CC and Council take decisions
[12:13] CarlosRui1: for the best of adempiere
[12:13] CarlosRui1: how a lurker can vote if first stable or libero - if nobody will help to fix bugs
[12:13] croo_: my point is simply that no everyone can be here now!
[12:13] MCalderon: that is why I did not vote, Carlos
[12:14] CarlosRui1: I would like to hear the people that are going to fix the bugs - the people that are going to test
[12:14] croo_: ok say everyone who is a SF project member can vote!
[12:14] CarlosRui1: and nobody can be in forums - we have a council, a PMC, a CC
[12:14] xp_prg: I will fix bugs and help CarlosRui1 !
[12:14] CarlosRui1: to think on strategy
[12:14] CarlosRui1: to think on how to get more developers
[12:14] CarlosRui1: to think on how to get more contributions
[12:14] CarlosRui1: etc
[12:14] CarlosRui1: etc
[12:14] CarlosRui1: etc
[12:15] CarlosRui1: but ok, if you want to vote, please do it, I'm really tired
[12:15] xp_prg: ok CarlosRui1 go to bed then
[12:15] CarlosRui1: I find these exercises ludicrous -
[12:15] * xp_prg tucks CarlosRui1 in his bed
[12:15] xp_prg: :)
[12:15] CarlosRui1: all what we talked here could be said in forums
[12:15] MCalderon: Victor: if you waited 3 years and 12 months, can you wait 6 more weeks?
[12:15] croo_: but no so quick ... it would take a month :)
[12:15] xp_prg: MCalderon it is now 6 weeks it is 4 months
[12:16] MCalderon: Really?
[12:16] xp_prg: now = not
[12:16] xp_prg: ya
[12:16] vpj-cd: Mario are 4 mound
[12:16] vpj-cd: 4 mouths
[12:16] croo_: I'm just saying there are many prominent members of the community who for whatever reason are not ehre now
[12:16] jsSolutions: i think the meeting is over, I'll volunteer to write up the summary
[12:16] CarlosRui1: ok, bye, hope somebody put this log in the wiki to review the decisions you take
[12:16] vpj-cd: the stable version are schedule to 25 december
[12:16] *** CarlosRui1 has left #adempiere-team.
[12:16] croo_: or we can just take the 5-2 vote as the end of the matter ....
[12:17] croo_: oh too late he's gone
[12:18] * xp_prg starts to shake hands with everyone just cuz
[12:18] croo_: lol
[12:18] croo_: who will wipe all te blood off the floor?
[12:18] MCalderon: You have reached almost all of the points you wanted
[12:18] vpj-cd: if we go to 3.4
[12:18] * xp_prg gets his mop
[12:19] vpj-cd: we need reservate id to libero and not wait 4 months to work with libero
[12:19] MCalderon: Carlos said the reservation was no problem
[12:19] vpj-cd: ok
[12:19] hengsin: tim, victor: I will say this for one last time, we will continue with current trunk for the 3.4 stable release but you can have your project setup to release AdempiereLibero for user along the way anytime you want.
Session Close (#adempiere-team): Wed Oct 17 12:20:05 2007
