| chat.freenode.net #tryton log beginning Thu Nov 14 00:00:02 CET 2013 | ||
| 2013-11-14 10:48 -!- anotherUser(~Kroll@smtp.prm-ag.de) has left #tryton | ||
| 2013-11-14 10:49 <cedk> sharoonthomas: did you try to clone with uncompressed ? | ||
| 2013-11-14 11:06 <sharoonthomas> cedk: i use the git mirror from github ;) | ||
| 2013-11-14 11:19 <pokoli> sharoonthomas: you know where is the modules dir when installing using https://gist.github.com/sharoonthomas/5857450 ?? | ||
| 2013-11-14 11:20 <sharoonthomas> pokoli: nope, system site packages i assume | ||
| 2013-11-14 11:21 <sharoonthomas> pokoli: do you install from debian packages ? we always create a virtualenv and pip | ||
| 2013-11-14 11:22 <pokoli> sharoonthomas: 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 is | ||
| 2013-11-14 11:22 <sharoonthomas> pokoli: ah ok! | ||
| 2013-11-14 11:25 <Pilou> cedk: it seems that one mail I wrote is stuck in the moderation queue of tryton-fr mailing list. | ||
| 2013-11-14 11:31 <cedk> Pilou: please fix your email configuration, the spf record doesn't match your sending path | ||
| 2013-11-14 11:32 <Pilou> erf i use another smtp server - ipv6 compatible - this time | ||
| 2013-11-14 11:33 <cedk> Pilou: wrong SPF record: https://groups.google.com/forum/#!original/tryton-fr/UvRrzehVmHU/xSzSL0R-2PYJ | ||
| 2013-11-14 14:03 <cedk> sharoonthomas: clone trytond from github: 22s; from hg.tryton.org: 9s | ||
| 2013-11-14 14:05 <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) :D | ||
| 2013-11-14 14:05 <cedk> sharoonthomas: switching from 1 to an other cost much more than cd | ||
| 2013-11-14 14:06 <sharoonthomas> cedk: not really, 2.8 and 3.0 code bases are almost the same. If i just want to back port something | ||
| 2013-11-14 14:06 <sharoonthomas> git checkout 2.8 | ||
| 2013-11-14 14:06 <sharoonthomas> git cherry-pick commit-sha | ||
| 2013-11-14 14:06 <sharoonthomas> and i have the code in the next version | ||
| 2013-11-14 14:07 <cedk> sharoonthomas: clone both branch is still faster on hg.tryton.org than on github | ||
| 2013-11-14 14:08 <sharoonthomas> cedk: we don't you put git on the same server and check ? | ||
| 2013-11-14 14:10 <cedk> sharoonthomas: anyway, branching is not a argument because same feature exist in hg | ||
| 2013-11-14 14:11 <sharoonthomas> cedk: yes, if you make tryton code available in multiple branches on same repo, I am game with it.... it solves my primary concern | ||
| 2013-11-14 14:14 <sharoonthomas> ACTION is happy béchamel is not in the room | ||
| 2013-11-14 14:15 <cedk> sharoonthomas: I see only problems with namedbranches | ||
| 2013-11-14 14:19 <cedk> indeed there is just one: usage of graft instead of transplant | ||
| 2013-11-14 14:23 <sharoonthomas> cedk: can it be used between branches (in hg) ? | ||
| 2013-11-14 14:24 <cedk> sharoonthomas: transplant works with namedbranch and branch | ||
| 2013-11-14 14:24 <cedk> sharoonthomas: while graft only works with namedbranch | ||
| 2013-11-14 14:24 <cedk> but graft use a better resolution algo for conflict than transplant | ||
| 2013-11-14 14:25 <sharoonthomas> cedk: why is branching such a mess in hg ? I really wish it was better. | ||
| 2013-11-14 14:27 <cedk> sharoonthomas: how can you say it is a mess, it is just like git !!! | ||
| 2013-11-14 14:33 <cedk> the 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 change | ||
| 2013-11-14 14:34 <cedk> I thought I was the only one doing cherry-picking and the current workflow is good enough for me | ||
| 2013-11-14 14:36 <cedk> ACTION waiting arguments | ||
| 2013-11-14 14:38 <jeancavallo> ACTION eats pop-corn | ||
| 2013-11-14 14:50 <sharoonthomas> ACTION is held up on a phone call he did not want to be in | ||
| 2013-11-14 14:51 <cedk> ACTION bbl | ||
| 2013-11-14 15:11 <sharoonthomas> back | ||
| 2013-11-14 15:12 <sharoonthomas> cedk: 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 together | ||
| 2013-11-14 15:38 <jeancavallo> cedk: sharoonthomas: I read an interesting article comparing git and mercurial : http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ | ||
| 2013-11-14 15:38 <sharoonthomas> jeancavallo: reading | ||
| 2013-11-14 15:41 <jeancavallo> sharoonthomas: It's a little old, but I found it rather accurate | ||
| 2013-11-14 15:41 <sharoonthomas> jeancavallo: i think the major change since the article is that there is the the "git" command wrapper which now wraps all the other commands | ||
| 2013-11-14 15:43 <jeancavallo> sharoonthomas: Indeed. But that does not add / remove functionality, just make them easier to use | ||
| 2013-11-14 15:43 <sharoonthomas> jeancavallo: exactly | ||
| 2013-11-14 15:49 <sharoonthomas> jeancavallo: really nice article | ||
| 2013-11-14 16:01 <pokoli> sharoonthomas: 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. | ||
| 2013-11-14 16:38 <sharoonthomas> pokoli: true | ||
| 2013-11-14 16:39 <sharoonthomas> pokoli: 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 ) | ||
| 2013-11-14 16:42 <giedrius> pokoli: good point. I find it paintful to work with multiple reviews on single module(repo) with hg. | ||
| 2013-11-14 16:47 <pokoli> sharoonthomas: giedrius: and also working in different patches for the same repo is easier with branches than with hg review | ||
| 2013-11-14 16:56 <cedk> any of those things can not be done with hg | ||
| 2013-11-14 16:57 <cedk> and any way, it is bad to work on a changesets that needs something not yet finishe | ||
| 2013-11-14 16:58 <giedrius> pokoli: yep, i find it quite unproductive compared with git+github pull request approach | ||
| 2013-11-14 16:58 <giedrius> pokoli: i mean hg review approach | ||
| 2013-11-14 16:58 <cedk> giedrius: I will never accept post commit review | ||
| 2013-11-14 16:59 <cedk> the goal is not to push fast but to push right | ||
| 2013-11-14 17:00 <giedrius> cedk: implementation/bugfixing can be done in branches and later these commits can be squashed to single commit and applied on upstream branch | ||
| 2013-11-14 17:00 <pokoli> giedrius: +1 | ||
| 2013-11-14 17:00 <giedrius> cedk: this is how its done with git | ||
| 2013-11-14 17:00 <cedk> giedrius: do what you want on your local machine | ||
| 2013-11-14 17:01 <cedk> giedrius: I don't care | ||
| 2013-11-14 17:01 <giedrius> cedk: basically, commit on these branches equals the updates on reviews | ||
| 2013-11-14 17:01 <pokoli> cedk: with PR aproach you can also the run the test suite automatically (with travis.ci) on all changeset of the review | ||
| 2013-11-14 17:01 <cedk> giedrius: as far as you submit review base on trunk | ||
| 2013-11-14 17:01 <cedk> pokoli: what is PR ? | ||
| 2013-11-14 17:01 <pokoli> cedk: sorry pull request | ||
| 2013-11-14 17:02 <cedk> pokoli: with review also | ||
| 2013-11-14 17:02 <cedk> pokoli: I don't want to rely on private company stuff for the Tryton development so travis is out | ||
| 2013-11-14 17:02 <cedk> pokoli: we have already too much issue with google app engine | ||
| 2013-11-14 17:03 <cedk> and migration to our own hosting is a so long running/waiting task | ||
| 2013-11-14 17:03 <pokoli> cedk: you can do it on your house with post-commit-hook | ||
| 2013-11-14 17:04 <pokoli> cedk: and there are also github opensource alternatives, and you can host in your house | ||
| 2013-11-14 17:04 <pokoli> cedk: maybe git will easy the migration from google app engine :P | ||
| 2013-11-14 17:04 <cedk> pokoli: what the point ? | ||
| 2013-11-14 17:05 <giedrius> cedk: why tryton is not using code hosting services such as bitbucket.com? | ||
| 2013-11-14 17:05 <cedk> pokoli: I think you don't know what you are talking about | ||
| 2013-11-14 17:05 <cedk> giedrius: because when it is free -> you are the product | ||
| 2013-11-14 17:05 <pokoli> cedk: I'm sure you can migrate the codereview tool | ||
| 2013-11-14 17:06 <pokoli> cedk: maybe not the mailing list, but they aren't a big problem for me | ||
| 2013-11-14 17:06 <cedk> giedrius: depending on private company service is a sword of Damocles | ||
| 2013-11-14 17:06 <cedk> pokoli: I know we can but nobody does it | ||
| 2013-11-14 17:07 <pokoli> cedk: i understand your point | ||
| 2013-11-14 17:09 <lids> there is gitprep as a free clone of github.. i never tried it yet though | ||
| 2013-11-14 17:10 <cedk> what is the point to get something like that? | ||
| 2013-11-14 17:10 <lids> ease the developper iirc | ||
| 2013-11-14 17:10 <lids> workflow* | ||
| 2013-11-14 17:11 <lids> s/iirc/from what i understand of this discussion/ :) | ||
| 2013-11-14 17:11 <cedk> lids: it sounds like push request vs review | ||
| 2013-11-14 17:12 <cedk> but as I said the goal is to have correct push not ease push | ||
| 2013-11-14 17:12 <giedrius> cedk: 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 needed | ||
| 2013-11-14 17:12 <lids> it's just an argument in favor of git.. | ||
| 2013-11-14 17:14 <yangoon1> a little bit unrelated, but there is also gitorious: https://gitorious.org/about , which runs under AGPL | ||
| 2013-11-14 17:14 <lids> cedk: 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 review | ||
| 2013-11-14 17:14 <lids> as for the correctness, it would be the same | ||
| 2013-11-14 17:14 <pokoli> lids: and more people is used to git also | ||
| 2013-11-14 17:15 <cedk> giedrius: what a cost to migrate | ||
| 2013-11-14 17:15 <cedk> lids: how ? | ||
| 2013-11-14 17:15 <cedk> pokoli: not a valid point | ||
| 2013-11-14 17:16 <lids> pokoli: true | ||
| 2013-11-14 17:16 <cedk> pokoli: more people use windows, openerp, eclipse | ||
| 2013-11-14 17:16 <giedrius> yangoon1: also rhodecode in GPL3, supports hg and git | ||
| 2013-11-14 17:17 <pokoli> ACTION feels embrassed after cedk arguments | ||
| 2013-11-14 17:17 <lids> cedk: how what ? | ||
| 2013-11-14 17:18 <cedk> lids: how do you get the same workflow with git which is lower overhead? | ||
| 2013-11-14 17:21 <cedk> FYI, I think the best workflow is the Python one | ||
| 2013-11-14 17:21 <cedk> we just miss the self-hosting of rietveld to achieve it | ||
| 2013-11-14 17:21 <lids> ah, 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-request | ||
| 2013-11-14 17:23 <cedk> lids: not it is not the same: post-commit vs pre-commit review | ||
| 2013-11-14 17:27 <cedk> how do you do with your git repo once you have to fix your commit because of bad review? | ||
| 2013-11-14 17:27 <lids> it's only a matter of how pull-request are seen, of course no code gets into tryton's trunk/master before any review is done | ||
| 2013-11-14 17:28 <cedk> lids: any way, what will be the workflow? | ||
| 2013-11-14 17:30 <cedk> how do you correct a commit? | ||
| 2013-11-14 17:30 <yangoon> cedk: rebasing is rather simple with git | ||
| 2013-11-14 17:31 <lids> editing commit is standard workflow in git, once it's fixed, it's reproposed to review | ||
| 2013-11-14 17:31 <cedk> yangoon: It sounds like a horrible practice to rebase a published commit | ||
| 2013-11-14 17:37 <guillemNaN> cedk: 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 necessary | ||
| 2013-11-14 17:37 <yangoon> cedk: I just answered your question;) | ||
| 2013-11-14 17:38 <yangoon> guillemNaN: which is way of rebasing before merging..., jftr | ||
| 2013-11-14 17:39 <yangoon> not that I see a problem with that | ||
| 2013-11-14 17:41 <pokoli> anyone knows how to debug ProtocolError: 500 Internal error | ||
| 2013-11-14 17:42 <cedk> pokoli: probably you return a non-serialisable object in a rpc callable method | ||
| 2013-11-14 17:42 <cedk> so guys, you want to use emails to review | ||
| 2013-11-14 17:43 <lids> that's not really constructive | ||
| 2013-11-14 17:44 <cedk> lids: I don't see how you can do other way without publishing commits that will be rewritten | ||
| 2013-11-14 17:46 <cedk> emails is the default review workflow of git | ||
| 2013-11-14 17:46 <lids> what do you mean by publishing ? they would be public, but not in the main tree.. | ||
| 2013-11-14 17:46 <cedk> lids: publishing == make public | ||
| 2013-11-14 17:47 <lids> there are project management softwares that handle reviews that are more user-friendly than just a mail-based workflow | ||
| 2013-11-14 17:48 <pokoli> cedk: solved! Thanks! | ||
| 2013-11-14 17:49 <lids> i don't get where is the problem to have current bugfixes and proposed features public | ||
| 2013-11-14 17:50 <cedk> lids: you mean Rube Goldberg machines | ||
| 2013-11-14 17:50 <cedk> lids: public patches: ok, public repository: wrong | ||
| 2013-11-14 17:51 <cedk> lids: I mean public repository with rewritten history | ||
| 2013-11-14 17:55 <lids> well.. i feel offensed by how you respond, i won't continue | ||
| 2013-11-14 17:55 <jeancavallo> pokoli: See the debugging doc, there is a trick for that | ||
| 2013-11-14 17:56 <Pilou> jeancavallo: pokoli the error should be improved :-/ | ||
| 2013-11-14 17:56 <jeancavallo> Pilou: 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 traceback | ||
| 2013-11-14 17:57 <pokoli> jeancavallo: you mean that part? http://tryton-documentation.readthedocs.org/en/latest/developer_guide/debugging.html#debug-those-annoying-error-200 | ||
| 2013-11-14 17:57 <jeancavallo> pokoli: Yeah. But I kinda screwed up the error number :'( | ||
| 2013-11-14 17:57 <Pilou> jeancavallo: it's not the case | ||
| 2013-11-14 17:57 <jeancavallo> Pilou: Thought so | ||
| 2013-11-14 17:57 <pokoli> jeancavallo: that was i trying to point. The error number is 500 :P | ||
| 2013-11-14 17:59 <jeancavallo> pokoli: changed it | ||
| 2013-11-14 18:00 <pokoli> jeancavallo: thank's for fast response :P | ||
| 2013-11-14 18:01 <jeancavallo> cedk: I do not understand why the tryton repo history would be rewritten | ||
| 2013-11-14 18:02 <jeancavallo> cedk: As long as the patch has not been merged (hopefully once it is valid), there is no trace of it in the repo | ||
| 2013-11-14 18:02 <jeancavallo> (still a git newbie, but that's my understanding) | ||
| 2013-11-14 18:03 <cedk> jeancavallo: if the repo of the merge proposal is not public how do you know about it | ||
| 2013-11-14 18:03 <Pilou> simplejson.scanner.JSONDecodeError are transmitted without traceback (http://hg.tryton.org/tryton/file/9d3812039b97/tryton/common/common.py#l1128 'tb' is not in kwargs) | ||
| 2013-11-14 18:03 <jeancavallo> Pilou: :( | ||
| 2013-11-14 18:04 <jeancavallo> cedk: The repo is usually a fork of the main repo. It is public, but it is not *the* repo | ||
| 2013-11-14 18:04 <cedk> jeancavallo: any way | ||
| 2013-11-14 18:04 <jeancavallo> cedk: For instance, when working on tryton-doc, my working fork is : https://github.com/JCavallo/tryton-documentation | ||
| 2013-11-14 18:05 <cedk> jeancavallo: yes so bad | ||
| 2013-11-14 18:06 <cedk> jeancavallo: one of the reason I hate github (and bitbucket) | ||
| 2013-11-14 18:06 <jeancavallo> cedk: Whatever. The point is that the main repo only sees the pull requests and is not polluted with whatever I am doing in my version | ||
| 2013-11-14 18:07 <cedk> jeancavallo: that's not the point | ||
| 2013-11-14 18:07 <jeancavallo> cedk: I was just addressing your concern about rewriting history on the main repo :) | ||
| 2013-11-14 18:08 <cedk> jeancavallo: my concern is not about the main repo | ||
| 2013-11-14 18:29 <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? | ||
| 2013-11-14 18:34 <pokoli> cedk: I don't understand your point about your hate of github (and bitbucket) | ||
| 2013-11-14 18:34 <jeancavallo> pokoli: The point about bitbucket is understandable (and I rather agree) | ||
| 2013-11-14 18:34 <cedk> pokoli: they provide a bad workflow | ||
| 2013-11-14 18:34 <cedk> bad behavior etc. | ||
| 2013-11-14 18:35 <cedk> One time, I spend 2 hours to find the “original” repository of a project | ||
| 2013-11-14 18:35 <pokoli> cedk: normally in github and bitbucket the forks have a link to the "original" repository | ||
| 2013-11-14 18:36 <cedk> pokoli: also they are 1 author centric | ||
| 2013-11-14 18:39 <pokoli> cedk: when you say author you say commiter? | ||
| 2013-11-14 18:40 <cedk> pokoli: I mean owner, just look at the url | ||
| 2013-11-14 18:41 <jeancavallo> cedk: https://github.com/tryton :) | ||
| 2013-11-14 18:42 <jeancavallo> cedk: But indeed, I think there are special rights for the repo creator | ||
| 2013-11-14 18:43 <cedk> jeancavallo: I think it is just sharoon who created a user named tryton | ||
| 2013-11-14 18:44 <cedk> the google code hosting is much more correct | ||
| 2013-11-14 18:45 <jeancavallo> cedk: Why ? I mean, you obviously have to have a "tryton" account somewhere, isn't it ? | ||
| 2013-11-14 18:46 <cedk> jeancavallo: that's why I say it is single owner centric | ||
| 2013-11-14 18:46 <cedk> jeancavallo: google code hosting is not, you can share with many | ||
| 2013-11-14 18:51 <cedk> jeancavallo: and still have fork repo, push request etc. | ||
| 2013-11-14 19:30 -!- hellhound(~hellhound@190.237.15.207) has left #tryton | ||
| 2013-11-14 20:01 <guillemNaN> cedk: in bitbucket (I think in github also) we have a "team account" nantic (and trytonspain) where some authors contribute | ||
| 2013-11-14 20:02 <guillemNaN> cedk: our personal accounts are associated as members of team account, so we inherit the access rights from team account | ||
| 2013-11-14 20:03 <guillemNaN> my 2 cents. I have to go home :-P see you | ||
| 2013-11-14 22:42 <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 account | ||
| 2013-11-14 22:42 <breno_> cedk: it will still be free because those are public repos, and you can configure roles (including several owners) | ||
| 2013-11-14 22:43 <cedk> ok, I will put an end to this thread, Tryton will never, never be hosted somewhere else then on a server of the Foundation | ||
| 2013-11-14 22:44 <breno_> that's understandable :-) , I was just commenting on the fact that github repos need to be single owner only | ||
| 2013-11-14 22:45 <cedk> I just see it is not possible to discuss about workflow because people just speak about tools | ||
| 2013-11-14 22:48 <breno_> yeah, don't sweat it, you actually spent time expalining your pov | ||
| 2013-11-14 22:49 <breno_> you should've seen how a discussion like this would've been handled in lkml (linux kernel) mailing list | ||
| 2013-11-14 22:50 <breno_> or the OpenBSD tech mailing list | ||
| 2013-11-14 22:52 <cedk> my only pending question is just about namedbranch but I see nobody giving a point |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!