* Sharoon Thomas [2014-11-20 16:45:43]: > On 11/20, Cédric Krier wrote: > > On 20 Nov 11:35, Mathias Behrle wrote: > > > 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:
Had you taken 5 minutes to submit a bug (not even a patch), the fix would have been in Tryton since 2 years. > 1. A simpler workflow is **not** just for casual contributors Or maybe this example just prove that you are a casual contributor. There is no wrong is "just" being a casual contributor, I can understand that you want to spend all your time on your own projects (nereid, angular-tryton, www.tryton.us, etc) and in the overall they are good for Tryton. > 2. One line patches can fix more than documentation Of course. I don't think anybody ever said the contrary. > > > - 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. I don't understand this paragraph. People are really using google / github to search the tryton code? > 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. Maybe also because editing documentation is easier on github thanks to the web interface. For code, I seriously doubt it still holds. > > > > > 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. For me the example you gave also shows something else. Someone of openlabs chose to fix it on his own, not caring about the community because of the burden that it is to submit a bug. That's a pity. Being part of the community is also caring about others that might be impacted by the bug. > 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. Can we agree that we disagree and let the people that code on this project decide which tools they want to use? Maybe the process can be better for casual contributors but switching the main workforce to something else seems counter-productive. I still appreciate all your marketing efforts for tryton, they are going in the right direction and I absolutely have not issue with the fact that they are developed on github. Also I am sure the users of nereid / angular-tryton / etc are very happy with it. > 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. You're again saying that the coders should switch their workflow to suit yours while you do not contribute that much by code (which does not mean that you don't contribute at all … as I said you contribute in other ways : documentation / marketing / nereid). > (Ignore the parts of rietveld as we dont use it after Github made > their review process better [4-7]) But still does not support nested repositories which is something we need. -- Nicolas Évrard - B2CK SPRL E-mail/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
signature.asc
Description: signature
