* 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). - It should still be possible to track issues and reviews in the commit message. - It should be possible to use a specified name and email address for the commit message. Additional open questions for me with the proposed setup: - Until now I am missing the procedure, how the review gets into trunk. - Until now there was a requirement to attach each review to a bug. How is this made with this setup? - Who will be in charge of closing the review? Until now we have the guideline to close reviews after commit. - Who will be in charge of doing the commit? Do we need a set of release/contribution managers? - How shall it be differentiated, if a review will be submitted/pushed to trunk automatically or by the review owner himself? - 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. Hope to get into a fruitful discussion, how we can improve the current situation. Cheers, Mathias -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
pgptvpV18mr5J.pgp
Description: Digitale Signatur von OpenPGP
