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. > > https://bugs.tryton.org/issue2177 > > I think, that no one took it is rather a sign of limited resources than not > being it an issue. Which raises oviously the question: why shouldn't we use an > external infrastructure, where we get all this for free? That's why we were two (Bertrand and Me) we choose to host on an external infrastructure which is Google appengine. And so now people complains that they don't want to contribute because it is external and in the same ask to move to another external provider. > 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. > - 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. > - we nevertheless would be masters of our infrastructure and such completely > independet > - this would just be an additional way to get into contact with and > contribute to the project doing no harm in keeping all current procedures > alive So it means we change nothing. > > > > > Additional open questions for me with the proposed setup: > > > > > > > > > > - Until now I am missing the procedure, how the review gets into > > > > > trunk. > > > > > > > > One core dev has to take it. > > > > > > That doesn't explain, how the procedure should work. > > > > A core dev will take a patch and push it. > > As contributor you don't have to care of any of this. > > As long as this will be in the following way, this could save work for all of > us: > > - Lets get an additional field for the commit message (or misuse the current > description for it). The final commit message including bug and review tags > should go into it. Already there, it is the description of the review (see any of my reviews as example). > - Core dev could integrate the patch with hg import directly. That's the goal, less steps. > which would save all this export and attaching to bugs work. Exactly. > > > 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. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpMQgLNWXeTP.pgp
Description: PGP signature
