PMC QA Meeting 20100310
Date: 2010-03-10
Time: 8AM GMT
Venue: irc #adempiere-team
Support Spreadsheet: Adempiere PMC QA
Chat times in GMT-5
(03:02:38) hengsin: carlos, is the QA meeting next ?
(03:03:41) CarlosRuiz: yep - supposedly - I see most of meetings disappeared from google calendar - so maybe the same happened to Ivan
(03:03:59) CarlosRuiz: I synchronize my cell phone with google calendar - and all those meetings were deleted
(03:04:10) CarlosRuiz: so, my cell phone didn't wake up me :-(
(03:04:26) interopen1 [~interopen@xiancaro.com] entered the channel.
(03:04:37) CarlosRuiz: ah, good, Ivan is here
(03:04:43) interopen1: Hi Carlos
(03:04:51) interopen1: sorry for the delay, just come from a meeting
(03:05:07) CarlosRuiz: No problem
(03:05:15) interopen1: we can start or continue
(03:05:51) CarlosRuiz: start
(03:06:41) interopen1: How about this schedule for today:
(03:07:17) interopen1: 1. Review documentation and arrange a letter in forum for contributions and people join
(03:07:47) interopen1: 2. We need to talk about the CI server where implement all the POC
(03:09:01) interopen1: 3. Would like to share some ideas about QA before non-maintain and maintain releases
(03:09:14) interopen1: if any other we can see it
(03:09:43) CarlosRuiz: I'm ok
(03:09:48) CarlosRuiz: with the proposed agenda
(03:10:44) interopen1: 1. we add some documentation about research to integrate Adempiere+Hudson and testing tools
(03:10:46) interopen1: http://www.adempiere.com/index.php/PMC:QA#Research_and_documentation
(03:11:28) interopen1: Fitnesse and Junit are ok
(03:11:59) interopen1: and Selenium have the problem we talk last week with Heng Sin about the session codes
(03:12:00) CarlosRuiz: yep, I saw the documents you and Sunny prepared
(03:12:19) CarlosRuiz: good work!
(03:12:28) interopen1: we are working with Sahi, but still is in research
(03:12:45) interopen1: looks easy to integrate, and we want to have it document it during this week
(03:13:28) interopen1: with this base of documentation we want to make it public, so any suggestion of the best way?
(03:14:16) CarlosRuiz: I think forums is the best
(03:14:17) hengsin: google doc or wiki
(03:14:19) interopen1: to see if other integrators have something to add or people want to join the group before we move into create POC
(03:14:27) hengsin: publish the link on forum
(03:15:17) interopen1: Ok, so clear point 1, all documented in the wiki and link in the forum
(03:15:25) CarlosRuiz: given the importance of this topic a little crossposting can be allowed - I mean, posting in several forums (with the corresponding note that is an intended crosspost because of the importance)
(03:15:25) hengsin: Ivan, you don't really have to wait, go ahead with whatever you have in mind. People will joint if they see the value in it but you cant predict that
(03:15:56) interopen1: ok, thanks for the advice
(03:16:09) interopen1: o think what forums are more related
(03:16:36) hengsin: I believe most follow open discussion and developer
(03:17:40) interopen1: ok, and how about call for a Issue manager?
(03:18:15) interopen1: i can include it
(03:18:52) interopen1: 2. second topic
(03:19:18) interopen1: CI server, we want to sponsor one server where build the POC and later where test this integrations
(03:19:25) interopen1: from your experience, any suggestions?
(03:19:32) interopen1: we have several options:
(03:19:54) interopen1: 1. In our office in China, but we can have problems with speed on international access
(03:20:00) interopen1: 2. In our office in Spain
(03:20:10) CarlosRuiz: [ about call for Issue Manager -> good ]
(03:20:15) interopen1: 3. Have it in the cloud or one ISP
(03:20:45) hengsin: Isn't metas already have one CI server ? can we just reuse that ?
(03:21:06) CarlosRuiz: Ivan, CI server is mostly to pull?
(03:21:19) interopen1: for me is not a problem, just not find any documentation about it
(03:21:35) interopen1: we want to integrate CI with testing
(03:21:46) hengsin: carlos, build and testing
(03:21:51) interopen1: i mean, first is integrated and later tested, all manage with Hudson
(03:22:04) CarlosRuiz: I mean - you don't expect lots of visits on that site - so speed must not be a big concern
(03:22:12) interopen1: and if there are errors, email to the developers and go back on the integration
(03:22:24) hengsin: carlos, do you who is in charge for metas ?
(03:22:24) interopen1: yes, i not expect much visits
(03:22:34) interopen1: is more i think the processor power
(03:22:42) interopen1: we have some servers with quite a lot
(03:23:12) CarlosRuiz: hengsin: I think is Mark
(03:23:39) CarlosRuiz: I think it's more important at this stage the server close to you
(03:24:20) interopen1: ok, that is an important point
(03:25:11) hengsin: ok, agree.
(03:25:29) interopen1: anyway if you can contact Mark, or he can read in the forums and contribute, we can see the options
(03:25:56) interopen1: for now we can focus on build a server here, and build the POC on it
(03:26:20) interopen1: we can publish as we go so others can review and comment
(03:26:33) interopen1: about the code base we use the trunk?
(03:27:22) CarlosRuiz: for me it will be great if hudson can monitor both - trunk and release
(03:28:20) interopen1: yes, about that i want to talk in part 3.
(03:28:32) CarlosRuiz: but if not possible - or too much work - then trunk is ok for me
(03:28:44) interopen1: but to start with? until now we have base on trunk but things have change last months
(03:29:08) interopen1: the work is the same once you have it working with one, the other one is just a copy
(03:29:33) hengsin: lets start with release
(03:29:42) hengsin: at the end, we should monitor both if possible
(03:30:54) interopen1: release have the advantage that is more control the bug solving
(03:30:58) CarlosRuiz: Ivan - trunk is experimental now - until now it's very close to release - but that cannot be guaranteed in future - a big experiment in trunk can make hard to integrate with release (specially using svn)
(03:31:51) interopen1: we can base on release for now then and see how it develops
(03:32:11) CarlosRuiz: ok
(03:32:12) interopen1: That lead us to point 3.
(03:32:38) interopen1: i see there was some discussion last week about trunk and release versions
(03:33:12) interopen1: and i think as we move forward in QA with the CI testing server there should be less distance between them
(03:34:10) interopen1: for example: if trunk is integrated and tested every night and there is an error with the test, is easy notify developers about it and revert it that same day
(03:34:25) interopen1: if those errors are found later on, is difficult to integrate
(03:34:45) interopen1: and again people will focus on using trunk instead of release version
(03:35:52) interopen1: that lead to problems as this one http://sourceforge.net/projects/adempiere/forums/forum/610547/topic/3583085
(03:35:52) hengsin: Ivan, I can't see why this doesn't need further discussion, we will release from /release, period.
(03:36:17) hengsin: sorry, typo, I means can't see why this need further discussion
(03:36:30) CarlosRuiz: Ivan, that's a different problem - is about backporting to previous releases
(03:36:58) interopen1: ok, so there will be only realeses form /release
(03:37:06) hengsin: yes
(03:37:13) interopen1: ok, then, i didn't had that clear before
(03:37:44) interopen1: so then our main focus on testing should be on release
(03:37:49) CarlosRuiz: if you replace the word "trunk" with "experimental" the meaning of the phrase change a lot
(03:38:12) interopen1: if we want to test a new functionality we can integrate release with the new branck in trunk and apply the test
(03:38:23) interopen1: so this way we not need to ever test the trunk?
(03:38:58) interopen1: yes, more clear we should stop to name it "trunk" and call it "experimental"
(03:39:01) interopen1: i will do it...
(03:39:34) hengsin: Ivan, it is good to have CI for trunk too, the more service for developer, the better
(03:39:59) hengsin: unless it is cost prohibitive, we should do it.
(03:40:22) interopen1: it should not, but will not be close monitor
(03:40:30) interopen1: only a service that notify
(03:40:52) interopen1: for example that this test that work well on release version don't work on experimental
(03:41:13) hengsin: Ivan, I don't thinks that matter
(03:41:50) interopen1: my worries are that if there is a distance between experimental and release, test will not work on release and developers need to create double test
(03:41:57) interopen1: and they will be willing to do it?
(03:43:44) interopen1: but if we force them, that everytime they want to release a new functionality they have in experimental or they have in a branch in order to go into release need to include a test
(03:44:04) interopen1: that we need to test integrating the branch in release and later test it
(03:44:54) CarlosRuiz: the most important is to guarantee quality of releases / that's the main goal
(03:44:54) CarlosRuiz: so - QA on /release is the most needed I guess
(03:44:54) CarlosRuiz: now - as Heng Sin said - if we can make QA on experimental trunk (or in any other important branch) that will be great as a service for the developer
(03:44:54) interopen1: but if they make the test for experimental+branch and it works, may be conflict for them to integrate it with release?
(03:45:17) hengsin: Ivan, a simple rules here will be it have to pass all the test on trunk before integration to release
(03:45:53) hengsin: same goes for integrating any other branch, that way at least we will have a stable reference point
(03:46:13) CarlosRuiz: good topic - with mercurial we'll have many branches
(03:46:19) hengsin: and can easyly analyse the problem if new issues come up after the integration to release
(03:46:53) interopen1: yes, but my worries are if developers not want to modify or write the tests for release, or there is conflict on it
(03:46:57) CarlosRuiz: we want a workflow to pass always via trunk? or we can integrate directly from a branch to release if QA passed
(03:47:15) interopen1: in this topic the idea was to clarify some concepts so i can try to write a basic rules
(03:47:44) interopen1: Carlos: yes that is a good point...
(03:47:47) hengsin: carlos, I guess we can be flexible here, as long as it pass all the test and a credible person do the pull into release, it should be ok
(03:47:55) hengsin: just like the linux model
(03:48:06) interopen1: with a CI testing server the second option brach to release is possible
(03:48:36) CarlosRuiz: yep - I prefer that also
(03:49:07) hengsin: Ivan, one important point - we should be able to run the CI test on any branch with minimum effort, if needed.
(03:49:44) interopen1: yes, i was thinking we can follow a similar model as the patch system Adempiere have
(03:50:13) hengsin: and people with their own branch, public or local, can pull the test suite anytime and run it on their branch
(03:50:21) interopen1: Those who want to test a new functionality or branch can add it to a folder in svn and the CI can integrate it with release and test it
(03:50:34) interopen1: adding also the test of the new functionality
(03:50:43) interopen1: in a separate test from the release CI and test
(03:51:30) interopen1: we can focus first on do it for release, later release + branch
(03:51:51) interopen1: and once that working if resources do it for experimental and experimental+branch
(03:52:09) interopen1: so total 4 integrations, 2+2
(03:53:54) hengsin: Ivan, I guess is more on doing it in structure, reusable way and we can apply it use it with any branch
(03:53:54) interopen1: and all of them notify to those developers who commit since the last integration and to the adempiere developer list
(03:54:10) satyag [~satyag@115.119.21.231] entered the channel.
(03:54:34) interopen1: yes, the problem can be server resources and control over it
(03:54:58) interopen1: if all works perfect is ok, but there will be always errors and things to maintain and improve
(03:55:23) interopen1: and if lot of integrations, everyday or not everyday but without central control, it can be not easy to manage
(03:56:26) CarlosRuiz: reusable is the key as Heng Sin pointed
(03:56:35) hengsin: Ivan, we should have a folder on SF to hold the hudson configuration file and the functional test script
(03:57:04) hengsin: at anytime, people can that take and run it on any server, we don't really have to worry on that part if it is well documented.
(03:57:08) interopen1: yes, of course
(03:57:29) CarlosRuiz: for example I would like to test Localization Colombia extension, firstly check all core QA pass (it doesn't break anything in core) - and then conduct some specific Colombian additional tests
(03:57:35) interopen1: ok i understand your meaning now, those developers who want to integrate it in home and test it
(03:57:42) CarlosRuiz: I guess for that the best would be to allow me to set up my own CI server
(03:58:17) interopen1: yes, that is a good idea for local testing
(03:58:44) interopen1: but we also need a central testing, as what you test may conflict with other integrations
(03:59:10) interopen1: we plan to document it all and have the code in the svn server, all open
(03:59:20) CarlosRuiz: good
(03:59:23) hengsin: yeah, sounds good
(04:00:09) interopen1: this way others also can review it, contribute it and test it... no other way to improve it :-)
(04:01:18) interopen1: ok, then for me are quite clear the 3 points, thanks for the help and comments
(04:01:37) interopen1: if there is any other question or topics? we continue with the roadmap
(04:02:17) interopen1: and have a meeting next week
(04:02:34) CarlosRuiz: for me it's ok - we can finish now
(04:02:44) hengsin: bye Ivan, c u next week
(04:02:51) CarlosRuiz: thanks a lot Ivan
(04:02:59) CarlosRuiz: thanks Heng Sin
(04:03:41) interopen1: bye Heng Sin and Carlos and thanks both
(04:04:00) CarlosRuiz: bye everybody
