[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: [kde-community] Official KDE mirror on github
From:       Jaroslaw Staniek <staniek () kde ! org>
Date:       2015-09-19 17:29:35
Message-ID: CAOj7QQ3dbZ4-zRG6Zk_nErH4BguYRG1RFdDF0EA9RLBxK6YGaQ () mail ! gmail ! com
[Download RAW message or body]

On 19 September 2015 at 17:36, Riccardo Iaconelli <riccardo@kde.org> 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
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
[prev in list] [next in list] [prev in thread] [next in thread]