* 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): > > > > > 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. I completely agree, that for bigger contributions the user will be more experienced anyway. Nevertheless a fast and easy contribution process will help those experienced users, too. > > - 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 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. > > 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. > > - 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. I think this could be another quite substantial barrier for contribution at all. 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). -- 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
pgpTgUnkv0yTx.pgp
Description: Digitale Signatur von OpenPGP
