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..
