apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amol Kekre <a...@datatorrent.com>
Subject Re: PR merge policy
Date Fri, 24 Mar 2017 21:42:02 GMT
Pramod,
That is a good idea. A timeout will help PR be more efficient.

Thks
Amol


E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com

*Join us at Apex Big Data World Mt View
<http://www.apexbigdata.com/mountain-view.html>, April 4, 2017!*
[image: http://www.apexbigdata.com/san-jose-register.html]
<http://www.apexbigdata.com/san-jose-register.html>

On Fri, Mar 24, 2017 at 11:42 AM, Pramod Immaneni <pramod@datatorrent.com>
wrote:

> For the PR part with multiple reviewers, I suggest we pick a convention
> like the main reviewer has to wait till all the other reviewers say
> something like LGTM or a timeout period like 2 days before merging it. This
> will remove ambiguity, especially in cases where reviewers come in
> later after review has been happening for a while and it is unclear whether
> they have started the review and will have more comments or are just are
> making singular comments. We, of course, do not want to encourage the
> behavior and would prefer interested folks join the review process early
> but in reality, these situations happen.
>
> On Fri, Mar 24, 2017 at 8:38 AM, Thomas Weise <thw@apache.org> wrote:
>
> > +1
> >
> > There are also cases where PRs have been under review by multiple people
> > that are suddenly unilaterally rebased and merged.
> >
> > Furthermore those that review and merge should follow the contributor
> > guidelines (or improve them). For example, JIRAs are supposed to be
> > resolved and marked with the fix version when the PR is merged.
> >
> > Thomas
> >
> >
> >
> >
> >
> >
> > On Thu, Mar 23, 2017 at 12:58 PM, Vlad Rozov <v.rozov@datatorrent.com>
> > wrote:
> >
> > > Lately there were few instances where PR open against apex-core and
> > > apex-malhar were merged just few hours after it being open and JIRA
> being
> > > raised without giving chance for other contributors to review and
> > comment.
> > > I'd suggest that we stop such practice no matter how trivial those
> > changes
> > > are. This equally applies to documentation. In a rear cases where PR is
> > > urgent (for example one that fixes compilation error), I'd suggest
> that a
> > > committer who plans to merge the PR sends an explicit notification to
> > > dev@apex and gives others a reasonable time to respond.
> > >
> > > Thank you,
> > >
> > > Vlad
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message