On 11/20, Cédric Krier wrote: > On 20 Nov 11:35, Mathias Behrle wrote: > > * Cédric Krier: " Re: [tryton-dev] Faster contribution" (Wed, 19 Nov 2014 > > 15:24:40 +0100): > > > > > On 19 Nov 14:59, Mathias Behrle wrote: > > > > * Cédric Krier: " Re: [tryton-dev] Faster contribution" (Wed, 19 Nov > > > > 2014 > > > > 12:44:15 +0100): > > > > > > > > > On 19 Nov 12:12, Mathias Behrle wrote: > > > > > > * Cédric Krier: " Re: [tryton-dev] Faster contribution" (Wed, 19 Nov > > > > > > 2014 11:27:25 +0100): > > > > > > - It should still be possible to track issues and reviews in the > > > > > > commit > > > > > > message. > > > > > > > > > > review is appended to the patch. > > > > > issue depends if the submitter add it or not. > > > > > > > > So this is dropped as a requirement? > > > > > > It will depend of the issue. > > > If the contributor will only provide a patch for an issue core > > > developers find it needs one, it will be requested as comment. > > > > > > > > > - It should be possible to use a specified name and email address > > > > > > for > > > > > > the commit message. > > > > > > > > > > Such contributor will have to use their preferred email address to > > > > > login > > > > > in rietveld. And they will have to set their real name. > > > > > > > > I doubt that will work. Not everyone wants to register every address > > > > (and > > > > especially addresses for this usage) at Google. > > > > > > That's another topic. The move from appspot to self hosting is there > > > since more than 3 years and nobody ever takes any steps, so we can guess > > > it is not really an issue. > > > > It seems to be an issue, even for the usage of appspot itself. If I > > understood > > correctly, Sharoon stated at TUL, that it is impossible for him to > > participate > > on reviews, because there are conflicts between mail adresses. Of course it > > would be best, if he would jump into this discussion to explain exactly the > > matter. > > That's a petty to have problems and not report them. I will not fix > issues for people who don't take the time to explain it.
Here is the patch [1] with which I fixed the issue (I mentioned as a typo which I took forever to send because of the workflow). The 'typo' fixed is not a simple documentation change, it is broken functionality introduced in March 25th, 2012 [2] by Cedric in version 2.4. Thanks to the flexibility of Tryton, this was fixed by our override of the stock module in every version, till I finally decided to go through the pain of sending that upstream patch, which was then applied to all the versions before it. The two conclusions from here: 1. A simpler workflow is **not** just for casual contributors 2. One line patches can fix more than documentation > > As I already stated at TUL, I am not a big fan of making global players to > > monopolists by reinforcing them in getting dependent from them. > > Nevertheless I > > would appreciate a lot a solution, that takes the best from the two worlds: > > > > If we could get away by using github just as a frontend, from which we pipe > > all > > requests to the project owned infrastructure > > - we had a very comfortable interface for easy contributions > > And a bad workflow, big developers don't follow the github workflow like > the Linux kernel, the golang project etc. I agree, may be it does not work for "big developers", the problem we are trying to address is to be big. To compare: 1. Linux has 481,865 commits by 4,357 contributors 2. Go Lang has 20,910 commits by 375 contributors (and 48 committers) 3. Trytond has 4,644 commits by 30 contributors (3602 by cedk) [3] So the problem we want to have is to have a big community and then we will have the resources to have our own infrastructure. Having the contributors rise from 30 is the goal of moving to Github. > > > - we would be more known and better reachable, because github is just what > > it > > is: a huge place of code and coders > > We already are on github thanks to the mirror of sharoon, so it doesn't > change on this topic. Having the mirror proves the point that it is better to have our source on github and to develop there. Having mirrors there already helps people get access to the code and read code, and search code, but not contribute. In comparison, the tryton-documentation project (hosted on github) has 104 commits and 19 contributors from the last 1 year. In comparison to other tryton modules this is much more, but perhaps contributing to documentation is easier than contributing to code, but I am pretty confident that we would not have had as many contributions if the documentation was elsewhere. None of the patches were merged without review and several pull requests were even rejected. Considering the fact that Tryton had no user documentation before this which received contributions (even on a shared google doc), I consider this proof enough to argue that github makes it easier for contributors. > > > > I found another point to add: > > > > > > > > - It should be able to work on a tree of repos (this being a feature of > > > > the > > > > current setup and not being possible on github AFAIK). > > > > > > Such cases are for big changes (so out of cusual contributor) and we > > > already have a good workflow for that for the core developers. > > > > Of course. But the subject is about 'Faster contribution', not only for > > casual > > contributots. > > Large contribution can not be faster and I don't want it to be faster. > Take your time is a quality and it is the main reason of Tryton's code > quality. I have proved with the example above that even a one-line patch is important and how the current workflow discouraged developers at Openlabs from sending a patch for over 4 major versions. I think I have spent a lot of time on this conversation about moving to Git and Github. There are a lot of people who agree and several who disagree, but for different reasons. I completely understand the reasons of Github being a propreitary platform and we already discussed how we could mitigate those risks. To conclude (no sarcasm and no sense of humor): The Tryton community could spend its infinite resources in developing a free and stable operating system and a programming language and a code review tool and a VCS to develop Tryton, or could spend its time in developing a good ERP with tools which make it easier. For me it is Git and Github which lets me maintain multiple versions for our customers, deliver them solutions faster and easier. If others are interested in seeing how we leverage git and github at Openlabs, there is a blog [3] about it. (Ignore the parts of rietveld as we dont use it after Github made their review process better [4-7]) [1] https://github.com/tryton/stock/commit/8828ca228e4f6d4e7e0e517c4f19de455c7b6649 [2] https://github.com/tryton/stock/commit/80fc96b7b0cb557760ae47a7a01deaca2f310c36 [3] http://engineering.openlabs.co.in/post/72769621921/tryton-development-workflow-at-openlabs [4] https://github.com/blog/785-pull-request-diff-comments [5] https://github.com/blog/1885-better-word-highlighting-in-diffs [6] https://github.com/blog/1884-introducing-split-diffs Thanks & Regards Sharoon Thomas Openlabs Technologies & Consulting (P) Limited github.com/sharoonthomas
