apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Priyanka Gugale <pri...@apache.org>
Subject Re: [DISCUSS] inactive PR
Date Mon, 25 Sep 2017 04:26:09 GMT
Hi,

I am okay with closing inactive PR but timeline should be more than a
month. I have been in situations where for some reason or other the PR was
pending for 2-3 months, sometimes reason was simple as relevant committer
didn't have time to review that time. I will vote for 3 months.

-Priyanka

On Mon, Sep 25, 2017 at 6:29 AM, Amol Kekre <amol@datatorrent.com> wrote:

> I am +1 on closing inactive PRs. Time wise 1 month looks short, 3 months
> looks long to me. In either case I do not have strong opinion on the time
> side; so I am 0+ on either.
>
> Thks,
> Amol
>
>
>
> E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
>
> www.datatorrent.com
>
>
> On Sun, Sep 24, 2017 at 3:27 PM, Pramod Immaneni <pramod@datatorrent.com>
> wrote:
>
> > If PR is open, the previous comments are available in the same context as
> > new discussions. There is no need to remember to go back to a previous
> > closed PR to figure out what was discussed or what is outstanding. People
> > will generally miss the old PR and will either not reopen it or will go
> > through it, so its possible previous reviewers concerns would be lost.
> Also
> > I don’t think three months is not an unreasonable time to leave PRs open,
> > two could work.
> >
> > > On Sep 24, 2017, at 2:56 PM, Vlad Rozov <vrozov@apache.org> wrote:
> > >
> > > If a PR is closed due to inactivity and a contributor fails to remember
> > that he/she open a PR in the past, what is the chance that a committer
> can
> > recollect what was discussed on a PR (whether it stays open or is closed)
> > that was inactive for 2-3 month :)? IMO, we should try to optimize
> process
> > for good community members (those who follow contributor guidelines) and
> > not those who do not follow.
> > >
> > > Thank you,
> > >
> > > Vlad
> > >
> > > On 9/24/17 09:29, Pramod Immaneni wrote:
> > >>> On Sep 24, 2017, at 9:21 AM, Thomas Weise <thw@apache.org> wrote:
> > >>>
> > >>> On Sun, Sep 24, 2017 at 9:08 AM, Pramod Immaneni <
> > pramod@datatorrent.com <mailto:pramod@datatorrent.com>>
> > >>> wrote:
> > >>>
> > >>>>> On Sep 24, 2017, at 8:28 AM, Thomas Weise <thw@apache.org>
wrote:
> > >>>>>
> > >>>>> +1 for closing inactive PRs after documented period of inactivity
> > >>>>> (contributor guidelines)
> > >>>>>
> > >>>>> There is nothing "draconian" or negative about closing a PR,
it is
> a
> > >>>>> function that github provides that should be used to improve
> > >>>> collaboration.
> > >>>>> PR is a review tool, it is not good to have stale or abandoned
PRs
> > >>>> sitting
> > >>>>> as open. When there is no activity on a PR and it is waiting
for
> > action
> > >>>> by
> > >>>>> the contributor (not ready for review), it should be closed
and
> then
> > >>>>> re-opened once the contributor was able to move it forward
and it
> > becomes
> > >>>>> ready for review.
> > >>>>>
> > >>>>> Thomas
> > >>>> Please refer to my email again, I am not against closing PR if
there
> > is
> > >>>> inactivity. My issue is with the time period. In reality, most
> people
> > will
> > >>>> create new PRs instead of reopening old ones and the old
> > context/comments
> > >>>> will be forgotten and not addressed.
> > >>>>
> > >>>>
> > >>> Why will contributors open new PRs even in cases where changes are
> > >>> requested on an open PR? Because it is not documented or reviewers
> > don't
> > >>> encourage the proper process? We should solve that problem.
> > >> In cases where PR was closed due to inactivity and the contributor
> > comes back later to work on it, they are likely going to create a new PR
> as
> > opposed to finding the closed one and reopening it. The guidelines can
> > include proper process but most likely this is one of those things that
> > will require checking on the committers part.
> > >>
> > >>
> > >
> >
> >
>

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