Idempiere Weekly Meetings

In http://red1.org/adempiere/viewtopic.php?f=28&t=1482#p7154 Carlos Ruiz announced weekly informal meetings for idempiere community. Here I want to document what comes out of this regarding to me and the FreiBier project.

2012-01-18

full transscript: http://red1.org/adempiere/viewtopic.php?f=32&t=1491

my own, shortened version:

Jan 18 14:07:27 <CarlosRuiz>	this meeting doesn't have a specific agenda - as is our first meeting I would prefer to exploit it to solve your questions
 
Jan 18 14:14:30 <CarlosRuiz>	>  How can we start working & using iDempiere ?
Jan 18 14:14:38 <CarlosRuiz>	I saw Azzam request on red1 forums
Jan 18 14:15:07 <CarlosRuiz>	hengsin and dominik (banym) have published interesting tutorials about how to configure idempiere on eclipse
Jan 18 14:15:27 <CarlosRuiz>	but Azzam asked that he wanted the before and after parts
Jan 18 14:15:43 <CarlosRuiz>	so I tried to expand that in my wiki
Jan 18 14:15:45 <CarlosRuiz>	http://www.globalqss.com/wiki/index.php/IDempiere
Jan 18 14:16:16 <CarlosRuiz>	starting with prerequisites installation - and explaining the after part - how to install and run
Jan 18 14:16:37 <CarlosRuiz>	please feel free to comment on that or request further information
Jan 18 14:17:53 <Azzam>	Thanks Calos I can see contents of documents :)

Jan 18 14:19:20 <hengsin>	carlos, the current postgresql seed in iDempiere is up to date ?
Jan 18 14:19:38 <CarlosRuiz>	yes hengsin
Jan 18 14:19:40 <CarlosRuiz>	>  I missed a clear documentation "from zero to idempiere" too. I had problems initializing the database.
Jan 18 14:19:56 <CarlosRuiz>	precisely I saw Thomas struggling with applying the migration scripts
Jan 18 14:20:03 <CarlosRuiz>	so I committed an updated seed past week
Jan 18 14:20:13 <CarlosRuiz>	is ready now for an initial preview release
Jan 18 14:20:18 <CarlosRuiz>	both seeds - postgresql and oracle

Jan 18 14:21:36 <CarlosRuiz>	> Can we expect a release for iDempiere ?
Jan 18 14:21:42 <CarlosRuiz>	yes Azzam, we're working on it
Jan 18 14:21:58 <CarlosRuiz>	I tried last week and found that installers are having some problems

Jan 18 14:22:21 <Javier_SETSOFTWA>	what is the safest path to migrate to IDempiere from ADempiere 361? When can we start to using it in a production enviroment?
Jan 18 14:22:41 <CarlosRuiz>	I think hengsin is working on those problems (please hengsin correct me if I'm wrong)
Jan 18 14:23:06 <CarlosRuiz>	so, after solved I'll try to do an initial preview release

Jan 18 14:23:32 <CarlosRuiz>	> Or is there a roadmap for idempiere ?
Jan 18 14:23:37 <red1>	as i written in OSGI_Hengsin in the .com wiki.. i found the DB instance same (at that time)
Jan 18 14:23:47 <CarlosRuiz>	hengsin has a proposed roadmap
Jan 18 14:25:43 <hengsin>	I guess we can start setting some time line and then what we can fit into it. for e.g, 1.0 at about 3 month from now and then another release 6/9 month after that.
Jan 18 14:25:44 <CarlosRuiz>	I used to call the roadmap a wishlist - but hengsin roadmap is guiding about where we want to be later - so I think is a good route guide
Jan 18 14:25:45 <red1>	which is QA for iDempiere under Jenkins stack
Jan 18 14:26:28 <CarlosRuiz>	yes, I like hengsin idea
Jan 18 14:26:49 <CarlosRuiz>	we can make a preview release - and take 3 months to stabilize it and release the 1.0

Jan 18 14:27:22 <CarlosRuiz>	> How can I ( we ) contribute in iDempiere  ?
Jan 18 14:27:59 <CarlosRuiz>	* reporting bugs
Jan 18 14:28:05 <CarlosRuiz>	* bringing ideas
Jan 18 14:28:08 <CarlosRuiz>	* spreading the word
Jan 18 14:28:14 <CarlosRuiz>	* Suggesting functional specifications
Jan 18 14:28:18 <CarlosRuiz>	* Contributing code for functional specifications
Jan 18 14:28:24 <CarlosRuiz>	* Contributing sponsorship for approved functional specifications or technical/architectural improvements
Jan 18 14:28:36 <hengsin>	beside some bug fixes and enhancement, the other thing in my mind at this point is to streamline the 1.0 release with a reasonable integration story line and do a zk6 upgrade after 1.0

Jan 18 14:32:37 <CarlosRuiz>	Thomas question now:
Jan 18 14:32:40 <CarlosRuiz>	> In some weeks I will want to commit code. At the moment I work with globalqss361. Which base is stable and a good base to commit code?
Jan 18 14:33:34 <CarlosRuiz>	I migrated globalqss361 branch to bitbucket - so, kenai is not maintained anymore (I put a notice in kenai homepage)
Jan 18 14:33:49 <CarlosRuiz>	globalqss361 is "semi-public"
Jan 18 14:33:54 <CarlosRuiz>	I mean
Jan 18 14:34:36 <CarlosRuiz>	I'm providing access to code on bitbucket globalqss361 on request
Jan 18 14:34:57 <CarlosRuiz>	I adviced in forums that you write me showing some karma points  ;-)    and you'll get access
Jan 18 14:35:25 <tbayen>	So if I can access bitbucket my contributions will go to idempiere without hassles? Thanks for the answer!
Jan 18 14:35:29 <CarlosRuiz>	I want to clarify that the idea is not to privatize - but to encourage contributions

Jan 18 14:39:49 <CarlosRuiz>	Thomas asked > So if I can access bitbucket my contributions will go to idempiere without hassles? Thanks for the answer!
Jan 18 14:40:29 <CarlosRuiz>	for a contribution to arrive to globalqss361 and/or idempiere - there is a peer review process
Jan 18 14:40:41 <CarlosRuiz>	so, if the peer review process passes, yes, it will arrive there
Jan 18 14:41:01 <CarlosRuiz>	if not - we'll let you know the why for you to fix it and try again

Jan 18 14:41:40 <CarlosRuiz>	Javier asked > what is the safest path to migrate to IDempiere from ADempiere 361? When can we start to using it in a production enviroment?
Jan 18 14:42:04 <CarlosRuiz>	from globalqss361 to idempiere the db migration will be easy - just applying migration scripts as always
Jan 18 14:42:29 <CarlosRuiz>	code migration is a different thing - we'll try to document what is needed for that
Jan 18 14:42:38 <red1>	am i correct to say that migration is basically the same as prior all this time?
Jan 18 14:42:51 <CarlosRuiz>	anyways, callouts and model validators and all the stuff we're used to is backward compatible
Jan 18 14:43:06 <CarlosRuiz>	just that the way of putting within the jars will probably vary
Jan 18 14:43:08 <red1>	just that there seems to be a forking point with 361
Jan 18 14:43:55 <CarlosRuiz>	red1 - yes for db migration - for code migration it can be a little different
Jan 18 14:44:00 <hengsin>	if you don't modify model classes (MOrder, MInvoice, etc) then it will be straightforward

Jan 18 14:44:54 <CarlosRuiz>	Thomas asked > If I understand right you would recommend 361 for my production system. Does it make sense for me to do clean commits to this branch or which way of contributing makes least work for you?
Jan 18 14:45:29 <CarlosRuiz>	I'm using globalqss361 in several installations, and I keep fixing the problems found and reported there
Jan 18 14:45:53 <CarlosRuiz>	as always - to "recommend" it for production depends on the scope of your project
Jan 18 14:46:17 <CarlosRuiz>	but I would say that yes - this is the only version I trust at this moment - of course this is a BIASED statement - so please don't blame me for that   :-D
Jan 18 14:46:43 <hengsin>	at this point, 361 or idempiere 1.0 depends more on the timeline of your project.

Jan 18 14:47:24 <CarlosRuiz>	I would like to explain something else
Jan 18 14:47:32 <CarlosRuiz>	how do we want to manage the "commit permissions"
Jan 18 14:48:02 <CarlosRuiz>	somebody asked me here where is the "community repository" (meaning where is the repository where "community" can commit)
Jan 18 14:48:15 <CarlosRuiz>	and that's something that we want to manage different on this project
Jan 18 14:48:33 <CarlosRuiz>	instead of having a trunk with permissions assigned (as we did in adempiere subversion)
Jan 18 14:49:00 <CarlosRuiz>	we want to have a "circles of trust" model like linux - empowered by distributed version control system (DVCS) at this moment mercurial
Jan 18 14:49:11 <CarlosRuiz>	mercurial is a tool to fork
Jan 18 14:49:17 <CarlosRuiz>	so you don't need to ask us for commit permissions
Jan 18 14:49:22 <CarlosRuiz>	you simply fork the project
Jan 18 14:49:37 <CarlosRuiz>	start making your changes - and then let us know for our peer review
Jan 18 14:50:21 <hengsin>	for bitbucket, you can clone globalqss361, make your changes and then send in a pull request
Jan 18 14:50:26 <CarlosRuiz>	via "pull requests" on bitbucket - or via publishing the patch somewhere
Jan 18 14:50:28 <CarlosRuiz>	exactly

Jan 18 14:51:08 <tbayen>	Perhaps we should document some standard procedures for beginners to do an own fork and to keep it synchronized with another "fork of trust". I would like to do this.
Jan 18 14:51:59 <CarlosRuiz>	exactly Thomas - what is expected is to have "circles of trust" - in linux that works very well to manage thousands of developers
Jan 18 14:52:31 <hengsin>	http://confluence.atlassian.com/display/BITBUCKET/Forking+a+bitbucket+Repository
Jan 18 14:53:32 <CarlosRuiz>	I tried to document some baby steps here http://www.globalqss.com/wiki/index.php/IDempiere/Download_the_Code
Jan 18 14:53:43 <CarlosRuiz>	but is still very poor documentation
Jan 18 14:53:39 <red1>	 tbayen at the moment i.e. Carlos trust Hengsin… and you trust Carlos.. so that is how you work
Jan 18 14:54:29 <red1>	if you wish to push code to Carlos… you may not get thru because Carlos does not trust you (yet)
Jan 18 14:55:18 <tbayen>	I just read about pull requests. Seems there is nothing more to document - just do it. Sorry for being stupid.
Jan 18 14:56:23 <red1>	yes tbayen .. only when you wish to push, then you have to push to those Carlos trust.. i.e. Hengsin.. or those Hengsin trust… and so on.. you can read the 'Circle of Trust by Linus"
Jan 18 14:56:28 <tbayen>	red1, I Carlos never has to trust me. I do a pull request, he reads it, makes a decision and uses it or not, right?
Jan 18 14:56:45 <red1>	yes tbayen

Jan 18 14:51:17 <hengsin>	it will be great if we have a gerrit like system ....
Jan 18 14:52:14 <egonzalez_ergio>	Hi: I have a question about distributed version control system: Why mercurial instead GIT?
Jan 18 14:54:15 <CarlosRuiz>	hengsin - sorry didn't understand the term "gerrit like system"
Jan 18 14:54:49 <hengsin>	see this for e.g - http://review.cyanogenmod.com/#change,11848 :)
Jan 18 14:55:34 <CarlosRuiz>	thanks hengsin for the link - I got the idea
Jan 18 14:55:36 <hengsin>	gerrit is only for git though, not sure there's something equivalent for mercury ...
Jan 18 14:55:50 <CarlosRuiz>	ok, to answer Emiliano
Jan 18 14:56:07 <CarlosRuiz>	mercurial was chosen before because it was better supported on eclipse and linux/windows/mac
Jan 18 14:56:18 <CarlosRuiz>	seems like situation have changed now
Jan 18 14:56:39 <hengsin>	lol, I'm actually supporter of git :)
Jan 18 14:57:16 <CarlosRuiz>	I'm not against moving to git if that's what developers prefer
Jan 18 14:57:26 <CarlosRuiz>	I haven't played with git - but I'm ready to learn   :-)
Jan 18 14:57:29 <red1>	Carlos or anyone may apply own discretion whether to subject you to more review or just blind acceptance (based on high trust)
Jan 18 14:57:53 <hengsin>	carlos, unless we want to use gerrit, it is of not much gain otherwise - better just stay as it is.
Jan 18 14:58:02 <red1>	there is much disfavour from users about mercurial
Jan 18 14:58:33 <hengsin>	ah .. one more benefit there - buckminster only support git and svn at the moment!
Jan 18 14:59:25 <CarlosRuiz>	something I read when I was doing the review is that mercurial was better than git on keeping history of moved files - not sure if that's true
Jan 18 15:01:11 <red1>	Dominik banym has cursed mercurial in front of me when i was in his office… for the huge disk size it needs to transfer thru the bandwidth.. and it takes a long time
Jan 18 15:02:07 <CarlosRuiz>	I don't think is a problem from mercurial - I guess a git full repository must be similar in size - is more about the adempiere big history