apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pramod Immaneni <pra...@datatorrent.com>
Subject Re: [DISCUSS] inactive PR
Date Sun, 01 Oct 2017 06:13:25 GMT
Sorry sent from a different email..

On Sun, Oct 1, 2017 at 8:11 AM, Lakshmi Velineni <lakshmi@datatorrent.com>
wrote:

> I was thinking it would be better to update guidelines first as it gives a
> little bit of heads up.
>
> On Thu, Sep 28, 2017 at 5:52 PM, Vlad Rozov <vrozov@apache.org> wrote:
>
> > Hi Pramod,
> >
> > Do you mean that guidelines needs to be updated first? I don't see why it
> > is necessary. Guidelines is for future PRs. For any existing open PR I
> > asked to provide objections (with justification) on this thread. If there
> > are no objections, I'll close all inactive PRs during this weekend.
> >
> > Thank you,
> >
> > Vlad
> >
> >
> > On 9/27/17 20:05, Pramod Immaneni wrote:
> >
> >> It should be ok in my opinion to close the currently open inactive PRs
> >> that
> >> fall into that category once we have the guidelines updated.
> >>
> >> On Wed, Sep 27, 2017 at 9:52 AM, Vlad Rozov <vrozov@apache.org> wrote:
> >>
> >> Based on the discussion I'll update contributor/committer guidelines to
> >>>
> >>> 1. ask a contributor to close PR when (s)he is not ready to work on it
> in
> >>> a timely manner
> >>> 2. allow committers to close inactive PR after 2 month of inactivity
> >>>
> >>> Any objections to closing existing (currently open) PRs that are
> inactive
> >>> for 2 month?
> >>>
> >>> Thank you,
> >>>
> >>> Vlad
> >>>
> >>>
> >>> On 9/24/17 21:19, Vlad Rozov wrote:
> >>>
> >>> Assuming that a contributor tries to open new PR using the same remote
> >>>> branch as the original PR instead of re-opening closed PR, github
> >>>> provides
> >>>> a notification reminding that one already exists, so I don't see why
> >>>> people
> >>>> will generally miss the old PR.
> >>>>
> >>>> The only case where closed PR can't be re-open is when the original
> >>>> (remote) branch was deleted and re-created or after a forced push to
> the
> >>>> original remote branch (that github can't distinguish from deleted and
> >>>> re-created branch). Would you agree that a forced push for a PR that
> was
> >>>> inactive for a significant period of time should be avoided as it will
> >>>> be
> >>>> impossible for reviewers to recollect comments without ability to see
> >>>> the
> >>>> old patch they (comments) apply to?
> >>>>
> >>>> Thank you,
> >>>>
> >>>> Vlad
> >>>>
> >>>> On 9/24/17 15:27, Pramod Immaneni 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