On 19 Nov 12:12, Mathias Behrle wrote: > * Cédric Krier: " Re: [tryton-dev] Faster contribution" (Wed, 19 Nov 2014 > 11:27:25 +0100): > > > On 19 Nov 09:48, LAG Robin Baumgartner wrote: > > > On 18.11.2014 22:39, Cédric Krier wrote: > > > > If we apply this patch the contribution guide could be reduced for > > > > simple fix to: > > > > > > > > $ hg clone http://hg.tryton.org/trytond > > > > $ cd trytond; vi … > > > > $ curl -o ~/.local/bin/upload.py > > > > http://codereview.tryton.org/static/upload.py $ python > > > > ~/.local/bin/upload.py > > > > > > I don't quite see the benefit for the contributor, that looks exactly > > > like the current workflow for creating a code review. > > > > He doesn't need any more to: > > > > - commit the changeset > > - export the changeset into a patch > > - attach the patch to an issue > > > > After some talks with people complaining about the current workflow, it > > was this part that was the most difficult for them when doing a small > > contribution. > > Perhaps this could be a step in the right direction, but I agree with Robin, > that this is still much too cumbersome for newcomers or random contributors. > > The main feature from the easy contribution setup on github is, that the user > can just directly edit the file in question and then push the button. All > other > stuff happens behind the scenes. > > I will try to specify here a list of requirements, that can serve as a layout > for a solution (being of more or less importance as a matter of course). I > would like them to be discussed and amended. > > - The user should get the file presented ready for edition (currently he has > to do a lot of steps, before he can edit). > > - The user should see his/her changes immediately (currently the > unexperienced user sees his beautified diff after upload). > > - The user should be able to submit the changes in a simple way (by just > pushing > a button, evtl. running one command).
I don't have any solution for this and I don't really think we should try. If such unexperienced user find a such easy thing to fix by just editing remotely the source file, this means it is nothing more than just a typo in a label. If this user find it, it is in the UI not in the source code. So having all this machinery will not help him to find where to make the change. And for a little bit more experienced user, I think making a clone of the repository is not so difficult. > - 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. > - 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. > 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. > - Until now there was a requirement to attach each review to a bug. How is > this > made with this setup? It is not required expect if a core dev think an issue need a bug report. > - Who will be in charge of closing the review? Until now we have the guideline > to close reviews after commit. The author could do it but we could add this right to the core dev and so when he import the patch he can close the review. But closing review is not really an important thing. > - Who will be in charge of doing the commit? Do we need a set of > release/contribution managers? core dev. > - How shall it be differentiated, if a review will be submitted/pushed to > trunk > automatically or by the review owner himself? core dev know each others so as they are the only one who can push a patch, they will not push a patch of another core dev. > - It should at least exist an additional field for the mail address. Since we > are (still) tied to google for authentication, you don't want necessarily > take the google registered address for the commit message. Use a google account for your preferred email address. I think it is the best way to do it as this will ensure we will have a valid address. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpJeYvpsDYpA.pgp
Description: PGP signature
