apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <vro...@apache.org>
Subject Re: following committer guideline when merging PR
Date Fri, 08 Sep 2017 20:56:07 GMT
I'll repeat myself. Prior to suggesting new process, posting questions 
to dev@apex or voting, please take time to review existing 
documentation, discussion threads and the information posted on 
apex.apache.org.

To answer your question regarding PR 669 - it is the committer 
responsibility to change the status of JIRA and update "Fix version" 
once PR is merged. If you want to revisit this requirement, please 
provide a justification/reason(s) why and how new process will be better 
than the existing one.

Thank you,

Vlad

On 9/8/17 13:21, Sanjay Pujare wrote:
> May be you can help clear the confusion for me. From the contribution
> guidelines you cited, it looks like it is already the contributor's
> responsibility to ensure all JIRA fields are correct and update them when
> the PR is merged.
>
> But in your original email you cited apex-malhar PR 669 as an example where
> the committer overlooked this responsibility. What am I missing?
>
> On Fri, Sep 8, 2017 at 1:01 PM, Vlad Rozov <vrozov@apache.org> wrote:
>
>> Sanjay,
>>
>> Please feel free to propose changes to the existing Apex contribution
>> guidelines, but prior to doing that I'd strongly recommend all community
>> members at least to review what already exists and to follow the guidelines
>> [1]. Additionally, it will be good that the community members understand
>> how Apache Apex contribution and release processes work, and not simply
>> engage in voting without engaging into discussion and following existing
>> guidelines. All this is an indication that except for few individuals the
>> community is not mature and independent.
>>
>> Thank you,
>>
>> Vlad
>>
>> [1] http://apex.apache.org/contributing.html
>>
>> "Before starting work, have a JIRA assigned to yourself. If you want to
>> work on a ticket that is assigned to someone else, send a courtesy e-mail
>> to the assignee to check if you can take it over. Confirm type, priority
>> and other JIRA fields (often default values are not the best fit)."
>>
>> On 9/8/17 11:37, Sanjay Pujare wrote:
>>
>>> Regarding updating JIRA (item#3) I think it should ideally be the
>>> contributor's responsibility to update the JIRA with all the required
>>> fields and not the committer's.
>>>
>>> On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov <v.rozov64@gmail.com> wrote:
>>>
>>> item #3. The concern with #661 is with all items that I marked in red in
>>>> my first email.
>>>>
>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>> On 9/8/17 10:48, Pramod Immaneni wrote:
>>>>
>>>> What's your concern with #669. It's a fix for a build issue (which you
>>>>> created) and was approved by two committers. Wasn't getting builds to
>>>>> successful state asap one of your top concerns based on your comments
>>>>> and
>>>>> -1 on #569 on core.
>>>>>
>>>>> On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov <v.rozov64@gmail.com>
wrote:
>>>>>
>>>>> Committers,
>>>>>
>>>>>> Please make sure to follow Apex community guideline when merging
PR
>>>>>> http://apex.apache.org/contributing.html.
>>>>>>
>>>>>> 1. Ensure that basic requirements for a pull request are met. This
>>>>>>       includes:
>>>>>>         * Sufficient time has passed for others to review
>>>>>>         * PR was suffiently reviewed and comments were addressed.
>>>>>>           Seevoting policy <https://www.apache.org/founda
>>>>>> tion/voting.html
>>>>>>
>>>>>>> .
>>>>>>>
>>>>>>         * When there are multiple reviewers, wait till other reviewers
>>>>>>           approve, with timeout of 48 hours before merging
>>>>>>         * /If the PR was open for a long time, email dev@ declaring
>>>>>> intent
>>>>>>           to merge/
>>>>>>         * Commit messages and PR title need to reference JIRA (pull
>>>>>>           requests will be linked to ticket)
>>>>>>         * /Travis CI and Jenkins pull request build needs to pass/
>>>>>>         * /Ensure tests are added/modified for new features or fixes/
>>>>>>         * Ensure appropriate JavaDoc comments have been added
>>>>>>         * Verify contributions don't depend on incompatible licences
>>>>>>           (seehttps://www.apache.org/legal/resolved.html#category-x)
>>>>>> 2. Use the github/rebase and merge/option or the git command line
to
>>>>>>       merge the pull request (see link|view command line options|on
the
>>>>>> PR).
>>>>>> 3. /Update JIRA after pushing the changes. Set the////|Fix
>>>>>>       version|////field and resolve the JIRA with proper resolution.
>>>>>> *Also
>>>>>>       verify that other fields (type, priority, assignee) are correct*./
>>>>>>
>>>>>>
>>>>>> A couple of recent PR merges (#661, #669) to apex-malhar require
a
>>>>>> second
>>>>>> look from the committers.
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Vlad
>>>>>>
>>>>>>
>>>>>>


Mime
View raw message