On 19 September 2015 at 17:36, Riccardo Iaconelli <[email protected]> wrote: > On Saturday, September 19, 2015 04:26:04 PM Luigi Toscano wrote: >> But that's not using the pull request. Such workflow would mean that the >> pull request is not accepted anyway, but the code is pushed through the >> infrastructure and not trough Github interface. >> >> Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please >> explain exactly what is the meaning of "use Github"? Do we all agree that in >> any way pull requests will never be merged directly through Github >> interface? > > Personally speaking, yes, they will never be merged directly through Github. > > Github mirrors should be read-only, accepting pull requests (or maybe we > should call them "fetch requests") shouldn't make them read-write.
Yes, freedom-wise these are like *.patch attachments in gmail e-mails. (I repeat this maybe third time?) @All Let me show the steps I am taking as a maintainer: 1. I get an email with *.patch attachments, it can be raw email or a notification from system such as github 2. I am briefly looking at the contents and decide what next 3a. If the patch comes from a first time contributor and it's worth reviewing I submit it for review in the official infra or asking a fellow contributor to do that; if not, I am gently replying to the author about reasoning and further possible steps 3b. If the patch comes from a next time contributor and it's worth reviewing I am gently asking if she would like to consider a shorter path, what is close to asking for joining KDE but in a more gentle manner 4. From now on normal KDE review process happens and if the code is accepted it lands in the read-write repo, not in the mirror. It's clear from the first minute because the project description in the GitHub mirror says so. Sometimes *popular* projects are silently forked in GitHub. People are in hurry so this happens and it's still better than keeping the patches private. In this case if I find usable code this extra step is needed: 0. Extract the patch(es) on my own from the forked repo and contact the author to come into agreement about upstream merge. In *no* step above I am attempting to patronize potential contributors based on their different tool set, skills, etc. I am also aware that in general *no bot* can replace me in this duty. I am also assuming the patches that have been created are frequently *side tasks* for the authors and not the ultimate goals. These contacts sometimes start *long-term* contributions and relations. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek _______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
