IRC logs of #tryton for Thursday, 2013-11-14

chat.freenode.net #tryton log beginning Thu Nov 14 00:00:02 CET 2013
-!- anotherUser(~Kroll@smtp.prm-ag.de) has left #tryton10:48
cedksharoonthomas: did you try to clone with uncompressed ?10:49
sharoonthomascedk: i use the git mirror from github ;)11:06
pokolisharoonthomas: you know where is the modules dir when installing using https://gist.github.com/sharoonthomas/5857450 ??11:19
sharoonthomaspokoli: nope, system site packages i assume11:20
sharoonthomaspokoli: do you install from debian packages ? we always create a virtualenv and pip11:21
pokolisharoonthomas: I run always from source :P It's for a user asking on the spanish mailing list. He used your gist to install it and now he doesn't know where the modules dir is11:22
sharoonthomaspokoli: ah ok!11:22
Piloucedk: it seems that one mail I wrote is stuck in the moderation queue of tryton-fr mailing list.11:25
cedkPilou: please fix your email configuration, the spf record doesn't match your sending path11:31
Pilouerf i use another smtp server - ipv6 compatible - this time11:32
cedkPilou: wrong SPF record: https://groups.google.com/forum/#!original/tryton-fr/UvRrzehVmHU/xSzSL0R-2PYJ11:33
cedksharoonthomas: clone trytond from github: 22s; from hg.tryton.org: 9s14:03
sharoonthomas@cedk: clone from hg.tryton.org and you get data from 1 version and you get all versions of tryton till date (from across the big pond) :D14:05
cedksharoonthomas: switching from 1 to an other cost much more than cd14:05
sharoonthomascedk: not really, 2.8 and 3.0 code bases are almost the same. If i just want to back port something14:06
sharoonthomasgit checkout 2.814:06
sharoonthomasgit cherry-pick commit-sha14:06
sharoonthomasand i have the code in the next version14:06
cedksharoonthomas: clone both branch is still faster on hg.tryton.org than on github14:07
sharoonthomascedk: we don't you put git on the same server and check ?14:08
cedksharoonthomas: anyway, branching is not a argument because same feature exist in hg14:10
sharoonthomascedk: yes, if you make tryton code available in multiple branches on same repo, I am game with it.... it solves my primary concern14:11
sharoonthomasACTION is happy béchamel is not in the room14:14
cedksharoonthomas: I see only problems with namedbranches14:15
cedkindeed there is just one: usage of graft instead of transplant14:19
sharoonthomascedk: can it be used between branches (in hg) ?14:23
cedksharoonthomas: transplant works with namedbranch and branch14:24
cedksharoonthomas: while graft only works with namedbranch14:24
cedkbut graft use a better resolution algo for conflict than transplant14:24
sharoonthomascedk: why is branching such a mess in hg ? I really wish it was better.14:25
cedksharoonthomas: how can you say it is a mess, it is just like git !!!14:27
cedkthe only change I see that could be an improvement is to use namedbranch but it should be study carefully because it is a non-return change14:33
cedkI thought I was the only one doing cherry-picking and the current workflow is good enough for me14:34
cedkACTION waiting arguments14:36
jeancavalloACTION eats pop-corn14:38
sharoonthomasACTION is held up on a phone call he did not want to be in 14:50
cedkACTION bbl14:51
sharoonthomasback15:11
sharoonthomascedk: its a mess because mercurial to work everyday needs a whole bunch of extension which hardly use the data model and each one breaks the other... while getting something complex done in git is a matter of using some git commands together15:12
jeancavallocedk: sharoonthomas: I read an interesting article comparing git and mercurial : http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/15:38
sharoonthomasjeancavallo: reading15:38
jeancavallosharoonthomas: It's a little old, but I found it rather accurate15:41
sharoonthomasjeancavallo: i think the major change since the article is that there is the the "git" command wrapper which now wraps all the other commands15:41
jeancavallosharoonthomas: Indeed. But that does not add / remove functionality, just make them easier to use15:43
sharoonthomasjeancavallo: exactly15:43
sharoonthomasjeancavallo: really nice article15:49
pokolisharoonthomas: another point in favor of git: With git branches there is no need of appling multiple patches when a review requires another review to work.16:01
sharoonthomaspokoli: true16:38
sharoonthomaspokoli: at openlabs, there could be multiple features and fixes (read patches) being developed by the developer at the same time and sent for review. With git they have branches for each such task and can keep fixing issues from reviews and finally squash and send a single patch (as pull request )16:39
giedriuspokoli: good point. I find it paintful to work with multiple reviews on single module(repo) with hg.16:42
pokolisharoonthomas: giedrius: and also working in different patches for the same repo is easier with branches than with hg review16:47
cedkany of those things can not be done with hg16:56
cedkand any way, it is bad to work on a changesets that needs something not yet finishe16:57
giedriuspokoli: yep, i find it quite unproductive compared with git+github pull request approach16:58
giedriuspokoli: i mean hg review approach16:58
cedkgiedrius: I will never accept post commit review16:58
cedkthe goal is not to push fast but to push right16:59
giedriuscedk: implementation/bugfixing can be done in branches and later these commits can be squashed to single commit and applied on upstream branch17:00
pokoligiedrius: +117:00
giedriuscedk: this is how its done with git17:00
cedkgiedrius: do what you want on your local machine17:00
cedkgiedrius: I don't care17:01
giedriuscedk: basically, commit on these branches equals the updates on reviews17:01
pokolicedk: with PR aproach you can also the run the test suite automatically (with travis.ci) on all changeset of the review17:01
cedkgiedrius: as far as you submit review base on trunk17:01
cedkpokoli: what is PR ?17:01
pokolicedk: sorry pull request17:01
cedkpokoli: with review also17:02
cedkpokoli: I don't want to rely on private company stuff for the Tryton development so travis is out17:02
cedkpokoli: we have already too much issue with google app engine17:02
cedkand migration to our own hosting is a so long running/waiting task17:03
pokolicedk: you can do it on your house with post-commit-hook17:03
pokolicedk: and there are also github opensource alternatives, and you can host in your house17:04
pokolicedk: maybe git will easy the migration from google app engine :P17:04
cedkpokoli: what the point ?17:04
giedriuscedk: why tryton is not using code hosting services such as bitbucket.com?17:05
cedkpokoli: I think you don't know what you are talking about17:05
cedkgiedrius: because when it is free -> you are the product17:05
pokolicedk: I'm sure you can migrate the codereview tool17:05
pokolicedk: maybe not the mailing list, but they aren't a big problem for me17:06
cedkgiedrius: depending on private company service is a sword of Damocles17:06
cedkpokoli: I know we can but nobody does it17:06
pokolicedk: i understand your point17:07
lidsthere is gitprep as a free clone of github.. i never tried it yet though17:09
cedkwhat is the point to get something like that?17:10
lidsease the developper iirc17:10
lidsworkflow*17:10
lidss/iirc/from what i understand of this discussion/ :)17:11
cedklids: it sounds like push request vs review17:11
cedkbut as I said the goal is to have correct push not ease push17:12
giedriuscedk: relaying on propietary services is more teorical risk than real, especially for code hosting. They don't own your repos and you can easiely migrate to other services if needed17:12
lidsit's just an argument in favor of git..17:12
yangoon1a little bit unrelated, but there is also gitorious: https://gitorious.org/about , which runs under AGPL17:14
lidscedk: i'm think the overhead of contributing to tryton would be much lower with git, ie. it wouldn't require to use third party hg module or a hand-made module do to the review17:14
lidsas for the correctness, it would be the same17:14
pokolilids: and more people is used to git also17:14
cedkgiedrius: what a cost to migrate17:15
cedklids: how ?17:15
cedkpokoli: not a valid point17:15
lidspokoli: true17:16
cedkpokoli: more people use windows, openerp, eclipse17:16
giedriusyangoon1: also rhodecode in GPL3, supports hg and git17:16
pokoliACTION feels embrassed after cedk arguments17:17
lidscedk: how what ?17:17
cedklids: how do you get the same workflow with git which is lower overhead?17:18
cedkFYI, I think the best workflow is the Python one17:21
cedkwe just miss the self-hosting of rietveld to achieve it17:21
lidsah, as i said, installing an hg extension and reading about its features takes time.. and learning the tryton developpement workflow as well because it involves a few tools, while this same workflow is the standard using git's pull-request17:21
cedklids: not it is not the same: post-commit vs pre-commit review17:23
cedkhow do you do with your git repo once you have to fix your commit because of bad review?17:27
lidsit's only a matter of how pull-request are seen, of course no code gets into tryton's trunk/master before any review is done17:27
cedklids: any way, what will be the workflow?17:28
cedkhow do you correct a commit?17:30
yangooncedk: rebasing is rather simple with git17:30
lidsediting commit is standard workflow in git, once it's fixed, it's reproposed to review17:31
cedkyangoon: It sounds like a horrible practice to rebase a published commit17:31
guillemNaNcedk: it's not necessary to rebase nor edit the commit. the patch is developed in a branch. when the branch is merged to 'master' it's done in a single commit (option in the merge command) => the branch can have all the commits that is necessary17:37
yangooncedk: I just answered your question;)17:37
yangoonguillemNaN: which is way of rebasing before merging..., jftr17:38
yangoonnot that I see a problem with that17:39
pokolianyone knows how to debug ProtocolError: 500 Internal error17:41
cedkpokoli: probably you return a non-serialisable object in a rpc callable method17:42
cedkso guys, you want to use emails to review17:42
lidsthat's not really constructive17:43
cedklids: I don't see how you can do other way without publishing commits that will be rewritten17:44
cedkemails is the default review workflow of git17:46
lidswhat do you mean by publishing ? they would be public, but not in the main tree..17:46
cedklids: publishing == make public17:46
lidsthere are project management softwares that handle reviews that are more user-friendly than just a mail-based workflow17:47
pokolicedk: solved! Thanks!17:48
lidsi don't get where is the problem to have current bugfixes and proposed features public17:49
cedklids: you mean Rube Goldberg machines17:50
cedklids: public patches: ok, public repository: wrong17:50
cedklids: I mean public repository with rewritten history17:51
lidswell.. i feel offensed by how you respond, i won't continue17:55
jeancavallopokoli: See the debugging doc, there is a trick for that17:55
Piloujeancavallo: pokoli the error should be improved :-/17:56
jeancavalloPilou: I had a chat with cedk on this, we should look in the client if the Error sent to the client does not contain some kind of traceback17:56
pokolijeancavallo: you mean that part? http://tryton-documentation.readthedocs.org/en/latest/developer_guide/debugging.html#debug-those-annoying-error-20017:57
jeancavallopokoli: Yeah. But I kinda screwed up the error number :'(17:57
Piloujeancavallo: it's not the case17:57
jeancavalloPilou: Thought so17:57
pokolijeancavallo: that was i trying to point. The error number is 500 :P17:57
jeancavallopokoli: changed it17:59
pokolijeancavallo: thank's for fast response :P18:00
jeancavallocedk: I do not understand why the tryton repo history would be rewritten18:01
jeancavallocedk: As long as the patch has not been merged (hopefully once it is valid), there is no trace of it in the repo18:02
jeancavallo(still a git newbie, but that's my understanding)18:02
cedkjeancavallo: if the repo of the merge proposal is not public how do you know about it18:03
Pilousimplejson.scanner.JSONDecodeError are transmitted without traceback (http://hg.tryton.org/tryton/file/9d3812039b97/tryton/common/common.py#l1128 'tb' is not in kwargs)18:03
jeancavalloPilou: :(18:03
jeancavallocedk: The repo is usually a fork of the main repo. It is public, but it is not *the* repo18:04
cedkjeancavallo: any way18:04
jeancavallocedk: For instance, when working on tryton-doc, my working fork is : https://github.com/JCavallo/tryton-documentation18:04
cedkjeancavallo: yes so bad18:05
cedkjeancavallo: one of the reason I hate github (and bitbucket)18:06
jeancavallocedk: Whatever. The point is that the main repo only sees the pull requests and is not polluted with whatever I am doing in my version18:06
cedkjeancavallo: that's not the point18:07
jeancavallocedk: I was just addressing your concern about rewriting history on the main repo :)18:07
cedkjeancavallo: my concern is not about the main repo18:08
breno_we are looking to integrate Django even more tightly that has been done up till now, so that we can take advantage of some niceties (generic views et al) that will really speed up frontend development for us. Thing is, those niceties are really tied to Django's ORM. So what we'd need to do is map Django ORM/queryset to Tryton's. Do you know if any such project has been done before? Probably not with Django but perhaps with other framework?18:29
pokolicedk: I don't understand your point about your hate of github (and bitbucket)18:34
jeancavallopokoli: The point about bitbucket is understandable (and I rather agree)18:34
cedkpokoli: they provide a bad workflow18:34
cedkbad behavior etc.18:34
cedkOne time, I spend 2 hours to find the “original” repository of a project18:35
pokolicedk: normally in github and bitbucket the forks have  a link to the "original" repository18:35
cedkpokoli: also they are 1 author centric18:36
pokolicedk: when you say author you say commiter?18:39
cedk pokoli: I mean owner, just look at the url18:40
jeancavallocedk: https://github.com/tryton :)18:41
jeancavallocedk: But indeed, I think there are special rights for the repo creator18:42
cedkjeancavallo: I think it is just sharoon who created a user named tryton18:43
cedkthe google code hosting is much more correct18:44
jeancavallocedk: Why ? I mean, you obviously have to have a "tryton" account somewhere, isn't it ?18:45
cedkjeancavallo: that's why I say it is single owner centric18:46
cedkjeancavallo: google code hosting is not, you can share with many18:46
cedkjeancavallo: and still have fork repo, push request etc.18:51
-!- hellhound(~hellhound@190.237.15.207) has left #tryton19:30
guillemNaNcedk: in bitbucket (I think in github also) we have a "team account" nantic (and trytonspain) where some authors contribute20:01
guillemNaNcedk: our personal accounts are associated as members of team account, so we inherit the access rights from team account20:02
guillemNaNmy 2 cents. I have to go home :-P see you20:03
breno_cedk: github doesnt have to be single-owner centric, if tryton is really a single user account you can easily convert it to a Github organization account22:42
breno_cedk: it will still be free because those are public repos, and you can configure roles (including several owners)22:42
cedkok, I will put an end to this thread, Tryton will never, never be hosted somewhere else then on a server of the Foundation22:43
breno_that's understandable :-) , I was just commenting on the fact that github repos need to be single owner only22:44
cedkI just see it is not possible to discuss about workflow because people just speak about tools22:45
breno_yeah, don't sweat it, you actually spent time expalining your pov22:48
breno_you should've seen how a discussion like this would've been handled in lkml (linux kernel) mailing list22:49
breno_or the OpenBSD tech mailing list22:50
cedkmy only pending question is just about namedbranch but I see nobody giving a point22:52

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!