On 20 Nov 15:45, Sharoon Thomas wrote: > 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
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.
> > > 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.
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.
> > > - 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.
What proof?
> Having mirrors there already helps
> people get access to the code and read code, and search code, but not
> contribute.
Of course, spreading the code is always better.
You can also mirror it on bitbucket, google code, source forge,
codeplex.
But contribution needs a clear unique path where consensus can be find
on changes and this path should fit the needs of the developers.
> 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.
This stil proofs nothing indeed I think it is the contrario there are
too few contribution for such project. Looking at the graph it looks
like a dead project (most of contributions are from last year).
> > > > > 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.
Shame on Openlabs.
> 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.
> 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
- Pull requests require the contributor to create a public fork of
the repository they're committing to
- 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.
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).
--
Cédric Krier - B2CK SPRL
Email/Jabber: [email protected]
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
pgp6fL6s2Yab2.pgp
Description: PGP signature
