El 20/11/14 a les 16:45, Sharoon Thomas ha escrit:
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).
I'm pretty sure if the issue had been reported, the issue will be fixed
on the next major version by a core developer and backported earlier :)
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.
For me there are more contribuitions because there is a button on the
docs for editing directly from the docs.
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.
(sarcasm mode on)
So why we must spend time moving to github?
(sarcasm mode off)
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])
Everything can be done with the current tools.
And a bonus question:
How you will manage a review that affects serveral modules (For example
[1]) in github? For me it's important to be able to review a patch that
affects multiple modules (not so strange on tryton) in the same
location, and be able to fetch them with a single command.
[1] http://codereview.tryton.org/13701003/
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
