Am 20.11.2014 18:59, schrieb Simon: > > Am 20.11.2014 um 17:36 schrieb Cédric Krier: >> >>> 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 >> I think you are just showing to the world how you don't care so much >> about Tryton and the community. You prefered create 4 modules than >> submitting a patch which is as simple as: >> >> $ git clone http://github.com/tryton/stock >> $ vim ... >> $ upload.py >> >> I think you are also showing that you are the partisan here, with >> behaviors like always use github.com links (despite I proof you that >> hg.tryton.org was faster) or not using the bugtracker or hg.tryton.org. >> In contrary, we are open by still working and talking with such >> behavior or even allowing you to submit patches from git. > > Please excuse me for shouting: > contenance! > > it's the interface and things like 'blame' that really do make a > difference for posted links > (i tried hard to find the same file on http://hg.tryton.org/ but i > failed - shame on me) > >>> 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. >> No, theyr refusal of the github workflow is not based on the number of >> contributors. It is based on the workflow only (that what makes good >> software). Hundreds of monkeys typing are still less efficient than >> one human. > In a small company i talk to my boss , in a big concern i have to file > 10 forms instead. each bureaucracy fits its needs... (hopefuly) > > [...] >> >>> 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. >> Shame on Openlabs. > contenance :) >> >>> 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. >> The strange thing is that almost all core developpers don't want to >> move. I think it is better to let the people who really *contribute* >> decide what is the best instead of those who don't. > > with salt and pepper and some irony one could say that this is self > fulfilling prophecy ;) > >> >>> 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. >> Really! >> So it seems that you don't understand that the workflow of development >> leads to a good software, not the number of contributors. And clearly >> the github workflow is wrong for many reasons: >> >> - Merging a pull request (almost) always creates a merge commit > whats the downside of this? >> - Pull requests require the contributor to create a public fork of >> the repository they're committing to > Which fulfils the gpl by definition... >> - Comments on pull requests are sent as soon as they are created >> - Rietveld has the notion of multiple 'patch sets' for a particular >> change, and you can see diffs between patch sets, so it's much >> easier to progressively review large changes. > you can use branches and do the same >> >> From https://news.ycombinator.com/item?id=8605204 >> >> Without considering that Tryton has many repositories and that some >> changes require change in all of them which will lead to so many Pull >> Request (that are only available via a web page). >> > If it was so damn wrong, why is it the case that so many projects use > it and even pay for it? > most developers have a github account nowadays, only some use gmail..
Hi all, possibly we should take a look at https://kallithea-scm.org/ - this will change nothing in the workflow and adds some webfront goodies. And I think the simplified way shown by cedrik is enough for me. Jan
