Closing JIRA Issue for Merged PRs

[Kaxil Naik <ka...@gmail.com>]

Hi Committers,

Please make sure to close the Jira issues if the related PRs are merged.

I am going through the Jira Reports (Image: https://imgur.com/n50Ticx) and
was concerned with the gap between issues created & resolved in recent
months.

However, I noticed while going through the jira issues that most of the PRs
related to the JIRAs have been resolved but the JIRA is not resolved.

Let's try to resolve all the issues when we merge the PR :)

This will help the release manager too.

Regards,
Kaxil

Re: Closing JIRA Issue for Merged PRs

[Kaxil Naik <ka...@gmail.com>]

Yes we do close JIRA issues that are not relevant or the problem mentioned
is already fixed by other issue

On Mon, Nov 18, 2019 at 9:12 PM Sergio Kef <se...@gmail.com> wrote:

> On a slightly irrelevant note, do we ever close tickets as non-reproducable
> or will-not-fix?
> Last time I was going through open tickets I found dozens that seemed
> really old, really not-gonna-happen or already fixed.
> What actions could we take to decrease this gap?
> WDYT?
>
> S.
>
> On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <tomasz.urbaszek@polidea.com
> >
> wrote:
>
> > I can agree that GitHub issues may get spammy but I other projects deal
> > with it somehow. And as a user I like the simplicity of creating an
> issue.
> > As per Jira, I think a good part of it is the ability to link issues
> across
> > different ASF project (but I don't think it's a killer feature).
> >
> > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> wrote:
> >
> > > I don’t like Jira particularly but I like GitHub issues even less. Both
> > > don’t feel right. And yes GitHub issues get spammy very quickly. The
> > hurdle
> > > gets so low that it functions as an alternative to the mailing list,
> far,
> > > and chat.
> > >
> > >
> > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> > wrote:
> > >
> > > Getting creds for Jira might be tricky, though Infra may have some way
> of
> > > resolving issues when PR is merged (please don't Close, only ever
> Resolve
> > > as closed issues can't have FixVersion changed)
> > >
> > > This brings me on to another question: what do were actual use Jira for
> > > that couldn't (or shouldn't) be done with GitHub Issues?
> > >
> > > The main thing I can think of right now is the Fix version when
> resolving
> > > to say when we should backport a PR, but this could be achieved with
> > > Milestones in GitHub.
> > >
> > > (A fringe benefit is that most people won't have an ASF Jira account so
> > > opening issues to ask questions is harder. "Benefit" as it avoids issue
> > > spam for question.)
> > >
> > > Is there anything else?
> > >
> > > -A
> > >
> > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > tomasz.urbaszek@polidea.com> wrote:
> > > >Is there any possibility to use GitHub actions for that?
> > > >For example, the one that allows to "Automatically transition an issue
> > > >to
> > > >done when a pull request whose name contains the issue key is merged"?
> > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > >
> > > >Bests,
> > > >Tomek
> > > >
> > > >
> > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> > > >wrote:
> > > >
> > > >> I wrote that script. It’s cli only unfortunately.
> > > >>
> > > >>
> > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > >(ddavydov@twitter.com.invalid
> > > >> )
> > > >> wrote:
> > > >>
> > > >> Wait this doesn't happen automatically!? I thought way-back-when
> > > >someone
> > > >> wrote a script to automatically close the JIRA tickets (maybe that
> > > >script
> > > >> is not run when changes are merged via the UI). My apologies, will
> > > >close
> > > >> JIRAs in the future, I don't think I've closed any JIRA tickets
> > > >manually.
> > > >>
> > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > ><Ja...@polidea.com>
> > > >> wrote:
> > > >>
> > > >> > And yes. I was one of the culprits - I saw :(. Sorry about that
> > > >Kaxil.
> > > >> > Just hope we can streamline this :).
> > > >> >
> > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > ><Ja...@polidea.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Heartily agree with it !
> > > >> > >
> > > >> > > I try always to close the PRs but sometimes I got distracted and
> > > >forget
> > > >> > to
> > > >> > > resolve an issue - it happend several times that I recalled it
> > > >few
> > > >> hours
> > > >> > > later that I have forgotten to resolve it. I hope it happens
> > > >rarely -
> > > >> I'd
> > > >> > > love to know if I was one of the culprits here :). And whenever
> I
> > > >> noticed
> > > >> > > some of the PRs are not closed but PR is merged by someone else
> -
> > > >I
> > > >> > > sometimes close them. But it's not ideal of course.
> > > >> > >
> > > >> > > However simple it is - I think we are just humans and we will
> > > >forget
> > > >> from
> > > >> > > time to time. I was wondering if we can (yes, you guessed it)
> > > >automate
> > > >> it
> > > >> > > :). Either with JIRA/Github integration or some automated tool
> to
> > > >do it
> > > >> > > regularly and resolving all already merged tickets. And the more
> > > >> > > committers we are going to have, the more it makes sense to
> > > >automate
> > > >> some
> > > >> > > of the work. The less you have to remember about your "chores"
> > > >the more
> > > >> > you
> > > >> > > can focus on the "real" stuff.
> > > >> > >
> > > >> > > I think there are a few unwritten rules that we have - like what
> > > >> version
> > > >> > > to set when we cherry-pick change to 1.10* . My understanding is
> > > >that
> > > >> we
> > > >> > > should set fixed version to the first unreleased yet 1.10.
> > > >version.
> > > >> This
> > > >> > > problem will soon be gone, so maybe it's not worth solving it.
> > > >There
> > > >> are
> > > >> > > also some edge cases like bad fixes which got reverted and
> > > >reapplied
> > > >> but
> > > >> > I
> > > >> > > think other than that the automation of it can be rather simple.
> > > >> > >
> > > >> > > And I think there are some scripts in "dev" that already do some
> > > >of
> > > >> that
> > > >> > -
> > > >> > > synchronising merges with JIRAs (but I don't think it's common
> > > >> knowledge
> > > >> > > and it's not regularly run). Maybe we can improve it somehow and
> > > >have
> > > >> it
> > > >> > > fully automated so that we do not even havet to think about it ?
> > > >> > >
> > > >> > > WDYT? Any ideas?
> > > >> > >
> > > >> > > J.
> > > >> > >
> > > >> > >
> > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <kaxilnaik@gmail.com
> >
> > > >> wrote:
> > > >> > >
> > > >> > >> We have some at
> > > >> > >>
> > > >>
> > > >
> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > >> > >>
> > > >> > >> The person who merges the PR to master is the one who would be
> > > >> > responsible
> > > >> > >> for resolving the JIRA issue as they can add the *target
> > > >version*
> > > >> based
> > > >> > on
> > > >> > >> what they think after reviewing the PR.
> > > >> > >>
> > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > > >> > >> aizhamal@apache.org>
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >> > I think it will be good to document the process. For example,
> > > >who is
> > > >> > >> > responsible for closing Jira issues: folks who closed PR's or
> > > >the
> > > >> ones
> > > >> > >> who
> > > >> > >> > opened?
> > > >> > >> >
> > > >> > >> > If the documentation already exists, let's bring it back to
> > > >> attention.
> > > >> > >> >
> > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > ><ka...@gmail.com>
> > > >> > wrote:
> > > >> > >> >
> > > >> > >> > > Hi Committers,
> > > >> > >> > >
> > > >> > >> > > Please make sure to close the Jira issues if the related
> PRs
> > > >are
> > > >> > >> merged.
> > > >> > >> > >
> > > >> > >> > > I am going through the Jira Reports (Image:
> > > >> > https://imgur.com/n50Ticx
> > > >> > >> )
> > > >> > >> > and
> > > >> > >> > > was concerned with the gap between issues created &
> resolved
> > > >in
> > > >> > recent
> > > >> > >> > > months.
> > > >> > >> > >
> > > >> > >> > > However, I noticed while going through the jira issues that
> > > >most
> > > >> of
> > > >> > >> the
> > > >> > >> > PRs
> > > >> > >> > > related to the JIRAs have been resolved but the JIRA is not
> > > >> > resolved.
> > > >> > >> > >
> > > >> > >> > > Let's try to resolve all the issues when we merge the PR :)
> > > >> > >> > >
> > > >> > >> > > This will help the release manager too.
> > > >> > >> > >
> > > >> > >> > > Regards,
> > > >> > >> > > Kaxil
> > > >> > >> > >
> > > >> > >> >
> > > >> > >>
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > >
> > > >> > > Jarek Potiuk
> > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > >> > >
> > > >> > > M: +48 660 796 129 <+48660796129>
> > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > >> > >
> > > >> > >
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Jarek Potiuk
> > > >> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >> >
> > > >> > M: +48 660 796 129 <+48660796129>
> > > >> > [image: Polidea] <https://www.polidea.com/>
> > > >> >
> > > >>
> > > >
> > > >
> > > >--
> > > >
> > > >Tomasz Urbaszek
> > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > >
> > > >M: +48 505 628 493 <+48505628493>
> > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > >
> > > >Unique Tech
> > > >Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
> >
> > --
> >
> > Tomasz Urbaszek
> > Polidea <https://www.polidea.com/> | Junior Software Engineer
> >
> > M: +48 505 628 493 <+48505628493>
> > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >
> > Unique Tech
> > Check out our projects! <https://www.polidea.com/our-work>
> >
>

Re: Closing JIRA Issue for Merged PRs

[Kaxil Naik <ka...@gmail.com>]

I am all for automation too. For now, I think the priority to build that is
low. Once we have all the items in the Roadmap close to being done, we can
surely get this kind of CLI built.

Regards,
Kaxil

On Mon, Nov 18, 2019 at 10:14 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> Agree that Github issue are nicely integrated with the code, I don't
> particularly mind which issue tracking system I use as long as it has good
> integration.
>
> The nice part about github issues that now with github actions we could
> automate more and have full control over it. And a lot of this works
> automagically (Fixes #NN) closes the issue when merged.
>
> On the other hand It is very limiting. I see it would have been difficult
> to follow the cherry-picking workflow where we decide after the merge if we
> want to cherry-pick or not. Issue can belong to only one milestone - so
> then we'd have to start messing around with labels etc. I don't have
> particularly strong feelings about moving out of JIRA and I think the
> benefits are very small compared to the hassle of changing.
>
> There is a lot of "boring" work in the commiter's live - mostly connected
> with reviewing list of issues in one of the systems (sometimes many times
> over) and reacting somehow. I think it would be much more enjoyable if we
> had - even manually driven -  some automation in place for that. I think
> about a small but well-rounded tool that could help with managing state of
> the several different system we use.
>
> I'd love a small "committer" CLI that we will be able to query the state of
> the issues and use it to perform particular tasks - i.e. checking the list
> of open issues assigned to me, issues that I have recently interacted with,
> issues that are in the area of my interest - viewable and discoverable via
> the CLI, and then manageable from the same CLI. I'd love for example to see
> all the issues that I already merged but they are not resolved yet. Or all
> the issues for which build failed recently but they are likely transient
> rebuilds etc. etc. Something that could be a small (CLI) dashboard for all
> the committers where all the typical use-cases for the committers are
> automated. This way we could not only make our life easier but also we
> could start promoting some good committer practices, and we could introduce
> some more sophisticated strategies for dealing with issues (vs. current
> anyone does anything strategy). For example sharing the issues between
> committers, auto-assigning reviewers etc. etc. Of course this can all be
> done without such tool, but that would be far less fun if those are
> "written down" and "manually followed" processes rather than automated
> ones.
>
> And of course  myself or anyone could develop such tool myself - but it's
> quite an effort and I think it would only pay off if the effort could be
> divided by a number of people contributing, but benefits multiplied by a
> number of people using it :).
>
> As we will have more committers (hopefully) we might have more need for
> such tool. Is this a good time to start thinking about it?
>
> J.
>
> On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com> wrote:
>
> > On a slightly irrelevant note, do we ever close tickets as
> non-reproducable
> > or will-not-fix?
> > Last time I was going through open tickets I found dozens that seemed
> > really old, really not-gonna-happen or already fixed.
> > What actions could we take to decrease this gap?
> > WDYT?
> >
> > S.
> >
> > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com
> > >
> > wrote:
> >
> > > I can agree that GitHub issues may get spammy but I other projects deal
> > > with it somehow. And as a user I like the simplicity of creating an
> > issue.
> > > As per Jira, I think a good part of it is the ability to link issues
> > across
> > > different ASF project (but I don't think it's a killer feature).
> > >
> > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> > wrote:
> > >
> > > > I don’t like Jira particularly but I like GitHub issues even less.
> Both
> > > > don’t feel right. And yes GitHub issues get spammy very quickly. The
> > > hurdle
> > > > gets so low that it functions as an alternative to the mailing list,
> > far,
> > > > and chat.
> > > >
> > > >
> > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> > > wrote:
> > > >
> > > > Getting creds for Jira might be tricky, though Infra may have some
> way
> > of
> > > > resolving issues when PR is merged (please don't Close, only ever
> > Resolve
> > > > as closed issues can't have FixVersion changed)
> > > >
> > > > This brings me on to another question: what do were actual use Jira
> for
> > > > that couldn't (or shouldn't) be done with GitHub Issues?
> > > >
> > > > The main thing I can think of right now is the Fix version when
> > resolving
> > > > to say when we should backport a PR, but this could be achieved with
> > > > Milestones in GitHub.
> > > >
> > > > (A fringe benefit is that most people won't have an ASF Jira account
> so
> > > > opening issues to ask questions is harder. "Benefit" as it avoids
> issue
> > > > spam for question.)
> > > >
> > > > Is there anything else?
> > > >
> > > > -A
> > > >
> > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > > tomasz.urbaszek@polidea.com> wrote:
> > > > >Is there any possibility to use GitHub actions for that?
> > > > >For example, the one that allows to "Automatically transition an
> issue
> > > > >to
> > > > >done when a pull request whose name contains the issue key is
> merged"?
> > > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > > >
> > > > >Bests,
> > > > >Tomek
> > > > >
> > > > >
> > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> > > > >wrote:
> > > > >
> > > > >> I wrote that script. It’s cli only unfortunately.
> > > > >>
> > > > >>
> > > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > > >(ddavydov@twitter.com.invalid
> > > > >> )
> > > > >> wrote:
> > > > >>
> > > > >> Wait this doesn't happen automatically!? I thought way-back-when
> > > > >someone
> > > > >> wrote a script to automatically close the JIRA tickets (maybe that
> > > > >script
> > > > >> is not run when changes are merged via the UI). My apologies, will
> > > > >close
> > > > >> JIRAs in the future, I don't think I've closed any JIRA tickets
> > > > >manually.
> > > > >>
> > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > > ><Ja...@polidea.com>
> > > > >> wrote:
> > > > >>
> > > > >> > And yes. I was one of the culprits - I saw :(. Sorry about that
> > > > >Kaxil.
> > > > >> > Just hope we can streamline this :).
> > > > >> >
> > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > > ><Ja...@polidea.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Heartily agree with it !
> > > > >> > >
> > > > >> > > I try always to close the PRs but sometimes I got distracted
> and
> > > > >forget
> > > > >> > to
> > > > >> > > resolve an issue - it happend several times that I recalled it
> > > > >few
> > > > >> hours
> > > > >> > > later that I have forgotten to resolve it. I hope it happens
> > > > >rarely -
> > > > >> I'd
> > > > >> > > love to know if I was one of the culprits here :). And
> whenever
> > I
> > > > >> noticed
> > > > >> > > some of the PRs are not closed but PR is merged by someone
> else
> > -
> > > > >I
> > > > >> > > sometimes close them. But it's not ideal of course.
> > > > >> > >
> > > > >> > > However simple it is - I think we are just humans and we will
> > > > >forget
> > > > >> from
> > > > >> > > time to time. I was wondering if we can (yes, you guessed it)
> > > > >automate
> > > > >> it
> > > > >> > > :). Either with JIRA/Github integration or some automated tool
> > to
> > > > >do it
> > > > >> > > regularly and resolving all already merged tickets. And the
> more
> > > > >> > > committers we are going to have, the more it makes sense to
> > > > >automate
> > > > >> some
> > > > >> > > of the work. The less you have to remember about your "chores"
> > > > >the more
> > > > >> > you
> > > > >> > > can focus on the "real" stuff.
> > > > >> > >
> > > > >> > > I think there are a few unwritten rules that we have - like
> what
> > > > >> version
> > > > >> > > to set when we cherry-pick change to 1.10* . My understanding
> is
> > > > >that
> > > > >> we
> > > > >> > > should set fixed version to the first unreleased yet 1.10.
> > > > >version.
> > > > >> This
> > > > >> > > problem will soon be gone, so maybe it's not worth solving it.
> > > > >There
> > > > >> are
> > > > >> > > also some edge cases like bad fixes which got reverted and
> > > > >reapplied
> > > > >> but
> > > > >> > I
> > > > >> > > think other than that the automation of it can be rather
> simple.
> > > > >> > >
> > > > >> > > And I think there are some scripts in "dev" that already do
> some
> > > > >of
> > > > >> that
> > > > >> > -
> > > > >> > > synchronising merges with JIRAs (but I don't think it's common
> > > > >> knowledge
> > > > >> > > and it's not regularly run). Maybe we can improve it somehow
> and
> > > > >have
> > > > >> it
> > > > >> > > fully automated so that we do not even havet to think about
> it ?
> > > > >> > >
> > > > >> > > WDYT? Any ideas?
> > > > >> > >
> > > > >> > > J.
> > > > >> > >
> > > > >> > >
> > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <
> kaxilnaik@gmail.com
> > >
> > > > >> wrote:
> > > > >> > >
> > > > >> > >> We have some at
> > > > >> > >>
> > > > >>
> > > > >
> > https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > > >> > >>
> > > > >> > >> The person who merges the PR to master is the one who would
> be
> > > > >> > responsible
> > > > >> > >> for resolving the JIRA issue as they can add the *target
> > > > >version*
> > > > >> based
> > > > >> > on
> > > > >> > >> what they think after reviewing the PR.
> > > > >> > >>
> > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > > > >> > >> aizhamal@apache.org>
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >> > I think it will be good to document the process. For
> example,
> > > > >who is
> > > > >> > >> > responsible for closing Jira issues: folks who closed PR's
> or
> > > > >the
> > > > >> ones
> > > > >> > >> who
> > > > >> > >> > opened?
> > > > >> > >> >
> > > > >> > >> > If the documentation already exists, let's bring it back to
> > > > >> attention.
> > > > >> > >> >
> > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > > ><ka...@gmail.com>
> > > > >> > wrote:
> > > > >> > >> >
> > > > >> > >> > > Hi Committers,
> > > > >> > >> > >
> > > > >> > >> > > Please make sure to close the Jira issues if the related
> > PRs
> > > > >are
> > > > >> > >> merged.
> > > > >> > >> > >
> > > > >> > >> > > I am going through the Jira Reports (Image:
> > > > >> > https://imgur.com/n50Ticx
> > > > >> > >> )
> > > > >> > >> > and
> > > > >> > >> > > was concerned with the gap between issues created &
> > resolved
> > > > >in
> > > > >> > recent
> > > > >> > >> > > months.
> > > > >> > >> > >
> > > > >> > >> > > However, I noticed while going through the jira issues
> that
> > > > >most
> > > > >> of
> > > > >> > >> the
> > > > >> > >> > PRs
> > > > >> > >> > > related to the JIRAs have been resolved but the JIRA is
> not
> > > > >> > resolved.
> > > > >> > >> > >
> > > > >> > >> > > Let's try to resolve all the issues when we merge the PR
> :)
> > > > >> > >> > >
> > > > >> > >> > > This will help the release manager too.
> > > > >> > >> > >
> > > > >> > >> > > Regards,
> > > > >> > >> > > Kaxil
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > >
> > > > >> > > Jarek Potiuk
> > > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > >> > >
> > > > >> > > M: +48 660 796 129 <+48660796129>
> > > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Jarek Potiuk
> > > > >> > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > > >> >
> > > > >> > M: +48 660 796 129 <+48660796129>
> > > > >> > [image: Polidea] <https://www.polidea.com/>
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >--
> > > > >
> > > > >Tomasz Urbaszek
> > > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > >
> > > > >M: +48 505 628 493 <+48505628493>
> > > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > >
> > > > >Unique Tech
> > > > >Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> > >
> > > --
> > >
> > > Tomasz Urbaszek
> > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >
> > > M: +48 505 628 493 <+48505628493>
> > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >
> > > Unique Tech
> > > Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: Closing JIRA Issue for Merged PRs

[Kaxil Naik <ka...@gmail.com>]

Yes, I will roll it own soon once I get some time if anyone doesn't get to
it first.

Have a great weekend all.

On Sat, Nov 30, 2019, 12:08 Jarek Potiuk <Ja...@polidea.com> wrote:

> With the recent asf.yaml change, seems that we are getting to get much
> easier self-maintenance of bot integration from ASF. I am all for adding
> more bot-driven stuff :).
>
> Probot looks absolutely great, especially that it has so many existing
> integrations and we can add our own if needed and contribute it back.
>
> Maybe someone would like to take on the "probot" hat and try to add some
> useful integrations already ?
>
> J.
>
>
> On Wed, Nov 20, 2019 at 8:22 PM Kaxil Naik <ka...@gmail.com> wrote:
>
> > I just used it on my fork and works nicely. Thanks, Max.
> >
> > +1 for probot
> >
> > On Tue, Nov 19, 2019 at 10:55 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > +1 for probot. How about we try it with
> > > https://github.com/cchantep/probot-jira for example?
> > >
> > > On Tue, Nov 19, 2019 at 8:28 PM Daniel Imberman <
> > daniel.imberman@gmail.com
> > > >
> > > wrote:
> > >
> > > > +1 for probot, the k8s community has a pretty slick GitHub automation
> > > > system as well we should look into.
> > > >
> > > > via Newton Mail [
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > ]
> > > > On Tue, Nov 19, 2019 at 2:09 PM, Maxime Beauchemin <
> > > > maximebeauchemin@gmail.com> wrote:
> > > > Quick note as I'm playing with Probot for Superset. It's possible to
> > > catch
> > > > all sorts of Github event and trigger all sorts of side effects with
> > it.
> > > >
> > > > On the Superset side we're looking to enable automation around Github
> > > > comments and labeling. It's also offers potential around enabling
> > people
> > > > (PMs, contributors) without write access to the repo to create
> > > > labels, assign tasks, ...
> > > >
> > > > More about it here:
> > > > https://probot.github.io/
> > > >
> > > > Max
> > > >
> > > > On Mon, Nov 18, 2019 at 2:14 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > > > wrote:
> > > >
> > > > > Agree that Github issue are nicely integrated with the code, I
> don't
> > > > > particularly mind which issue tracking system I use as long as it
> has
> > > > good
> > > > > integration.
> > > > >
> > > > > The nice part about github issues that now with github actions we
> > could
> > > > > automate more and have full control over it. And a lot of this
> works
> > > > > automagically (Fixes #NN) closes the issue when merged.
> > > > >
> > > > > On the other hand It is very limiting. I see it would have been
> > > difficult
> > > > > to follow the cherry-picking workflow where we decide after the
> merge
> > > if
> > > > we
> > > > > want to cherry-pick or not. Issue can belong to only one milestone
> -
> > so
> > > > > then we'd have to start messing around with labels etc. I don't
> have
> > > > > particularly strong feelings about moving out of JIRA and I think
> the
> > > > > benefits are very small compared to the hassle of changing.
> > > > >
> > > > > There is a lot of "boring" work in the commiter's live - mostly
> > > connected
> > > > > with reviewing list of issues in one of the systems (sometimes many
> > > times
> > > > > over) and reacting somehow. I think it would be much more enjoyable
> > if
> > > we
> > > > > had - even manually driven - some automation in place for that. I
> > think
> > > > > about a small but well-rounded tool that could help with managing
> > state
> > > > of
> > > > > the several different system we use.
> > > > >
> > > > > I'd love a small "committer" CLI that we will be able to query the
> > > state
> > > > of
> > > > > the issues and use it to perform particular tasks - i.e. checking
> the
> > > > list
> > > > > of open issues assigned to me, issues that I have recently
> interacted
> > > > with,
> > > > > issues that are in the area of my interest - viewable and
> > discoverable
> > > > via
> > > > > the CLI, and then manageable from the same CLI. I'd love for
> example
> > to
> > > > see
> > > > > all the issues that I already merged but they are not resolved yet.
> > Or
> > > > all
> > > > > the issues for which build failed recently but they are likely
> > > transient
> > > > > rebuilds etc. etc. Something that could be a small (CLI) dashboard
> > for
> > > > all
> > > > > the committers where all the typical use-cases for the committers
> are
> > > > > automated. This way we could not only make our life easier but also
> > we
> > > > > could start promoting some good committer practices, and we could
> > > > introduce
> > > > > some more sophisticated strategies for dealing with issues (vs.
> > current
> > > > > anyone does anything strategy). For example sharing the issues
> > between
> > > > > committers, auto-assigning reviewers etc. etc. Of course this can
> all
> > > be
> > > > > done without such tool, but that would be far less fun if those are
> > > > > "written down" and "manually followed" processes rather than
> > automated
> > > > > ones.
> > > > >
> > > > > And of course myself or anyone could develop such tool myself - but
> > > it's
> > > > > quite an effort and I think it would only pay off if the effort
> could
> > > be
> > > > > divided by a number of people contributing, but benefits multiplied
> > by
> > > a
> > > > > number of people using it :).
> > > > >
> > > > > As we will have more committers (hopefully) we might have more need
> > for
> > > > > such tool. Is this a good time to start thinking about it?
> > > > >
> > > > > J.
> > > > >
> > > > > On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com>
> > > wrote:
> > > > >
> > > > > > On a slightly irrelevant note, do we ever close tickets as
> > > > > non-reproducable
> > > > > > or will-not-fix?
> > > > > > Last time I was going through open tickets I found dozens that
> > seemed
> > > > > > really old, really not-gonna-happen or already fixed.
> > > > > > What actions could we take to decrease this gap?
> > > > > > WDYT?
> > > > > >
> > > > > > S.
> > > > > >
> > > > > > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> > > > > tomasz.urbaszek@polidea.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I can agree that GitHub issues may get spammy but I other
> > projects
> > > > deal
> > > > > > > with it somehow. And as a user I like the simplicity of
> creating
> > an
> > > > > > issue.
> > > > > > > As per Jira, I think a good part of it is the ability to link
> > > issues
> > > > > > across
> > > > > > > different ASF project (but I don't think it's a killer
> feature).
> > > > > > >
> > > > > > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <
> > bdbruin@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > I don’t like Jira particularly but I like GitHub issues even
> > > less.
> > > > > Both
> > > > > > > > don’t feel right. And yes GitHub issues get spammy very
> > quickly.
> > > > The
> > > > > > > hurdle
> > > > > > > > gets so low that it functions as an alternative to the
> mailing
> > > > list,
> > > > > > far,
> > > > > > > > and chat.
> > > > > > > >
> > > > > > > >
> > > > > > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (
> > > ash@apache.org
> > > > )
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Getting creds for Jira might be tricky, though Infra may have
> > > some
> > > > > way
> > > > > > of
> > > > > > > > resolving issues when PR is merged (please don't Close, only
> > ever
> > > > > > Resolve
> > > > > > > > as closed issues can't have FixVersion changed)
> > > > > > > >
> > > > > > > > This brings me on to another question: what do were actual
> use
> > > Jira
> > > > > for
> > > > > > > > that couldn't (or shouldn't) be done with GitHub Issues?
> > > > > > > >
> > > > > > > > The main thing I can think of right now is the Fix version
> when
> > > > > > resolving
> > > > > > > > to say when we should backport a PR, but this could be
> achieved
> > > > with
> > > > > > > > Milestones in GitHub.
> > > > > > > >
> > > > > > > > (A fringe benefit is that most people won't have an ASF Jira
> > > > account
> > > > > so
> > > > > > > > opening issues to ask questions is harder. "Benefit" as it
> > avoids
> > > > > issue
> > > > > > > > spam for question.)
> > > > > > > >
> > > > > > > > Is there anything else?
> > > > > > > >
> > > > > > > > -A
> > > > > > > >
> > > > > > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > >Is there any possibility to use GitHub actions for that?
> > > > > > > > >For example, the one that allows to "Automatically
> transition
> > an
> > > > > issue
> > > > > > > > >to
> > > > > > > > >done when a pull request whose name contains the issue key
> is
> > > > > merged"?
> > > > > > > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > > > > > > >
> > > > > > > > >Bests,
> > > > > > > > >Tomek
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <
> > > bdbruin@gmail.com
> > > > >
> > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > >> I wrote that script. It’s cli only unfortunately.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > > > > > > >(ddavydov@twitter.com.invalid
> > > > > > > > >> )
> > > > > > > > >> wrote:
> > > > > > > > >>
> > > > > > > > >> Wait this doesn't happen automatically!? I thought
> > > way-back-when
> > > > > > > > >someone
> > > > > > > > >> wrote a script to automatically close the JIRA tickets
> > (maybe
> > > > that
> > > > > > > > >script
> > > > > > > > >> is not run when changes are merged via the UI). My
> > apologies,
> > > > will
> > > > > > > > >close
> > > > > > > > >> JIRAs in the future, I don't think I've closed any JIRA
> > > tickets
> > > > > > > > >manually.
> > > > > > > > >>
> > > > > > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > > > > > > ><Ja...@polidea.com>
> > > > > > > > >> wrote:
> > > > > > > > >>
> > > > > > > > >> > And yes. I was one of the culprits - I saw :(. Sorry
> about
> > > > that
> > > > > > > > >Kaxil.
> > > > > > > > >> > Just hope we can streamline this :).
> > > > > > > > >> >
> > > > > > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > > > > > > ><Ja...@polidea.com>
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Heartily agree with it !
> > > > > > > > >> > >
> > > > > > > > >> > > I try always to close the PRs but sometimes I got
> > > distracted
> > > > > and
> > > > > > > > >forget
> > > > > > > > >> > to
> > > > > > > > >> > > resolve an issue - it happend several times that I
> > > recalled
> > > > it
> > > > > > > > >few
> > > > > > > > >> hours
> > > > > > > > >> > > later that I have forgotten to resolve it. I hope it
> > > happens
> > > > > > > > >rarely -
> > > > > > > > >> I'd
> > > > > > > > >> > > love to know if I was one of the culprits here :). And
> > > > > whenever
> > > > > > I
> > > > > > > > >> noticed
> > > > > > > > >> > > some of the PRs are not closed but PR is merged by
> > someone
> > > > > else
> > > > > > -
> > > > > > > > >I
> > > > > > > > >> > > sometimes close them. But it's not ideal of course.
> > > > > > > > >> > >
> > > > > > > > >> > > However simple it is - I think we are just humans and
> we
> > > > will
> > > > > > > > >forget
> > > > > > > > >> from
> > > > > > > > >> > > time to time. I was wondering if we can (yes, you
> > guessed
> > > > it)
> > > > > > > > >automate
> > > > > > > > >> it
> > > > > > > > >> > > :). Either with JIRA/Github integration or some
> > automated
> > > > tool
> > > > > > to
> > > > > > > > >do it
> > > > > > > > >> > > regularly and resolving all already merged tickets.
> And
> > > the
> > > > > more
> > > > > > > > >> > > committers we are going to have, the more it makes
> sense
> > > to
> > > > > > > > >automate
> > > > > > > > >> some
> > > > > > > > >> > > of the work. The less you have to remember about your
> > > > "chores"
> > > > > > > > >the more
> > > > > > > > >> > you
> > > > > > > > >> > > can focus on the "real" stuff.
> > > > > > > > >> > >
> > > > > > > > >> > > I think there are a few unwritten rules that we have -
> > > like
> > > > > what
> > > > > > > > >> version
> > > > > > > > >> > > to set when we cherry-pick change to 1.10* . My
> > > > understanding
> > > > > is
> > > > > > > > >that
> > > > > > > > >> we
> > > > > > > > >> > > should set fixed version to the first unreleased yet
> > 1.10.
> > > > > > > > >version.
> > > > > > > > >> This
> > > > > > > > >> > > problem will soon be gone, so maybe it's not worth
> > solving
> > > > it.
> > > > > > > > >There
> > > > > > > > >> are
> > > > > > > > >> > > also some edge cases like bad fixes which got reverted
> > and
> > > > > > > > >reapplied
> > > > > > > > >> but
> > > > > > > > >> > I
> > > > > > > > >> > > think other than that the automation of it can be
> rather
> > > > > simple.
> > > > > > > > >> > >
> > > > > > > > >> > > And I think there are some scripts in "dev" that
> already
> > > do
> > > > > some
> > > > > > > > >of
> > > > > > > > >> that
> > > > > > > > >> > -
> > > > > > > > >> > > synchronising merges with JIRAs (but I don't think
> it's
> > > > common
> > > > > > > > >> knowledge
> > > > > > > > >> > > and it's not regularly run). Maybe we can improve it
> > > somehow
> > > > > and
> > > > > > > > >have
> > > > > > > > >> it
> > > > > > > > >> > > fully automated so that we do not even havet to think
> > > about
> > > > > it ?
> > > > > > > > >> > >
> > > > > > > > >> > > WDYT? Any ideas?
> > > > > > > > >> > >
> > > > > > > > >> > > J.
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > > > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <
> > > > > kaxilnaik@gmail.com
> > > > > > >
> > > > > > > > >> wrote:
> > > > > > > > >> > >
> > > > > > > > >> > >> We have some at
> > > > > > > > >> > >>
> > > > > > > > >>
> > > > > > > > >
> > > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > > > > > > >> > >>
> > > > > > > > >> > >> The person who merges the PR to master is the one who
> > > would
> > > > > be
> > > > > > > > >> > responsible
> > > > > > > > >> > >> for resolving the JIRA issue as they can add the
> > *target
> > > > > > > > >version*
> > > > > > > > >> based
> > > > > > > > >> > on
> > > > > > > > >> > >> what they think after reviewing the PR.
> > > > > > > > >> > >>
> > > > > > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat
> > kyzy <
> > > > > > > > >> > >> aizhamal@apache.org>
> > > > > > > > >> > >> wrote:
> > > > > > > > >> > >>
> > > > > > > > >> > >> > I think it will be good to document the process.
> For
> > > > > example,
> > > > > > > > >who is
> > > > > > > > >> > >> > responsible for closing Jira issues: folks who
> closed
> > > > PR's
> > > > > or
> > > > > > > > >the
> > > > > > > > >> ones
> > > > > > > > >> > >> who
> > > > > > > > >> > >> > opened?
> > > > > > > > >> > >> >
> > > > > > > > >> > >> > If the documentation already exists, let's bring it
> > > back
> > > > to
> > > > > > > > >> attention.
> > > > > > > > >> > >> >
> > > > > > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > > > > > > ><ka...@gmail.com>
> > > > > > > > >> > wrote:
> > > > > > > > >> > >> >
> > > > > > > > >> > >> > > Hi Committers,
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > Please make sure to close the Jira issues if the
> > > > related
> > > > > > PRs
> > > > > > > > >are
> > > > > > > > >> > >> merged.
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > I am going through the Jira Reports (Image:
> > > > > > > > >> > https://imgur.com/n50Ticx
> > > > > > > > >> > >> )
> > > > > > > > >> > >> > and
> > > > > > > > >> > >> > > was concerned with the gap between issues
> created &
> > > > > > resolved
> > > > > > > > >in
> > > > > > > > >> > recent
> > > > > > > > >> > >> > > months.
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > However, I noticed while going through the jira
> > > issues
> > > > > that
> > > > > > > > >most
> > > > > > > > >> of
> > > > > > > > >> > >> the
> > > > > > > > >> > >> > PRs
> > > > > > > > >> > >> > > related to the JIRAs have been resolved but the
> > JIRA
> > > is
> > > > > not
> > > > > > > > >> > resolved.
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > Let's try to resolve all the issues when we merge
> > the
> > > > PR
> > > > > :)
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > This will help the release manager too.
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > Regards,
> > > > > > > > >> > >> > > Kaxil
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> >
> > > > > > > > >> > >>
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > > > > > >> > > --
> > > > > > > > >> > >
> > > > > > > > >> > > Jarek Potiuk
> > > > > > > > >> > > Polidea <https://www.polidea.com/> | Principal
> Software
> > > > > > Engineer
> > > > > > > > >> > >
> > > > > > > > >> > > M: +48 660 796 129 <+48660796129>
> > > > > > > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >> > --
> > > > > > > > >> >
> > > > > > > > >> > Jarek Potiuk
> > > > > > > > >> > Polidea <https://www.polidea.com/> | Principal Software
> > > > > Engineer
> > > > > > > > >> >
> > > > > > > > >> > M: +48 660 796 129 <+48660796129>
> > > > > > > > >> > [image: Polidea] <https://www.polidea.com/>
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >--
> > > > > > > > >
> > > > > > > > >Tomasz Urbaszek
> > > > > > > > >Polidea <https://www.polidea.com/> | Junior Software
> Engineer
> > > > > > > > >
> > > > > > > > >M: +48 505 628 493 <+48505628493>
> > > > > > > > >E: tomasz.urbaszek@polidea.com <
> tomasz.urbaszeki@polidea.com>
> > > > > > > > >
> > > > > > > > >Unique Tech
> > > > > > > > >Check out our projects! <https://www.polidea.com/our-work>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Tomasz Urbaszek
> > > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > > >
> > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > > >
> > > > > > > Unique Tech
> > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Jarek Potiuk
> > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > > >
> > > > > M: +48 660 796 129 <+48660796129>
> > > > > [image: Polidea] <https://www.polidea.com/>
> > > > >
> > >
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: Closing JIRA Issue for Merged PRs

[Jarek Potiuk <Ja...@polidea.com>]

With the recent asf.yaml change, seems that we are getting to get much
easier self-maintenance of bot integration from ASF. I am all for adding
more bot-driven stuff :).

Probot looks absolutely great, especially that it has so many existing
integrations and we can add our own if needed and contribute it back.

Maybe someone would like to take on the "probot" hat and try to add some
useful integrations already ?

J.


On Wed, Nov 20, 2019 at 8:22 PM Kaxil Naik <ka...@gmail.com> wrote:

> I just used it on my fork and works nicely. Thanks, Max.
>
> +1 for probot
>
> On Tue, Nov 19, 2019 at 10:55 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > +1 for probot. How about we try it with
> > https://github.com/cchantep/probot-jira for example?
> >
> > On Tue, Nov 19, 2019 at 8:28 PM Daniel Imberman <
> daniel.imberman@gmail.com
> > >
> > wrote:
> >
> > > +1 for probot, the k8s community has a pretty slick GitHub automation
> > > system as well we should look into.
> > >
> > > via Newton Mail [
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > ]
> > > On Tue, Nov 19, 2019 at 2:09 PM, Maxime Beauchemin <
> > > maximebeauchemin@gmail.com> wrote:
> > > Quick note as I'm playing with Probot for Superset. It's possible to
> > catch
> > > all sorts of Github event and trigger all sorts of side effects with
> it.
> > >
> > > On the Superset side we're looking to enable automation around Github
> > > comments and labeling. It's also offers potential around enabling
> people
> > > (PMs, contributors) without write access to the repo to create
> > > labels, assign tasks, ...
> > >
> > > More about it here:
> > > https://probot.github.io/
> > >
> > > Max
> > >
> > > On Mon, Nov 18, 2019 at 2:14 PM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > wrote:
> > >
> > > > Agree that Github issue are nicely integrated with the code, I don't
> > > > particularly mind which issue tracking system I use as long as it has
> > > good
> > > > integration.
> > > >
> > > > The nice part about github issues that now with github actions we
> could
> > > > automate more and have full control over it. And a lot of this works
> > > > automagically (Fixes #NN) closes the issue when merged.
> > > >
> > > > On the other hand It is very limiting. I see it would have been
> > difficult
> > > > to follow the cherry-picking workflow where we decide after the merge
> > if
> > > we
> > > > want to cherry-pick or not. Issue can belong to only one milestone -
> so
> > > > then we'd have to start messing around with labels etc. I don't have
> > > > particularly strong feelings about moving out of JIRA and I think the
> > > > benefits are very small compared to the hassle of changing.
> > > >
> > > > There is a lot of "boring" work in the commiter's live - mostly
> > connected
> > > > with reviewing list of issues in one of the systems (sometimes many
> > times
> > > > over) and reacting somehow. I think it would be much more enjoyable
> if
> > we
> > > > had - even manually driven - some automation in place for that. I
> think
> > > > about a small but well-rounded tool that could help with managing
> state
> > > of
> > > > the several different system we use.
> > > >
> > > > I'd love a small "committer" CLI that we will be able to query the
> > state
> > > of
> > > > the issues and use it to perform particular tasks - i.e. checking the
> > > list
> > > > of open issues assigned to me, issues that I have recently interacted
> > > with,
> > > > issues that are in the area of my interest - viewable and
> discoverable
> > > via
> > > > the CLI, and then manageable from the same CLI. I'd love for example
> to
> > > see
> > > > all the issues that I already merged but they are not resolved yet.
> Or
> > > all
> > > > the issues for which build failed recently but they are likely
> > transient
> > > > rebuilds etc. etc. Something that could be a small (CLI) dashboard
> for
> > > all
> > > > the committers where all the typical use-cases for the committers are
> > > > automated. This way we could not only make our life easier but also
> we
> > > > could start promoting some good committer practices, and we could
> > > introduce
> > > > some more sophisticated strategies for dealing with issues (vs.
> current
> > > > anyone does anything strategy). For example sharing the issues
> between
> > > > committers, auto-assigning reviewers etc. etc. Of course this can all
> > be
> > > > done without such tool, but that would be far less fun if those are
> > > > "written down" and "manually followed" processes rather than
> automated
> > > > ones.
> > > >
> > > > And of course myself or anyone could develop such tool myself - but
> > it's
> > > > quite an effort and I think it would only pay off if the effort could
> > be
> > > > divided by a number of people contributing, but benefits multiplied
> by
> > a
> > > > number of people using it :).
> > > >
> > > > As we will have more committers (hopefully) we might have more need
> for
> > > > such tool. Is this a good time to start thinking about it?
> > > >
> > > > J.
> > > >
> > > > On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com>
> > wrote:
> > > >
> > > > > On a slightly irrelevant note, do we ever close tickets as
> > > > non-reproducable
> > > > > or will-not-fix?
> > > > > Last time I was going through open tickets I found dozens that
> seemed
> > > > > really old, really not-gonna-happen or already fixed.
> > > > > What actions could we take to decrease this gap?
> > > > > WDYT?
> > > > >
> > > > > S.
> > > > >
> > > > > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> > > > tomasz.urbaszek@polidea.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I can agree that GitHub issues may get spammy but I other
> projects
> > > deal
> > > > > > with it somehow. And as a user I like the simplicity of creating
> an
> > > > > issue.
> > > > > > As per Jira, I think a good part of it is the ability to link
> > issues
> > > > > across
> > > > > > different ASF project (but I don't think it's a killer feature).
> > > > > >
> > > > > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <
> bdbruin@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > I don’t like Jira particularly but I like GitHub issues even
> > less.
> > > > Both
> > > > > > > don’t feel right. And yes GitHub issues get spammy very
> quickly.
> > > The
> > > > > > hurdle
> > > > > > > gets so low that it functions as an alternative to the mailing
> > > list,
> > > > > far,
> > > > > > > and chat.
> > > > > > >
> > > > > > >
> > > > > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (
> > ash@apache.org
> > > )
> > > > > > wrote:
> > > > > > >
> > > > > > > Getting creds for Jira might be tricky, though Infra may have
> > some
> > > > way
> > > > > of
> > > > > > > resolving issues when PR is merged (please don't Close, only
> ever
> > > > > Resolve
> > > > > > > as closed issues can't have FixVersion changed)
> > > > > > >
> > > > > > > This brings me on to another question: what do were actual use
> > Jira
> > > > for
> > > > > > > that couldn't (or shouldn't) be done with GitHub Issues?
> > > > > > >
> > > > > > > The main thing I can think of right now is the Fix version when
> > > > > resolving
> > > > > > > to say when we should backport a PR, but this could be achieved
> > > with
> > > > > > > Milestones in GitHub.
> > > > > > >
> > > > > > > (A fringe benefit is that most people won't have an ASF Jira
> > > account
> > > > so
> > > > > > > opening issues to ask questions is harder. "Benefit" as it
> avoids
> > > > issue
> > > > > > > spam for question.)
> > > > > > >
> > > > > > > Is there anything else?
> > > > > > >
> > > > > > > -A
> > > > > > >
> > > > > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > >Is there any possibility to use GitHub actions for that?
> > > > > > > >For example, the one that allows to "Automatically transition
> an
> > > > issue
> > > > > > > >to
> > > > > > > >done when a pull request whose name contains the issue key is
> > > > merged"?
> > > > > > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > > > > > >
> > > > > > > >Bests,
> > > > > > > >Tomek
> > > > > > > >
> > > > > > > >
> > > > > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <
> > bdbruin@gmail.com
> > > >
> > > > > > > >wrote:
> > > > > > > >
> > > > > > > >> I wrote that script. It’s cli only unfortunately.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > > > > > >(ddavydov@twitter.com.invalid
> > > > > > > >> )
> > > > > > > >> wrote:
> > > > > > > >>
> > > > > > > >> Wait this doesn't happen automatically!? I thought
> > way-back-when
> > > > > > > >someone
> > > > > > > >> wrote a script to automatically close the JIRA tickets
> (maybe
> > > that
> > > > > > > >script
> > > > > > > >> is not run when changes are merged via the UI). My
> apologies,
> > > will
> > > > > > > >close
> > > > > > > >> JIRAs in the future, I don't think I've closed any JIRA
> > tickets
> > > > > > > >manually.
> > > > > > > >>
> > > > > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > > > > > ><Ja...@polidea.com>
> > > > > > > >> wrote:
> > > > > > > >>
> > > > > > > >> > And yes. I was one of the culprits - I saw :(. Sorry about
> > > that
> > > > > > > >Kaxil.
> > > > > > > >> > Just hope we can streamline this :).
> > > > > > > >> >
> > > > > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > > > > > ><Ja...@polidea.com>
> > > > > > > >> > wrote:
> > > > > > > >> >
> > > > > > > >> > > Heartily agree with it !
> > > > > > > >> > >
> > > > > > > >> > > I try always to close the PRs but sometimes I got
> > distracted
> > > > and
> > > > > > > >forget
> > > > > > > >> > to
> > > > > > > >> > > resolve an issue - it happend several times that I
> > recalled
> > > it
> > > > > > > >few
> > > > > > > >> hours
> > > > > > > >> > > later that I have forgotten to resolve it. I hope it
> > happens
> > > > > > > >rarely -
> > > > > > > >> I'd
> > > > > > > >> > > love to know if I was one of the culprits here :). And
> > > > whenever
> > > > > I
> > > > > > > >> noticed
> > > > > > > >> > > some of the PRs are not closed but PR is merged by
> someone
> > > > else
> > > > > -
> > > > > > > >I
> > > > > > > >> > > sometimes close them. But it's not ideal of course.
> > > > > > > >> > >
> > > > > > > >> > > However simple it is - I think we are just humans and we
> > > will
> > > > > > > >forget
> > > > > > > >> from
> > > > > > > >> > > time to time. I was wondering if we can (yes, you
> guessed
> > > it)
> > > > > > > >automate
> > > > > > > >> it
> > > > > > > >> > > :). Either with JIRA/Github integration or some
> automated
> > > tool
> > > > > to
> > > > > > > >do it
> > > > > > > >> > > regularly and resolving all already merged tickets. And
> > the
> > > > more
> > > > > > > >> > > committers we are going to have, the more it makes sense
> > to
> > > > > > > >automate
> > > > > > > >> some
> > > > > > > >> > > of the work. The less you have to remember about your
> > > "chores"
> > > > > > > >the more
> > > > > > > >> > you
> > > > > > > >> > > can focus on the "real" stuff.
> > > > > > > >> > >
> > > > > > > >> > > I think there are a few unwritten rules that we have -
> > like
> > > > what
> > > > > > > >> version
> > > > > > > >> > > to set when we cherry-pick change to 1.10* . My
> > > understanding
> > > > is
> > > > > > > >that
> > > > > > > >> we
> > > > > > > >> > > should set fixed version to the first unreleased yet
> 1.10.
> > > > > > > >version.
> > > > > > > >> This
> > > > > > > >> > > problem will soon be gone, so maybe it's not worth
> solving
> > > it.
> > > > > > > >There
> > > > > > > >> are
> > > > > > > >> > > also some edge cases like bad fixes which got reverted
> and
> > > > > > > >reapplied
> > > > > > > >> but
> > > > > > > >> > I
> > > > > > > >> > > think other than that the automation of it can be rather
> > > > simple.
> > > > > > > >> > >
> > > > > > > >> > > And I think there are some scripts in "dev" that already
> > do
> > > > some
> > > > > > > >of
> > > > > > > >> that
> > > > > > > >> > -
> > > > > > > >> > > synchronising merges with JIRAs (but I don't think it's
> > > common
> > > > > > > >> knowledge
> > > > > > > >> > > and it's not regularly run). Maybe we can improve it
> > somehow
> > > > and
> > > > > > > >have
> > > > > > > >> it
> > > > > > > >> > > fully automated so that we do not even havet to think
> > about
> > > > it ?
> > > > > > > >> > >
> > > > > > > >> > > WDYT? Any ideas?
> > > > > > > >> > >
> > > > > > > >> > > J.
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <
> > > > kaxilnaik@gmail.com
> > > > > >
> > > > > > > >> wrote:
> > > > > > > >> > >
> > > > > > > >> > >> We have some at
> > > > > > > >> > >>
> > > > > > > >>
> > > > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > > > > > >> > >>
> > > > > > > >> > >> The person who merges the PR to master is the one who
> > would
> > > > be
> > > > > > > >> > responsible
> > > > > > > >> > >> for resolving the JIRA issue as they can add the
> *target
> > > > > > > >version*
> > > > > > > >> based
> > > > > > > >> > on
> > > > > > > >> > >> what they think after reviewing the PR.
> > > > > > > >> > >>
> > > > > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat
> kyzy <
> > > > > > > >> > >> aizhamal@apache.org>
> > > > > > > >> > >> wrote:
> > > > > > > >> > >>
> > > > > > > >> > >> > I think it will be good to document the process. For
> > > > example,
> > > > > > > >who is
> > > > > > > >> > >> > responsible for closing Jira issues: folks who closed
> > > PR's
> > > > or
> > > > > > > >the
> > > > > > > >> ones
> > > > > > > >> > >> who
> > > > > > > >> > >> > opened?
> > > > > > > >> > >> >
> > > > > > > >> > >> > If the documentation already exists, let's bring it
> > back
> > > to
> > > > > > > >> attention.
> > > > > > > >> > >> >
> > > > > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > > > > > ><ka...@gmail.com>
> > > > > > > >> > wrote:
> > > > > > > >> > >> >
> > > > > > > >> > >> > > Hi Committers,
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > Please make sure to close the Jira issues if the
> > > related
> > > > > PRs
> > > > > > > >are
> > > > > > > >> > >> merged.
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > I am going through the Jira Reports (Image:
> > > > > > > >> > https://imgur.com/n50Ticx
> > > > > > > >> > >> )
> > > > > > > >> > >> > and
> > > > > > > >> > >> > > was concerned with the gap between issues created &
> > > > > resolved
> > > > > > > >in
> > > > > > > >> > recent
> > > > > > > >> > >> > > months.
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > However, I noticed while going through the jira
> > issues
> > > > that
> > > > > > > >most
> > > > > > > >> of
> > > > > > > >> > >> the
> > > > > > > >> > >> > PRs
> > > > > > > >> > >> > > related to the JIRAs have been resolved but the
> JIRA
> > is
> > > > not
> > > > > > > >> > resolved.
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > Let's try to resolve all the issues when we merge
> the
> > > PR
> > > > :)
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > This will help the release manager too.
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > Regards,
> > > > > > > >> > >> > > Kaxil
> > > > > > > >> > >> > >
> > > > > > > >> > >> >
> > > > > > > >> > >>
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > --
> > > > > > > >> > >
> > > > > > > >> > > Jarek Potiuk
> > > > > > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> > > > > Engineer
> > > > > > > >> > >
> > > > > > > >> > > M: +48 660 796 129 <+48660796129>
> > > > > > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >> > --
> > > > > > > >> >
> > > > > > > >> > Jarek Potiuk
> > > > > > > >> > Polidea <https://www.polidea.com/> | Principal Software
> > > > Engineer
> > > > > > > >> >
> > > > > > > >> > M: +48 660 796 129 <+48660796129>
> > > > > > > >> > [image: Polidea] <https://www.polidea.com/>
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >--
> > > > > > > >
> > > > > > > >Tomasz Urbaszek
> > > > > > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > > > >
> > > > > > > >M: +48 505 628 493 <+48505628493>
> > > > > > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > > > >
> > > > > > > >Unique Tech
> > > > > > > >Check out our projects! <https://www.polidea.com/our-work>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Tomasz Urbaszek
> > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > >
> > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > >
> > > > > > Unique Tech
> > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Jarek Potiuk
> > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >
> > > > M: +48 660 796 129 <+48660796129>
> > > > [image: Polidea] <https://www.polidea.com/>
> > > >
> >
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: Closing JIRA Issue for Merged PRs

[Kaxil Naik <ka...@gmail.com>]

I just used it on my fork and works nicely. Thanks, Max.

+1 for probot

On Tue, Nov 19, 2019 at 10:55 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> +1 for probot. How about we try it with
> https://github.com/cchantep/probot-jira for example?
>
> On Tue, Nov 19, 2019 at 8:28 PM Daniel Imberman <daniel.imberman@gmail.com
> >
> wrote:
>
> > +1 for probot, the k8s community has a pretty slick GitHub automation
> > system as well we should look into.
> >
> > via Newton Mail [
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > ]
> > On Tue, Nov 19, 2019 at 2:09 PM, Maxime Beauchemin <
> > maximebeauchemin@gmail.com> wrote:
> > Quick note as I'm playing with Probot for Superset. It's possible to
> catch
> > all sorts of Github event and trigger all sorts of side effects with it.
> >
> > On the Superset side we're looking to enable automation around Github
> > comments and labeling. It's also offers potential around enabling people
> > (PMs, contributors) without write access to the repo to create
> > labels, assign tasks, ...
> >
> > More about it here:
> > https://probot.github.io/
> >
> > Max
> >
> > On Mon, Nov 18, 2019 at 2:14 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > Agree that Github issue are nicely integrated with the code, I don't
> > > particularly mind which issue tracking system I use as long as it has
> > good
> > > integration.
> > >
> > > The nice part about github issues that now with github actions we could
> > > automate more and have full control over it. And a lot of this works
> > > automagically (Fixes #NN) closes the issue when merged.
> > >
> > > On the other hand It is very limiting. I see it would have been
> difficult
> > > to follow the cherry-picking workflow where we decide after the merge
> if
> > we
> > > want to cherry-pick or not. Issue can belong to only one milestone - so
> > > then we'd have to start messing around with labels etc. I don't have
> > > particularly strong feelings about moving out of JIRA and I think the
> > > benefits are very small compared to the hassle of changing.
> > >
> > > There is a lot of "boring" work in the commiter's live - mostly
> connected
> > > with reviewing list of issues in one of the systems (sometimes many
> times
> > > over) and reacting somehow. I think it would be much more enjoyable if
> we
> > > had - even manually driven - some automation in place for that. I think
> > > about a small but well-rounded tool that could help with managing state
> > of
> > > the several different system we use.
> > >
> > > I'd love a small "committer" CLI that we will be able to query the
> state
> > of
> > > the issues and use it to perform particular tasks - i.e. checking the
> > list
> > > of open issues assigned to me, issues that I have recently interacted
> > with,
> > > issues that are in the area of my interest - viewable and discoverable
> > via
> > > the CLI, and then manageable from the same CLI. I'd love for example to
> > see
> > > all the issues that I already merged but they are not resolved yet. Or
> > all
> > > the issues for which build failed recently but they are likely
> transient
> > > rebuilds etc. etc. Something that could be a small (CLI) dashboard for
> > all
> > > the committers where all the typical use-cases for the committers are
> > > automated. This way we could not only make our life easier but also we
> > > could start promoting some good committer practices, and we could
> > introduce
> > > some more sophisticated strategies for dealing with issues (vs. current
> > > anyone does anything strategy). For example sharing the issues between
> > > committers, auto-assigning reviewers etc. etc. Of course this can all
> be
> > > done without such tool, but that would be far less fun if those are
> > > "written down" and "manually followed" processes rather than automated
> > > ones.
> > >
> > > And of course myself or anyone could develop such tool myself - but
> it's
> > > quite an effort and I think it would only pay off if the effort could
> be
> > > divided by a number of people contributing, but benefits multiplied by
> a
> > > number of people using it :).
> > >
> > > As we will have more committers (hopefully) we might have more need for
> > > such tool. Is this a good time to start thinking about it?
> > >
> > > J.
> > >
> > > On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com>
> wrote:
> > >
> > > > On a slightly irrelevant note, do we ever close tickets as
> > > non-reproducable
> > > > or will-not-fix?
> > > > Last time I was going through open tickets I found dozens that seemed
> > > > really old, really not-gonna-happen or already fixed.
> > > > What actions could we take to decrease this gap?
> > > > WDYT?
> > > >
> > > > S.
> > > >
> > > > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> > > tomasz.urbaszek@polidea.com
> > > > >
> > > > wrote:
> > > >
> > > > > I can agree that GitHub issues may get spammy but I other projects
> > deal
> > > > > with it somehow. And as a user I like the simplicity of creating an
> > > > issue.
> > > > > As per Jira, I think a good part of it is the ability to link
> issues
> > > > across
> > > > > different ASF project (but I don't think it's a killer feature).
> > > > >
> > > > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > I don’t like Jira particularly but I like GitHub issues even
> less.
> > > Both
> > > > > > don’t feel right. And yes GitHub issues get spammy very quickly.
> > The
> > > > > hurdle
> > > > > > gets so low that it functions as an alternative to the mailing
> > list,
> > > > far,
> > > > > > and chat.
> > > > > >
> > > > > >
> > > > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (
> ash@apache.org
> > )
> > > > > wrote:
> > > > > >
> > > > > > Getting creds for Jira might be tricky, though Infra may have
> some
> > > way
> > > > of
> > > > > > resolving issues when PR is merged (please don't Close, only ever
> > > > Resolve
> > > > > > as closed issues can't have FixVersion changed)
> > > > > >
> > > > > > This brings me on to another question: what do were actual use
> Jira
> > > for
> > > > > > that couldn't (or shouldn't) be done with GitHub Issues?
> > > > > >
> > > > > > The main thing I can think of right now is the Fix version when
> > > > resolving
> > > > > > to say when we should backport a PR, but this could be achieved
> > with
> > > > > > Milestones in GitHub.
> > > > > >
> > > > > > (A fringe benefit is that most people won't have an ASF Jira
> > account
> > > so
> > > > > > opening issues to ask questions is harder. "Benefit" as it avoids
> > > issue
> > > > > > spam for question.)
> > > > > >
> > > > > > Is there anything else?
> > > > > >
> > > > > > -A
> > > > > >
> > > > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > >Is there any possibility to use GitHub actions for that?
> > > > > > >For example, the one that allows to "Automatically transition an
> > > issue
> > > > > > >to
> > > > > > >done when a pull request whose name contains the issue key is
> > > merged"?
> > > > > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > > > > >
> > > > > > >Bests,
> > > > > > >Tomek
> > > > > > >
> > > > > > >
> > > > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <
> bdbruin@gmail.com
> > >
> > > > > > >wrote:
> > > > > > >
> > > > > > >> I wrote that script. It’s cli only unfortunately.
> > > > > > >>
> > > > > > >>
> > > > > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > > > > >(ddavydov@twitter.com.invalid
> > > > > > >> )
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> Wait this doesn't happen automatically!? I thought
> way-back-when
> > > > > > >someone
> > > > > > >> wrote a script to automatically close the JIRA tickets (maybe
> > that
> > > > > > >script
> > > > > > >> is not run when changes are merged via the UI). My apologies,
> > will
> > > > > > >close
> > > > > > >> JIRAs in the future, I don't think I've closed any JIRA
> tickets
> > > > > > >manually.
> > > > > > >>
> > > > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > > > > ><Ja...@polidea.com>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > And yes. I was one of the culprits - I saw :(. Sorry about
> > that
> > > > > > >Kaxil.
> > > > > > >> > Just hope we can streamline this :).
> > > > > > >> >
> > > > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > > > > ><Ja...@polidea.com>
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> > > Heartily agree with it !
> > > > > > >> > >
> > > > > > >> > > I try always to close the PRs but sometimes I got
> distracted
> > > and
> > > > > > >forget
> > > > > > >> > to
> > > > > > >> > > resolve an issue - it happend several times that I
> recalled
> > it
> > > > > > >few
> > > > > > >> hours
> > > > > > >> > > later that I have forgotten to resolve it. I hope it
> happens
> > > > > > >rarely -
> > > > > > >> I'd
> > > > > > >> > > love to know if I was one of the culprits here :). And
> > > whenever
> > > > I
> > > > > > >> noticed
> > > > > > >> > > some of the PRs are not closed but PR is merged by someone
> > > else
> > > > -
> > > > > > >I
> > > > > > >> > > sometimes close them. But it's not ideal of course.
> > > > > > >> > >
> > > > > > >> > > However simple it is - I think we are just humans and we
> > will
> > > > > > >forget
> > > > > > >> from
> > > > > > >> > > time to time. I was wondering if we can (yes, you guessed
> > it)
> > > > > > >automate
> > > > > > >> it
> > > > > > >> > > :). Either with JIRA/Github integration or some automated
> > tool
> > > > to
> > > > > > >do it
> > > > > > >> > > regularly and resolving all already merged tickets. And
> the
> > > more
> > > > > > >> > > committers we are going to have, the more it makes sense
> to
> > > > > > >automate
> > > > > > >> some
> > > > > > >> > > of the work. The less you have to remember about your
> > "chores"
> > > > > > >the more
> > > > > > >> > you
> > > > > > >> > > can focus on the "real" stuff.
> > > > > > >> > >
> > > > > > >> > > I think there are a few unwritten rules that we have -
> like
> > > what
> > > > > > >> version
> > > > > > >> > > to set when we cherry-pick change to 1.10* . My
> > understanding
> > > is
> > > > > > >that
> > > > > > >> we
> > > > > > >> > > should set fixed version to the first unreleased yet 1.10.
> > > > > > >version.
> > > > > > >> This
> > > > > > >> > > problem will soon be gone, so maybe it's not worth solving
> > it.
> > > > > > >There
> > > > > > >> are
> > > > > > >> > > also some edge cases like bad fixes which got reverted and
> > > > > > >reapplied
> > > > > > >> but
> > > > > > >> > I
> > > > > > >> > > think other than that the automation of it can be rather
> > > simple.
> > > > > > >> > >
> > > > > > >> > > And I think there are some scripts in "dev" that already
> do
> > > some
> > > > > > >of
> > > > > > >> that
> > > > > > >> > -
> > > > > > >> > > synchronising merges with JIRAs (but I don't think it's
> > common
> > > > > > >> knowledge
> > > > > > >> > > and it's not regularly run). Maybe we can improve it
> somehow
> > > and
> > > > > > >have
> > > > > > >> it
> > > > > > >> > > fully automated so that we do not even havet to think
> about
> > > it ?
> > > > > > >> > >
> > > > > > >> > > WDYT? Any ideas?
> > > > > > >> > >
> > > > > > >> > > J.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <
> > > kaxilnaik@gmail.com
> > > > >
> > > > > > >> wrote:
> > > > > > >> > >
> > > > > > >> > >> We have some at
> > > > > > >> > >>
> > > > > > >>
> > > > > > >
> > > >
> > https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > > > > >> > >>
> > > > > > >> > >> The person who merges the PR to master is the one who
> would
> > > be
> > > > > > >> > responsible
> > > > > > >> > >> for resolving the JIRA issue as they can add the *target
> > > > > > >version*
> > > > > > >> based
> > > > > > >> > on
> > > > > > >> > >> what they think after reviewing the PR.
> > > > > > >> > >>
> > > > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > > > > > >> > >> aizhamal@apache.org>
> > > > > > >> > >> wrote:
> > > > > > >> > >>
> > > > > > >> > >> > I think it will be good to document the process. For
> > > example,
> > > > > > >who is
> > > > > > >> > >> > responsible for closing Jira issues: folks who closed
> > PR's
> > > or
> > > > > > >the
> > > > > > >> ones
> > > > > > >> > >> who
> > > > > > >> > >> > opened?
> > > > > > >> > >> >
> > > > > > >> > >> > If the documentation already exists, let's bring it
> back
> > to
> > > > > > >> attention.
> > > > > > >> > >> >
> > > > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > > > > ><ka...@gmail.com>
> > > > > > >> > wrote:
> > > > > > >> > >> >
> > > > > > >> > >> > > Hi Committers,
> > > > > > >> > >> > >
> > > > > > >> > >> > > Please make sure to close the Jira issues if the
> > related
> > > > PRs
> > > > > > >are
> > > > > > >> > >> merged.
> > > > > > >> > >> > >
> > > > > > >> > >> > > I am going through the Jira Reports (Image:
> > > > > > >> > https://imgur.com/n50Ticx
> > > > > > >> > >> )
> > > > > > >> > >> > and
> > > > > > >> > >> > > was concerned with the gap between issues created &
> > > > resolved
> > > > > > >in
> > > > > > >> > recent
> > > > > > >> > >> > > months.
> > > > > > >> > >> > >
> > > > > > >> > >> > > However, I noticed while going through the jira
> issues
> > > that
> > > > > > >most
> > > > > > >> of
> > > > > > >> > >> the
> > > > > > >> > >> > PRs
> > > > > > >> > >> > > related to the JIRAs have been resolved but the JIRA
> is
> > > not
> > > > > > >> > resolved.
> > > > > > >> > >> > >
> > > > > > >> > >> > > Let's try to resolve all the issues when we merge the
> > PR
> > > :)
> > > > > > >> > >> > >
> > > > > > >> > >> > > This will help the release manager too.
> > > > > > >> > >> > >
> > > > > > >> > >> > > Regards,
> > > > > > >> > >> > > Kaxil
> > > > > > >> > >> > >
> > > > > > >> > >> >
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > --
> > > > > > >> > >
> > > > > > >> > > Jarek Potiuk
> > > > > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> > > > Engineer
> > > > > > >> > >
> > > > > > >> > > M: +48 660 796 129 <+48660796129>
> > > > > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> > --
> > > > > > >> >
> > > > > > >> > Jarek Potiuk
> > > > > > >> > Polidea <https://www.polidea.com/> | Principal Software
> > > Engineer
> > > > > > >> >
> > > > > > >> > M: +48 660 796 129 <+48660796129>
> > > > > > >> > [image: Polidea] <https://www.polidea.com/>
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >--
> > > > > > >
> > > > > > >Tomasz Urbaszek
> > > > > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > > >
> > > > > > >M: +48 505 628 493 <+48505628493>
> > > > > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > > >
> > > > > > >Unique Tech
> > > > > > >Check out our projects! <https://www.polidea.com/our-work>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Tomasz Urbaszek
> > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > >
> > > > > M: +48 505 628 493 <+48505628493>
> > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > >
> > > > > Unique Tech
> > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
>
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: Closing JIRA Issue for Merged PRs

[Jarek Potiuk <Ja...@polidea.com>]

+1 for probot. How about we try it with
https://github.com/cchantep/probot-jira for example?

On Tue, Nov 19, 2019 at 8:28 PM Daniel Imberman <da...@gmail.com>
wrote:

> +1 for probot, the k8s community has a pretty slick GitHub automation
> system as well we should look into.
>
> via Newton Mail [
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> ]
> On Tue, Nov 19, 2019 at 2:09 PM, Maxime Beauchemin <
> maximebeauchemin@gmail.com> wrote:
> Quick note as I'm playing with Probot for Superset. It's possible to catch
> all sorts of Github event and trigger all sorts of side effects with it.
>
> On the Superset side we're looking to enable automation around Github
> comments and labeling. It's also offers potential around enabling people
> (PMs, contributors) without write access to the repo to create
> labels, assign tasks, ...
>
> More about it here:
> https://probot.github.io/
>
> Max
>
> On Mon, Nov 18, 2019 at 2:14 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Agree that Github issue are nicely integrated with the code, I don't
> > particularly mind which issue tracking system I use as long as it has
> good
> > integration.
> >
> > The nice part about github issues that now with github actions we could
> > automate more and have full control over it. And a lot of this works
> > automagically (Fixes #NN) closes the issue when merged.
> >
> > On the other hand It is very limiting. I see it would have been difficult
> > to follow the cherry-picking workflow where we decide after the merge if
> we
> > want to cherry-pick or not. Issue can belong to only one milestone - so
> > then we'd have to start messing around with labels etc. I don't have
> > particularly strong feelings about moving out of JIRA and I think the
> > benefits are very small compared to the hassle of changing.
> >
> > There is a lot of "boring" work in the commiter's live - mostly connected
> > with reviewing list of issues in one of the systems (sometimes many times
> > over) and reacting somehow. I think it would be much more enjoyable if we
> > had - even manually driven - some automation in place for that. I think
> > about a small but well-rounded tool that could help with managing state
> of
> > the several different system we use.
> >
> > I'd love a small "committer" CLI that we will be able to query the state
> of
> > the issues and use it to perform particular tasks - i.e. checking the
> list
> > of open issues assigned to me, issues that I have recently interacted
> with,
> > issues that are in the area of my interest - viewable and discoverable
> via
> > the CLI, and then manageable from the same CLI. I'd love for example to
> see
> > all the issues that I already merged but they are not resolved yet. Or
> all
> > the issues for which build failed recently but they are likely transient
> > rebuilds etc. etc. Something that could be a small (CLI) dashboard for
> all
> > the committers where all the typical use-cases for the committers are
> > automated. This way we could not only make our life easier but also we
> > could start promoting some good committer practices, and we could
> introduce
> > some more sophisticated strategies for dealing with issues (vs. current
> > anyone does anything strategy). For example sharing the issues between
> > committers, auto-assigning reviewers etc. etc. Of course this can all be
> > done without such tool, but that would be far less fun if those are
> > "written down" and "manually followed" processes rather than automated
> > ones.
> >
> > And of course myself or anyone could develop such tool myself - but it's
> > quite an effort and I think it would only pay off if the effort could be
> > divided by a number of people contributing, but benefits multiplied by a
> > number of people using it :).
> >
> > As we will have more committers (hopefully) we might have more need for
> > such tool. Is this a good time to start thinking about it?
> >
> > J.
> >
> > On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com> wrote:
> >
> > > On a slightly irrelevant note, do we ever close tickets as
> > non-reproducable
> > > or will-not-fix?
> > > Last time I was going through open tickets I found dozens that seemed
> > > really old, really not-gonna-happen or already fixed.
> > > What actions could we take to decrease this gap?
> > > WDYT?
> > >
> > > S.
> > >
> > > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> > tomasz.urbaszek@polidea.com
> > > >
> > > wrote:
> > >
> > > > I can agree that GitHub issues may get spammy but I other projects
> deal
> > > > with it somehow. And as a user I like the simplicity of creating an
> > > issue.
> > > > As per Jira, I think a good part of it is the ability to link issues
> > > across
> > > > different ASF project (but I don't think it's a killer feature).
> > > >
> > > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> > > wrote:
> > > >
> > > > > I don’t like Jira particularly but I like GitHub issues even less.
> > Both
> > > > > don’t feel right. And yes GitHub issues get spammy very quickly.
> The
> > > > hurdle
> > > > > gets so low that it functions as an alternative to the mailing
> list,
> > > far,
> > > > > and chat.
> > > > >
> > > > >
> > > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org
> )
> > > > wrote:
> > > > >
> > > > > Getting creds for Jira might be tricky, though Infra may have some
> > way
> > > of
> > > > > resolving issues when PR is merged (please don't Close, only ever
> > > Resolve
> > > > > as closed issues can't have FixVersion changed)
> > > > >
> > > > > This brings me on to another question: what do were actual use Jira
> > for
> > > > > that couldn't (or shouldn't) be done with GitHub Issues?
> > > > >
> > > > > The main thing I can think of right now is the Fix version when
> > > resolving
> > > > > to say when we should backport a PR, but this could be achieved
> with
> > > > > Milestones in GitHub.
> > > > >
> > > > > (A fringe benefit is that most people won't have an ASF Jira
> account
> > so
> > > > > opening issues to ask questions is harder. "Benefit" as it avoids
> > issue
> > > > > spam for question.)
> > > > >
> > > > > Is there anything else?
> > > > >
> > > > > -A
> > > > >
> > > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > >Is there any possibility to use GitHub actions for that?
> > > > > >For example, the one that allows to "Automatically transition an
> > issue
> > > > > >to
> > > > > >done when a pull request whose name contains the issue key is
> > merged"?
> > > > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > > > >
> > > > > >Bests,
> > > > > >Tomek
> > > > > >
> > > > > >
> > > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bdbruin@gmail.com
> >
> > > > > >wrote:
> > > > > >
> > > > > >> I wrote that script. It’s cli only unfortunately.
> > > > > >>
> > > > > >>
> > > > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > > > >(ddavydov@twitter.com.invalid
> > > > > >> )
> > > > > >> wrote:
> > > > > >>
> > > > > >> Wait this doesn't happen automatically!? I thought way-back-when
> > > > > >someone
> > > > > >> wrote a script to automatically close the JIRA tickets (maybe
> that
> > > > > >script
> > > > > >> is not run when changes are merged via the UI). My apologies,
> will
> > > > > >close
> > > > > >> JIRAs in the future, I don't think I've closed any JIRA tickets
> > > > > >manually.
> > > > > >>
> > > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > > > ><Ja...@polidea.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > And yes. I was one of the culprits - I saw :(. Sorry about
> that
> > > > > >Kaxil.
> > > > > >> > Just hope we can streamline this :).
> > > > > >> >
> > > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > > > ><Ja...@polidea.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Heartily agree with it !
> > > > > >> > >
> > > > > >> > > I try always to close the PRs but sometimes I got distracted
> > and
> > > > > >forget
> > > > > >> > to
> > > > > >> > > resolve an issue - it happend several times that I recalled
> it
> > > > > >few
> > > > > >> hours
> > > > > >> > > later that I have forgotten to resolve it. I hope it happens
> > > > > >rarely -
> > > > > >> I'd
> > > > > >> > > love to know if I was one of the culprits here :). And
> > whenever
> > > I
> > > > > >> noticed
> > > > > >> > > some of the PRs are not closed but PR is merged by someone
> > else
> > > -
> > > > > >I
> > > > > >> > > sometimes close them. But it's not ideal of course.
> > > > > >> > >
> > > > > >> > > However simple it is - I think we are just humans and we
> will
> > > > > >forget
> > > > > >> from
> > > > > >> > > time to time. I was wondering if we can (yes, you guessed
> it)
> > > > > >automate
> > > > > >> it
> > > > > >> > > :). Either with JIRA/Github integration or some automated
> tool
> > > to
> > > > > >do it
> > > > > >> > > regularly and resolving all already merged tickets. And the
> > more
> > > > > >> > > committers we are going to have, the more it makes sense to
> > > > > >automate
> > > > > >> some
> > > > > >> > > of the work. The less you have to remember about your
> "chores"
> > > > > >the more
> > > > > >> > you
> > > > > >> > > can focus on the "real" stuff.
> > > > > >> > >
> > > > > >> > > I think there are a few unwritten rules that we have - like
> > what
> > > > > >> version
> > > > > >> > > to set when we cherry-pick change to 1.10* . My
> understanding
> > is
> > > > > >that
> > > > > >> we
> > > > > >> > > should set fixed version to the first unreleased yet 1.10.
> > > > > >version.
> > > > > >> This
> > > > > >> > > problem will soon be gone, so maybe it's not worth solving
> it.
> > > > > >There
> > > > > >> are
> > > > > >> > > also some edge cases like bad fixes which got reverted and
> > > > > >reapplied
> > > > > >> but
> > > > > >> > I
> > > > > >> > > think other than that the automation of it can be rather
> > simple.
> > > > > >> > >
> > > > > >> > > And I think there are some scripts in "dev" that already do
> > some
> > > > > >of
> > > > > >> that
> > > > > >> > -
> > > > > >> > > synchronising merges with JIRAs (but I don't think it's
> common
> > > > > >> knowledge
> > > > > >> > > and it's not regularly run). Maybe we can improve it somehow
> > and
> > > > > >have
> > > > > >> it
> > > > > >> > > fully automated so that we do not even havet to think about
> > it ?
> > > > > >> > >
> > > > > >> > > WDYT? Any ideas?
> > > > > >> > >
> > > > > >> > > J.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <
> > kaxilnaik@gmail.com
> > > >
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > >> We have some at
> > > > > >> > >>
> > > > > >>
> > > > > >
> > >
> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > > > >> > >>
> > > > > >> > >> The person who merges the PR to master is the one who would
> > be
> > > > > >> > responsible
> > > > > >> > >> for resolving the JIRA issue as they can add the *target
> > > > > >version*
> > > > > >> based
> > > > > >> > on
> > > > > >> > >> what they think after reviewing the PR.
> > > > > >> > >>
> > > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > > > > >> > >> aizhamal@apache.org>
> > > > > >> > >> wrote:
> > > > > >> > >>
> > > > > >> > >> > I think it will be good to document the process. For
> > example,
> > > > > >who is
> > > > > >> > >> > responsible for closing Jira issues: folks who closed
> PR's
> > or
> > > > > >the
> > > > > >> ones
> > > > > >> > >> who
> > > > > >> > >> > opened?
> > > > > >> > >> >
> > > > > >> > >> > If the documentation already exists, let's bring it back
> to
> > > > > >> attention.
> > > > > >> > >> >
> > > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > > > ><ka...@gmail.com>
> > > > > >> > wrote:
> > > > > >> > >> >
> > > > > >> > >> > > Hi Committers,
> > > > > >> > >> > >
> > > > > >> > >> > > Please make sure to close the Jira issues if the
> related
> > > PRs
> > > > > >are
> > > > > >> > >> merged.
> > > > > >> > >> > >
> > > > > >> > >> > > I am going through the Jira Reports (Image:
> > > > > >> > https://imgur.com/n50Ticx
> > > > > >> > >> )
> > > > > >> > >> > and
> > > > > >> > >> > > was concerned with the gap between issues created &
> > > resolved
> > > > > >in
> > > > > >> > recent
> > > > > >> > >> > > months.
> > > > > >> > >> > >
> > > > > >> > >> > > However, I noticed while going through the jira issues
> > that
> > > > > >most
> > > > > >> of
> > > > > >> > >> the
> > > > > >> > >> > PRs
> > > > > >> > >> > > related to the JIRAs have been resolved but the JIRA is
> > not
> > > > > >> > resolved.
> > > > > >> > >> > >
> > > > > >> > >> > > Let's try to resolve all the issues when we merge the
> PR
> > :)
> > > > > >> > >> > >
> > > > > >> > >> > > This will help the release manager too.
> > > > > >> > >> > >
> > > > > >> > >> > > Regards,
> > > > > >> > >> > > Kaxil
> > > > > >> > >> > >
> > > > > >> > >> >
> > > > > >> > >>
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > >
> > > > > >> > > Jarek Potiuk
> > > > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> > > Engineer
> > > > > >> > >
> > > > > >> > > M: +48 660 796 129 <+48660796129>
> > > > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >> > --
> > > > > >> >
> > > > > >> > Jarek Potiuk
> > > > > >> > Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > > >> >
> > > > > >> > M: +48 660 796 129 <+48660796129>
> > > > > >> > [image: Polidea] <https://www.polidea.com/>
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > > >--
> > > > > >
> > > > > >Tomasz Urbaszek
> > > > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > >
> > > > > >M: +48 505 628 493 <+48505628493>
> > > > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > >
> > > > > >Unique Tech
> > > > > >Check out our projects! <https://www.polidea.com/our-work>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Tomasz Urbaszek
> > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > >
> > > > M: +48 505 628 493 <+48505628493>
> > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > >
> > > > Unique Tech
> > > > Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >



-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: Closing JIRA Issue for Merged PRs

[Daniel Imberman <da...@gmail.com>]

+1 for probot, the k8s community has a pretty slick GitHub automation system as well we should look into.

via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2]
On Tue, Nov 19, 2019 at 2:09 PM, Maxime Beauchemin <ma...@gmail.com> wrote:
Quick note as I'm playing with Probot for Superset. It's possible to catch
all sorts of Github event and trigger all sorts of side effects with it.

On the Superset side we're looking to enable automation around Github
comments and labeling. It's also offers potential around enabling people
(PMs, contributors) without write access to the repo to create
labels, assign tasks, ...

More about it here:
https://probot.github.io/

Max

On Mon, Nov 18, 2019 at 2:14 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> Agree that Github issue are nicely integrated with the code, I don't
> particularly mind which issue tracking system I use as long as it has good
> integration.
>
> The nice part about github issues that now with github actions we could
> automate more and have full control over it. And a lot of this works
> automagically (Fixes #NN) closes the issue when merged.
>
> On the other hand It is very limiting. I see it would have been difficult
> to follow the cherry-picking workflow where we decide after the merge if we
> want to cherry-pick or not. Issue can belong to only one milestone - so
> then we'd have to start messing around with labels etc. I don't have
> particularly strong feelings about moving out of JIRA and I think the
> benefits are very small compared to the hassle of changing.
>
> There is a lot of "boring" work in the commiter's live - mostly connected
> with reviewing list of issues in one of the systems (sometimes many times
> over) and reacting somehow. I think it would be much more enjoyable if we
> had - even manually driven - some automation in place for that. I think
> about a small but well-rounded tool that could help with managing state of
> the several different system we use.
>
> I'd love a small "committer" CLI that we will be able to query the state of
> the issues and use it to perform particular tasks - i.e. checking the list
> of open issues assigned to me, issues that I have recently interacted with,
> issues that are in the area of my interest - viewable and discoverable via
> the CLI, and then manageable from the same CLI. I'd love for example to see
> all the issues that I already merged but they are not resolved yet. Or all
> the issues for which build failed recently but they are likely transient
> rebuilds etc. etc. Something that could be a small (CLI) dashboard for all
> the committers where all the typical use-cases for the committers are
> automated. This way we could not only make our life easier but also we
> could start promoting some good committer practices, and we could introduce
> some more sophisticated strategies for dealing with issues (vs. current
> anyone does anything strategy). For example sharing the issues between
> committers, auto-assigning reviewers etc. etc. Of course this can all be
> done without such tool, but that would be far less fun if those are
> "written down" and "manually followed" processes rather than automated
> ones.
>
> And of course myself or anyone could develop such tool myself - but it's
> quite an effort and I think it would only pay off if the effort could be
> divided by a number of people contributing, but benefits multiplied by a
> number of people using it :).
>
> As we will have more committers (hopefully) we might have more need for
> such tool. Is this a good time to start thinking about it?
>
> J.
>
> On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com> wrote:
>
> > On a slightly irrelevant note, do we ever close tickets as
> non-reproducable
> > or will-not-fix?
> > Last time I was going through open tickets I found dozens that seemed
> > really old, really not-gonna-happen or already fixed.
> > What actions could we take to decrease this gap?
> > WDYT?
> >
> > S.
> >
> > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com
> > >
> > wrote:
> >
> > > I can agree that GitHub issues may get spammy but I other projects deal
> > > with it somehow. And as a user I like the simplicity of creating an
> > issue.
> > > As per Jira, I think a good part of it is the ability to link issues
> > across
> > > different ASF project (but I don't think it's a killer feature).
> > >
> > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> > wrote:
> > >
> > > > I don’t like Jira particularly but I like GitHub issues even less.
> Both
> > > > don’t feel right. And yes GitHub issues get spammy very quickly. The
> > > hurdle
> > > > gets so low that it functions as an alternative to the mailing list,
> > far,
> > > > and chat.
> > > >
> > > >
> > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> > > wrote:
> > > >
> > > > Getting creds for Jira might be tricky, though Infra may have some
> way
> > of
> > > > resolving issues when PR is merged (please don't Close, only ever
> > Resolve
> > > > as closed issues can't have FixVersion changed)
> > > >
> > > > This brings me on to another question: what do were actual use Jira
> for
> > > > that couldn't (or shouldn't) be done with GitHub Issues?
> > > >
> > > > The main thing I can think of right now is the Fix version when
> > resolving
> > > > to say when we should backport a PR, but this could be achieved with
> > > > Milestones in GitHub.
> > > >
> > > > (A fringe benefit is that most people won't have an ASF Jira account
> so
> > > > opening issues to ask questions is harder. "Benefit" as it avoids
> issue
> > > > spam for question.)
> > > >
> > > > Is there anything else?
> > > >
> > > > -A
> > > >
> > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > > tomasz.urbaszek@polidea.com> wrote:
> > > > >Is there any possibility to use GitHub actions for that?
> > > > >For example, the one that allows to "Automatically transition an
> issue
> > > > >to
> > > > >done when a pull request whose name contains the issue key is
> merged"?
> > > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > > >
> > > > >Bests,
> > > > >Tomek
> > > > >
> > > > >
> > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> > > > >wrote:
> > > > >
> > > > >> I wrote that script. It’s cli only unfortunately.
> > > > >>
> > > > >>
> > > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > > >(ddavydov@twitter.com.invalid
> > > > >> )
> > > > >> wrote:
> > > > >>
> > > > >> Wait this doesn't happen automatically!? I thought way-back-when
> > > > >someone
> > > > >> wrote a script to automatically close the JIRA tickets (maybe that
> > > > >script
> > > > >> is not run when changes are merged via the UI). My apologies, will
> > > > >close
> > > > >> JIRAs in the future, I don't think I've closed any JIRA tickets
> > > > >manually.
> > > > >>
> > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > > ><Ja...@polidea.com>
> > > > >> wrote:
> > > > >>
> > > > >> > And yes. I was one of the culprits - I saw :(. Sorry about that
> > > > >Kaxil.
> > > > >> > Just hope we can streamline this :).
> > > > >> >
> > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > > ><Ja...@polidea.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Heartily agree with it !
> > > > >> > >
> > > > >> > > I try always to close the PRs but sometimes I got distracted
> and
> > > > >forget
> > > > >> > to
> > > > >> > > resolve an issue - it happend several times that I recalled it
> > > > >few
> > > > >> hours
> > > > >> > > later that I have forgotten to resolve it. I hope it happens
> > > > >rarely -
> > > > >> I'd
> > > > >> > > love to know if I was one of the culprits here :). And
> whenever
> > I
> > > > >> noticed
> > > > >> > > some of the PRs are not closed but PR is merged by someone
> else
> > -
> > > > >I
> > > > >> > > sometimes close them. But it's not ideal of course.
> > > > >> > >
> > > > >> > > However simple it is - I think we are just humans and we will
> > > > >forget
> > > > >> from
> > > > >> > > time to time. I was wondering if we can (yes, you guessed it)
> > > > >automate
> > > > >> it
> > > > >> > > :). Either with JIRA/Github integration or some automated tool
> > to
> > > > >do it
> > > > >> > > regularly and resolving all already merged tickets. And the
> more
> > > > >> > > committers we are going to have, the more it makes sense to
> > > > >automate
> > > > >> some
> > > > >> > > of the work. The less you have to remember about your "chores"
> > > > >the more
> > > > >> > you
> > > > >> > > can focus on the "real" stuff.
> > > > >> > >
> > > > >> > > I think there are a few unwritten rules that we have - like
> what
> > > > >> version
> > > > >> > > to set when we cherry-pick change to 1.10* . My understanding
> is
> > > > >that
> > > > >> we
> > > > >> > > should set fixed version to the first unreleased yet 1.10.
> > > > >version.
> > > > >> This
> > > > >> > > problem will soon be gone, so maybe it's not worth solving it.
> > > > >There
> > > > >> are
> > > > >> > > also some edge cases like bad fixes which got reverted and
> > > > >reapplied
> > > > >> but
> > > > >> > I
> > > > >> > > think other than that the automation of it can be rather
> simple.
> > > > >> > >
> > > > >> > > And I think there are some scripts in "dev" that already do
> some
> > > > >of
> > > > >> that
> > > > >> > -
> > > > >> > > synchronising merges with JIRAs (but I don't think it's common
> > > > >> knowledge
> > > > >> > > and it's not regularly run). Maybe we can improve it somehow
> and
> > > > >have
> > > > >> it
> > > > >> > > fully automated so that we do not even havet to think about
> it ?
> > > > >> > >
> > > > >> > > WDYT? Any ideas?
> > > > >> > >
> > > > >> > > J.
> > > > >> > >
> > > > >> > >
> > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <
> kaxilnaik@gmail.com
> > >
> > > > >> wrote:
> > > > >> > >
> > > > >> > >> We have some at
> > > > >> > >>
> > > > >>
> > > > >
> > https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > > >> > >>
> > > > >> > >> The person who merges the PR to master is the one who would
> be
> > > > >> > responsible
> > > > >> > >> for resolving the JIRA issue as they can add the *target
> > > > >version*
> > > > >> based
> > > > >> > on
> > > > >> > >> what they think after reviewing the PR.
> > > > >> > >>
> > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > > > >> > >> aizhamal@apache.org>
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >> > I think it will be good to document the process. For
> example,
> > > > >who is
> > > > >> > >> > responsible for closing Jira issues: folks who closed PR's
> or
> > > > >the
> > > > >> ones
> > > > >> > >> who
> > > > >> > >> > opened?
> > > > >> > >> >
> > > > >> > >> > If the documentation already exists, let's bring it back to
> > > > >> attention.
> > > > >> > >> >
> > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > > ><ka...@gmail.com>
> > > > >> > wrote:
> > > > >> > >> >
> > > > >> > >> > > Hi Committers,
> > > > >> > >> > >
> > > > >> > >> > > Please make sure to close the Jira issues if the related
> > PRs
> > > > >are
> > > > >> > >> merged.
> > > > >> > >> > >
> > > > >> > >> > > I am going through the Jira Reports (Image:
> > > > >> > https://imgur.com/n50Ticx
> > > > >> > >> )
> > > > >> > >> > and
> > > > >> > >> > > was concerned with the gap between issues created &
> > resolved
> > > > >in
> > > > >> > recent
> > > > >> > >> > > months.
> > > > >> > >> > >
> > > > >> > >> > > However, I noticed while going through the jira issues
> that
> > > > >most
> > > > >> of
> > > > >> > >> the
> > > > >> > >> > PRs
> > > > >> > >> > > related to the JIRAs have been resolved but the JIRA is
> not
> > > > >> > resolved.
> > > > >> > >> > >
> > > > >> > >> > > Let's try to resolve all the issues when we merge the PR
> :)
> > > > >> > >> > >
> > > > >> > >> > > This will help the release manager too.
> > > > >> > >> > >
> > > > >> > >> > > Regards,
> > > > >> > >> > > Kaxil
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > >
> > > > >> > > Jarek Potiuk
> > > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > >> > >
> > > > >> > > M: +48 660 796 129 <+48660796129>
> > > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Jarek Potiuk
> > > > >> > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > > >> >
> > > > >> > M: +48 660 796 129 <+48660796129>
> > > > >> > [image: Polidea] <https://www.polidea.com/>
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >--
> > > > >
> > > > >Tomasz Urbaszek
> > > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > >
> > > > >M: +48 505 628 493 <+48505628493>
> > > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > >
> > > > >Unique Tech
> > > > >Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> > >
> > > --
> > >
> > > Tomasz Urbaszek
> > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >
> > > M: +48 505 628 493 <+48505628493>
> > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >
> > > Unique Tech
> > > Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: Closing JIRA Issue for Merged PRs

[Maxime Beauchemin <ma...@gmail.com>]

Quick note as I'm playing with Probot for Superset. It's possible to catch
all sorts of Github event and trigger all sorts of side effects with it.

On the Superset side we're looking to enable automation around Github
comments and labeling. It's also offers potential around enabling people
(PMs, contributors) without write access to the repo to create
labels, assign tasks, ...

More about it here:
https://probot.github.io/

Max

On Mon, Nov 18, 2019 at 2:14 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> Agree that Github issue are nicely integrated with the code, I don't
> particularly mind which issue tracking system I use as long as it has good
> integration.
>
> The nice part about github issues that now with github actions we could
> automate more and have full control over it. And a lot of this works
> automagically (Fixes #NN) closes the issue when merged.
>
> On the other hand It is very limiting. I see it would have been difficult
> to follow the cherry-picking workflow where we decide after the merge if we
> want to cherry-pick or not. Issue can belong to only one milestone - so
> then we'd have to start messing around with labels etc. I don't have
> particularly strong feelings about moving out of JIRA and I think the
> benefits are very small compared to the hassle of changing.
>
> There is a lot of "boring" work in the commiter's live - mostly connected
> with reviewing list of issues in one of the systems (sometimes many times
> over) and reacting somehow. I think it would be much more enjoyable if we
> had - even manually driven -  some automation in place for that. I think
> about a small but well-rounded tool that could help with managing state of
> the several different system we use.
>
> I'd love a small "committer" CLI that we will be able to query the state of
> the issues and use it to perform particular tasks - i.e. checking the list
> of open issues assigned to me, issues that I have recently interacted with,
> issues that are in the area of my interest - viewable and discoverable via
> the CLI, and then manageable from the same CLI. I'd love for example to see
> all the issues that I already merged but they are not resolved yet. Or all
> the issues for which build failed recently but they are likely transient
> rebuilds etc. etc. Something that could be a small (CLI) dashboard for all
> the committers where all the typical use-cases for the committers are
> automated. This way we could not only make our life easier but also we
> could start promoting some good committer practices, and we could introduce
> some more sophisticated strategies for dealing with issues (vs. current
> anyone does anything strategy). For example sharing the issues between
> committers, auto-assigning reviewers etc. etc. Of course this can all be
> done without such tool, but that would be far less fun if those are
> "written down" and "manually followed" processes rather than automated
> ones.
>
> And of course  myself or anyone could develop such tool myself - but it's
> quite an effort and I think it would only pay off if the effort could be
> divided by a number of people contributing, but benefits multiplied by a
> number of people using it :).
>
> As we will have more committers (hopefully) we might have more need for
> such tool. Is this a good time to start thinking about it?
>
> J.
>
> On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com> wrote:
>
> > On a slightly irrelevant note, do we ever close tickets as
> non-reproducable
> > or will-not-fix?
> > Last time I was going through open tickets I found dozens that seemed
> > really old, really not-gonna-happen or already fixed.
> > What actions could we take to decrease this gap?
> > WDYT?
> >
> > S.
> >
> > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com
> > >
> > wrote:
> >
> > > I can agree that GitHub issues may get spammy but I other projects deal
> > > with it somehow. And as a user I like the simplicity of creating an
> > issue.
> > > As per Jira, I think a good part of it is the ability to link issues
> > across
> > > different ASF project (but I don't think it's a killer feature).
> > >
> > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> > wrote:
> > >
> > > > I don’t like Jira particularly but I like GitHub issues even less.
> Both
> > > > don’t feel right. And yes GitHub issues get spammy very quickly. The
> > > hurdle
> > > > gets so low that it functions as an alternative to the mailing list,
> > far,
> > > > and chat.
> > > >
> > > >
> > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> > > wrote:
> > > >
> > > > Getting creds for Jira might be tricky, though Infra may have some
> way
> > of
> > > > resolving issues when PR is merged (please don't Close, only ever
> > Resolve
> > > > as closed issues can't have FixVersion changed)
> > > >
> > > > This brings me on to another question: what do were actual use Jira
> for
> > > > that couldn't (or shouldn't) be done with GitHub Issues?
> > > >
> > > > The main thing I can think of right now is the Fix version when
> > resolving
> > > > to say when we should backport a PR, but this could be achieved with
> > > > Milestones in GitHub.
> > > >
> > > > (A fringe benefit is that most people won't have an ASF Jira account
> so
> > > > opening issues to ask questions is harder. "Benefit" as it avoids
> issue
> > > > spam for question.)
> > > >
> > > > Is there anything else?
> > > >
> > > > -A
> > > >
> > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > > tomasz.urbaszek@polidea.com> wrote:
> > > > >Is there any possibility to use GitHub actions for that?
> > > > >For example, the one that allows to "Automatically transition an
> issue
> > > > >to
> > > > >done when a pull request whose name contains the issue key is
> merged"?
> > > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > > >
> > > > >Bests,
> > > > >Tomek
> > > > >
> > > > >
> > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> > > > >wrote:
> > > > >
> > > > >> I wrote that script. It’s cli only unfortunately.
> > > > >>
> > > > >>
> > > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > > >(ddavydov@twitter.com.invalid
> > > > >> )
> > > > >> wrote:
> > > > >>
> > > > >> Wait this doesn't happen automatically!? I thought way-back-when
> > > > >someone
> > > > >> wrote a script to automatically close the JIRA tickets (maybe that
> > > > >script
> > > > >> is not run when changes are merged via the UI). My apologies, will
> > > > >close
> > > > >> JIRAs in the future, I don't think I've closed any JIRA tickets
> > > > >manually.
> > > > >>
> > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > > ><Ja...@polidea.com>
> > > > >> wrote:
> > > > >>
> > > > >> > And yes. I was one of the culprits - I saw :(. Sorry about that
> > > > >Kaxil.
> > > > >> > Just hope we can streamline this :).
> > > > >> >
> > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > > ><Ja...@polidea.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Heartily agree with it !
> > > > >> > >
> > > > >> > > I try always to close the PRs but sometimes I got distracted
> and
> > > > >forget
> > > > >> > to
> > > > >> > > resolve an issue - it happend several times that I recalled it
> > > > >few
> > > > >> hours
> > > > >> > > later that I have forgotten to resolve it. I hope it happens
> > > > >rarely -
> > > > >> I'd
> > > > >> > > love to know if I was one of the culprits here :). And
> whenever
> > I
> > > > >> noticed
> > > > >> > > some of the PRs are not closed but PR is merged by someone
> else
> > -
> > > > >I
> > > > >> > > sometimes close them. But it's not ideal of course.
> > > > >> > >
> > > > >> > > However simple it is - I think we are just humans and we will
> > > > >forget
> > > > >> from
> > > > >> > > time to time. I was wondering if we can (yes, you guessed it)
> > > > >automate
> > > > >> it
> > > > >> > > :). Either with JIRA/Github integration or some automated tool
> > to
> > > > >do it
> > > > >> > > regularly and resolving all already merged tickets. And the
> more
> > > > >> > > committers we are going to have, the more it makes sense to
> > > > >automate
> > > > >> some
> > > > >> > > of the work. The less you have to remember about your "chores"
> > > > >the more
> > > > >> > you
> > > > >> > > can focus on the "real" stuff.
> > > > >> > >
> > > > >> > > I think there are a few unwritten rules that we have - like
> what
> > > > >> version
> > > > >> > > to set when we cherry-pick change to 1.10* . My understanding
> is
> > > > >that
> > > > >> we
> > > > >> > > should set fixed version to the first unreleased yet 1.10.
> > > > >version.
> > > > >> This
> > > > >> > > problem will soon be gone, so maybe it's not worth solving it.
> > > > >There
> > > > >> are
> > > > >> > > also some edge cases like bad fixes which got reverted and
> > > > >reapplied
> > > > >> but
> > > > >> > I
> > > > >> > > think other than that the automation of it can be rather
> simple.
> > > > >> > >
> > > > >> > > And I think there are some scripts in "dev" that already do
> some
> > > > >of
> > > > >> that
> > > > >> > -
> > > > >> > > synchronising merges with JIRAs (but I don't think it's common
> > > > >> knowledge
> > > > >> > > and it's not regularly run). Maybe we can improve it somehow
> and
> > > > >have
> > > > >> it
> > > > >> > > fully automated so that we do not even havet to think about
> it ?
> > > > >> > >
> > > > >> > > WDYT? Any ideas?
> > > > >> > >
> > > > >> > > J.
> > > > >> > >
> > > > >> > >
> > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <
> kaxilnaik@gmail.com
> > >
> > > > >> wrote:
> > > > >> > >
> > > > >> > >> We have some at
> > > > >> > >>
> > > > >>
> > > > >
> > https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > > >> > >>
> > > > >> > >> The person who merges the PR to master is the one who would
> be
> > > > >> > responsible
> > > > >> > >> for resolving the JIRA issue as they can add the *target
> > > > >version*
> > > > >> based
> > > > >> > on
> > > > >> > >> what they think after reviewing the PR.
> > > > >> > >>
> > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > > > >> > >> aizhamal@apache.org>
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >> > I think it will be good to document the process. For
> example,
> > > > >who is
> > > > >> > >> > responsible for closing Jira issues: folks who closed PR's
> or
> > > > >the
> > > > >> ones
> > > > >> > >> who
> > > > >> > >> > opened?
> > > > >> > >> >
> > > > >> > >> > If the documentation already exists, let's bring it back to
> > > > >> attention.
> > > > >> > >> >
> > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > > ><ka...@gmail.com>
> > > > >> > wrote:
> > > > >> > >> >
> > > > >> > >> > > Hi Committers,
> > > > >> > >> > >
> > > > >> > >> > > Please make sure to close the Jira issues if the related
> > PRs
> > > > >are
> > > > >> > >> merged.
> > > > >> > >> > >
> > > > >> > >> > > I am going through the Jira Reports (Image:
> > > > >> > https://imgur.com/n50Ticx
> > > > >> > >> )
> > > > >> > >> > and
> > > > >> > >> > > was concerned with the gap between issues created &
> > resolved
> > > > >in
> > > > >> > recent
> > > > >> > >> > > months.
> > > > >> > >> > >
> > > > >> > >> > > However, I noticed while going through the jira issues
> that
> > > > >most
> > > > >> of
> > > > >> > >> the
> > > > >> > >> > PRs
> > > > >> > >> > > related to the JIRAs have been resolved but the JIRA is
> not
> > > > >> > resolved.
> > > > >> > >> > >
> > > > >> > >> > > Let's try to resolve all the issues when we merge the PR
> :)
> > > > >> > >> > >
> > > > >> > >> > > This will help the release manager too.
> > > > >> > >> > >
> > > > >> > >> > > Regards,
> > > > >> > >> > > Kaxil
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > >
> > > > >> > > Jarek Potiuk
> > > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > >> > >
> > > > >> > > M: +48 660 796 129 <+48660796129>
> > > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Jarek Potiuk
> > > > >> > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > > >> >
> > > > >> > M: +48 660 796 129 <+48660796129>
> > > > >> > [image: Polidea] <https://www.polidea.com/>
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >--
> > > > >
> > > > >Tomasz Urbaszek
> > > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > >
> > > > >M: +48 505 628 493 <+48505628493>
> > > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > >
> > > > >Unique Tech
> > > > >Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> > >
> > > --
> > >
> > > Tomasz Urbaszek
> > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >
> > > M: +48 505 628 493 <+48505628493>
> > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >
> > > Unique Tech
> > > Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: Closing JIRA Issue for Merged PRs

[Kaxil Naik <ka...@gmail.com>]

Thanks, Imran for pointing out to the script you guys use, we will surely
have a look.



On Tue, Nov 19, 2019 at 2:10 PM Imran Rashid <im...@gmail.com> wrote:

> Hi,
>
> I'm mostly just a lurker here but I thought I'd point out the scripts we
> use for spark:
>
> https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py
>
> It makes it easy to standardize format of commit msgs, merge to multiple
> branches, and update jira.  Every once in a while, somebody has to update
> those scripts as an API or auth method changes somewhere, or we change the
> way we want to format things.  So only useful if you're willing to invest
> in the scripts too.
>
> Hope this helps,
> Imran
>
> On Tue, Nov 19, 2019, 7:31 AM Ash Berlin-Taylor <as...@apache.org> wrote:
>
> > https://github.com/go-jira/jira <https://github.com/go-jira/jira> with
> > some careful scripting would go some way to doing this. There are also a
> > few scripts in the dev/ folder of the repo.
> >
> > An example of a command I used in the last release:
> >
> >     jira list -t list-fix -q "Key IN ($(git log --oneline --format='%s'
> > 1.10.5...HEAD | grep -vi 'AIRFLOW-XXX' | grep -i 'AIRFLOW-' | perl -pe
> > 's/.*(AIRFLOW-\d+).*/\U$1/i' | paste -s -d , -)) AND (fixVersion not in
> > ("1.10.6") OR fixVersion is null)"
> >
> > (This was to find commits in my branch since 1.10.5 that weren't yet
> > marked for fix in 1.10.6. It was never 100% accurate, but was close;
> >
> > -a
> >
> > > On 18 Nov 2019, at 22:14, Jarek Potiuk <Ja...@polidea.com>
> wrote:
> > >
> > > Agree that Github issue are nicely integrated with the code, I don't
> > > particularly mind which issue tracking system I use as long as it has
> > good
> > > integration.
> > >
> > > The nice part about github issues that now with github actions we could
> > > automate more and have full control over it. And a lot of this works
> > > automagically (Fixes #NN) closes the issue when merged.
> > >
> > > On the other hand It is very limiting. I see it would have been
> difficult
> > > to follow the cherry-picking workflow where we decide after the merge
> if
> > we
> > > want to cherry-pick or not. Issue can belong to only one milestone - so
> > > then we'd have to start messing around with labels etc. I don't have
> > > particularly strong feelings about moving out of JIRA and I think the
> > > benefits are very small compared to the hassle of changing.
> > >
> > > There is a lot of "boring" work in the commiter's live - mostly
> connected
> > > with reviewing list of issues in one of the systems (sometimes many
> times
> > > over) and reacting somehow. I think it would be much more enjoyable if
> we
> > > had - even manually driven -  some automation in place for that. I
> think
> > > about a small but well-rounded tool that could help with managing state
> > of
> > > the several different system we use.
> > >
> > > I'd love a small "committer" CLI that we will be able to query the
> state
> > of
> > > the issues and use it to perform particular tasks - i.e. checking the
> > list
> > > of open issues assigned to me, issues that I have recently interacted
> > with,
> > > issues that are in the area of my interest - viewable and discoverable
> > via
> > > the CLI, and then manageable from the same CLI. I'd love for example to
> > see
> > > all the issues that I already merged but they are not resolved yet. Or
> > all
> > > the issues for which build failed recently but they are likely
> transient
> > > rebuilds etc. etc. Something that could be a small (CLI) dashboard for
> > all
> > > the committers where all the typical use-cases for the committers are
> > > automated. This way we could not only make our life easier but also we
> > > could start promoting some good committer practices, and we could
> > introduce
> > > some more sophisticated strategies for dealing with issues (vs. current
> > > anyone does anything strategy). For example sharing the issues between
> > > committers, auto-assigning reviewers etc. etc. Of course this can all
> be
> > > done without such tool, but that would be far less fun if those are
> > > "written down" and "manually followed" processes rather than automated
> > ones.
> > >
> > > And of course  myself or anyone could develop such tool myself - but
> it's
> > > quite an effort and I think it would only pay off if the effort could
> be
> > > divided by a number of people contributing, but benefits multiplied by
> a
> > > number of people using it :).
> > >
> > > As we will have more committers (hopefully) we might have more need for
> > > such tool. Is this a good time to start thinking about it?
> > >
> > > J.
> > >
> > > On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com>
> wrote:
> > >
> > >> On a slightly irrelevant note, do we ever close tickets as
> > non-reproducable
> > >> or will-not-fix?
> > >> Last time I was going through open tickets I found dozens that seemed
> > >> really old, really not-gonna-happen or already fixed.
> > >> What actions could we take to decrease this gap?
> > >> WDYT?
> > >>
> > >> S.
> > >>
> > >> On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> > tomasz.urbaszek@polidea.com
> > >>>
> > >> wrote:
> > >>
> > >>> I can agree that GitHub issues may get spammy but I other projects
> deal
> > >>> with it somehow. And as a user I like the simplicity of creating an
> > >> issue.
> > >>> As per Jira, I think a good part of it is the ability to link issues
> > >> across
> > >>> different ASF project (but I don't think it's a killer feature).
> > >>>
> > >>> On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> > >> wrote:
> > >>>
> > >>>> I don’t like Jira particularly but I like GitHub issues even less.
> > Both
> > >>>> don’t feel right. And yes GitHub issues get spammy very quickly. The
> > >>> hurdle
> > >>>> gets so low that it functions as an alternative to the mailing list,
> > >> far,
> > >>>> and chat.
> > >>>>
> > >>>>
> > >>>> On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> > >>> wrote:
> > >>>>
> > >>>> Getting creds for Jira might be tricky, though Infra may have some
> way
> > >> of
> > >>>> resolving issues when PR is merged (please don't Close, only ever
> > >> Resolve
> > >>>> as closed issues can't have FixVersion changed)
> > >>>>
> > >>>> This brings me on to another question: what do were actual use Jira
> > for
> > >>>> that couldn't (or shouldn't) be done with GitHub Issues?
> > >>>>
> > >>>> The main thing I can think of right now is the Fix version when
> > >> resolving
> > >>>> to say when we should backport a PR, but this could be achieved with
> > >>>> Milestones in GitHub.
> > >>>>
> > >>>> (A fringe benefit is that most people won't have an ASF Jira account
> > so
> > >>>> opening issues to ask questions is harder. "Benefit" as it avoids
> > issue
> > >>>> spam for question.)
> > >>>>
> > >>>> Is there anything else?
> > >>>>
> > >>>> -A
> > >>>>
> > >>>> On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > >>>> tomasz.urbaszek@polidea.com> wrote:
> > >>>>> Is there any possibility to use GitHub actions for that?
> > >>>>> For example, the one that allows to "Automatically transition an
> > issue
> > >>>>> to
> > >>>>> done when a pull request whose name contains the issue key is
> > merged"?
> > >>>>> Here is Atlassian repo: https://github.com/atlassian/gajira
> > >>>>>
> > >>>>> Bests,
> > >>>>> Tomek
> > >>>>>
> > >>>>>
> > >>>>> On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> I wrote that script. It’s cli only unfortunately.
> > >>>>>>
> > >>>>>>
> > >>>>>> On 18 November 2019 at 18:22:04, Dan Davydov
> > >>>>> (ddavydov@twitter.com.invalid
> > >>>>>> )
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>> Wait this doesn't happen automatically!? I thought way-back-when
> > >>>>> someone
> > >>>>>> wrote a script to automatically close the JIRA tickets (maybe that
> > >>>>> script
> > >>>>>> is not run when changes are merged via the UI). My apologies, will
> > >>>>> close
> > >>>>>> JIRAs in the future, I don't think I've closed any JIRA tickets
> > >>>>> manually.
> > >>>>>>
> > >>>>>> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > >>>>> <Ja...@polidea.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> And yes. I was one of the culprits - I saw :(. Sorry about that
> > >>>>> Kaxil.
> > >>>>>>> Just hope we can streamline this :).
> > >>>>>>>
> > >>>>>>> On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > >>>>> <Ja...@polidea.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Heartily agree with it !
> > >>>>>>>>
> > >>>>>>>> I try always to close the PRs but sometimes I got distracted and
> > >>>>> forget
> > >>>>>>> to
> > >>>>>>>> resolve an issue - it happend several times that I recalled it
> > >>>>> few
> > >>>>>> hours
> > >>>>>>>> later that I have forgotten to resolve it. I hope it happens
> > >>>>> rarely -
> > >>>>>> I'd
> > >>>>>>>> love to know if I was one of the culprits here :). And whenever
> > >> I
> > >>>>>> noticed
> > >>>>>>>> some of the PRs are not closed but PR is merged by someone else
> > >> -
> > >>>>> I
> > >>>>>>>> sometimes close them. But it's not ideal of course.
> > >>>>>>>>
> > >>>>>>>> However simple it is - I think we are just humans and we will
> > >>>>> forget
> > >>>>>> from
> > >>>>>>>> time to time. I was wondering if we can (yes, you guessed it)
> > >>>>> automate
> > >>>>>> it
> > >>>>>>>> :). Either with JIRA/Github integration or some automated tool
> > >> to
> > >>>>> do it
> > >>>>>>>> regularly and resolving all already merged tickets. And the more
> > >>>>>>>> committers we are going to have, the more it makes sense to
> > >>>>> automate
> > >>>>>> some
> > >>>>>>>> of the work. The less you have to remember about your "chores"
> > >>>>> the more
> > >>>>>>> you
> > >>>>>>>> can focus on the "real" stuff.
> > >>>>>>>>
> > >>>>>>>> I think there are a few unwritten rules that we have - like what
> > >>>>>> version
> > >>>>>>>> to set when we cherry-pick change to 1.10* . My understanding is
> > >>>>> that
> > >>>>>> we
> > >>>>>>>> should set fixed version to the first unreleased yet 1.10.
> > >>>>> version.
> > >>>>>> This
> > >>>>>>>> problem will soon be gone, so maybe it's not worth solving it.
> > >>>>> There
> > >>>>>> are
> > >>>>>>>> also some edge cases like bad fixes which got reverted and
> > >>>>> reapplied
> > >>>>>> but
> > >>>>>>> I
> > >>>>>>>> think other than that the automation of it can be rather simple.
> > >>>>>>>>
> > >>>>>>>> And I think there are some scripts in "dev" that already do some
> > >>>>> of
> > >>>>>> that
> > >>>>>>> -
> > >>>>>>>> synchronising merges with JIRAs (but I don't think it's common
> > >>>>>> knowledge
> > >>>>>>>> and it's not regularly run). Maybe we can improve it somehow and
> > >>>>> have
> > >>>>>> it
> > >>>>>>>> fully automated so that we do not even havet to think about it ?
> > >>>>>>>>
> > >>>>>>>> WDYT? Any ideas?
> > >>>>>>>>
> > >>>>>>>> J.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <kaxilnaik@gmail.com
> > >>>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> We have some at
> > >>>>>>>>>
> > >>>>>>
> > >>>>>
> > >>
> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > >>>>>>>>>
> > >>>>>>>>> The person who merges the PR to master is the one who would be
> > >>>>>>> responsible
> > >>>>>>>>> for resolving the JIRA issue as they can add the *target
> > >>>>> version*
> > >>>>>> based
> > >>>>>>> on
> > >>>>>>>>> what they think after reviewing the PR.
> > >>>>>>>>>
> > >>>>>>>>> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > >>>>>>>>> aizhamal@apache.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> I think it will be good to document the process. For example,
> > >>>>> who is
> > >>>>>>>>>> responsible for closing Jira issues: folks who closed PR's or
> > >>>>> the
> > >>>>>> ones
> > >>>>>>>>> who
> > >>>>>>>>>> opened?
> > >>>>>>>>>>
> > >>>>>>>>>> If the documentation already exists, let's bring it back to
> > >>>>>> attention.
> > >>>>>>>>>>
> > >>>>>>>>>> On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > >>>>> <ka...@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Hi Committers,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Please make sure to close the Jira issues if the related
> > >> PRs
> > >>>>> are
> > >>>>>>>>> merged.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I am going through the Jira Reports (Image:
> > >>>>>>> https://imgur.com/n50Ticx
> > >>>>>>>>> )
> > >>>>>>>>>> and
> > >>>>>>>>>>> was concerned with the gap between issues created &
> > >> resolved
> > >>>>> in
> > >>>>>>> recent
> > >>>>>>>>>>> months.
> > >>>>>>>>>>>
> > >>>>>>>>>>> However, I noticed while going through the jira issues that
> > >>>>> most
> > >>>>>> of
> > >>>>>>>>> the
> > >>>>>>>>>> PRs
> > >>>>>>>>>>> related to the JIRAs have been resolved but the JIRA is not
> > >>>>>>> resolved.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Let's try to resolve all the issues when we merge the PR :)
> > >>>>>>>>>>>
> > >>>>>>>>>>> This will help the release manager too.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Regards,
> > >>>>>>>>>>> Kaxil
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>>
> > >>>>>>>> Jarek Potiuk
> > >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > >> Engineer
> > >>>>>>>>
> > >>>>>>>> M: +48 660 796 129 <+48660796129>
> > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>>
> > >>>>>>> Jarek Potiuk
> > >>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>>>>>>
> > >>>>>>> M: +48 660 796 129 <+48660796129>
> > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>>
> > >>>>> Tomasz Urbaszek
> > >>>>> Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >>>>>
> > >>>>> M: +48 505 628 493 <+48505628493>
> > >>>>> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >>>>>
> > >>>>> Unique Tech
> > >>>>> Check out our projects! <https://www.polidea.com/our-work>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> Tomasz Urbaszek
> > >>> Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >>>
> > >>> M: +48 505 628 493 <+48505628493>
> > >>> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >>>
> > >>> Unique Tech
> > >>> Check out our projects! <https://www.polidea.com/our-work>
> > >>>
> > >>
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> >
> >
>

Re: Closing JIRA Issue for Merged PRs

[Imran Rashid <im...@gmail.com>]

Hi,

I'm mostly just a lurker here but I thought I'd point out the scripts we
use for spark:

https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py

It makes it easy to standardize format of commit msgs, merge to multiple
branches, and update jira.  Every once in a while, somebody has to update
those scripts as an API or auth method changes somewhere, or we change the
way we want to format things.  So only useful if you're willing to invest
in the scripts too.

Hope this helps,
Imran

On Tue, Nov 19, 2019, 7:31 AM Ash Berlin-Taylor <as...@apache.org> wrote:

> https://github.com/go-jira/jira <https://github.com/go-jira/jira> with
> some careful scripting would go some way to doing this. There are also a
> few scripts in the dev/ folder of the repo.
>
> An example of a command I used in the last release:
>
>     jira list -t list-fix -q "Key IN ($(git log --oneline --format='%s'
> 1.10.5...HEAD | grep -vi 'AIRFLOW-XXX' | grep -i 'AIRFLOW-' | perl -pe
> 's/.*(AIRFLOW-\d+).*/\U$1/i' | paste -s -d , -)) AND (fixVersion not in
> ("1.10.6") OR fixVersion is null)"
>
> (This was to find commits in my branch since 1.10.5 that weren't yet
> marked for fix in 1.10.6. It was never 100% accurate, but was close;
>
> -a
>
> > On 18 Nov 2019, at 22:14, Jarek Potiuk <Ja...@polidea.com> wrote:
> >
> > Agree that Github issue are nicely integrated with the code, I don't
> > particularly mind which issue tracking system I use as long as it has
> good
> > integration.
> >
> > The nice part about github issues that now with github actions we could
> > automate more and have full control over it. And a lot of this works
> > automagically (Fixes #NN) closes the issue when merged.
> >
> > On the other hand It is very limiting. I see it would have been difficult
> > to follow the cherry-picking workflow where we decide after the merge if
> we
> > want to cherry-pick or not. Issue can belong to only one milestone - so
> > then we'd have to start messing around with labels etc. I don't have
> > particularly strong feelings about moving out of JIRA and I think the
> > benefits are very small compared to the hassle of changing.
> >
> > There is a lot of "boring" work in the commiter's live - mostly connected
> > with reviewing list of issues in one of the systems (sometimes many times
> > over) and reacting somehow. I think it would be much more enjoyable if we
> > had - even manually driven -  some automation in place for that. I think
> > about a small but well-rounded tool that could help with managing state
> of
> > the several different system we use.
> >
> > I'd love a small "committer" CLI that we will be able to query the state
> of
> > the issues and use it to perform particular tasks - i.e. checking the
> list
> > of open issues assigned to me, issues that I have recently interacted
> with,
> > issues that are in the area of my interest - viewable and discoverable
> via
> > the CLI, and then manageable from the same CLI. I'd love for example to
> see
> > all the issues that I already merged but they are not resolved yet. Or
> all
> > the issues for which build failed recently but they are likely transient
> > rebuilds etc. etc. Something that could be a small (CLI) dashboard for
> all
> > the committers where all the typical use-cases for the committers are
> > automated. This way we could not only make our life easier but also we
> > could start promoting some good committer practices, and we could
> introduce
> > some more sophisticated strategies for dealing with issues (vs. current
> > anyone does anything strategy). For example sharing the issues between
> > committers, auto-assigning reviewers etc. etc. Of course this can all be
> > done without such tool, but that would be far less fun if those are
> > "written down" and "manually followed" processes rather than automated
> ones.
> >
> > And of course  myself or anyone could develop such tool myself - but it's
> > quite an effort and I think it would only pay off if the effort could be
> > divided by a number of people contributing, but benefits multiplied by a
> > number of people using it :).
> >
> > As we will have more committers (hopefully) we might have more need for
> > such tool. Is this a good time to start thinking about it?
> >
> > J.
> >
> > On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com> wrote:
> >
> >> On a slightly irrelevant note, do we ever close tickets as
> non-reproducable
> >> or will-not-fix?
> >> Last time I was going through open tickets I found dozens that seemed
> >> really old, really not-gonna-happen or already fixed.
> >> What actions could we take to decrease this gap?
> >> WDYT?
> >>
> >> S.
> >>
> >> On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com
> >>>
> >> wrote:
> >>
> >>> I can agree that GitHub issues may get spammy but I other projects deal
> >>> with it somehow. And as a user I like the simplicity of creating an
> >> issue.
> >>> As per Jira, I think a good part of it is the ability to link issues
> >> across
> >>> different ASF project (but I don't think it's a killer feature).
> >>>
> >>> On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> >> wrote:
> >>>
> >>>> I don’t like Jira particularly but I like GitHub issues even less.
> Both
> >>>> don’t feel right. And yes GitHub issues get spammy very quickly. The
> >>> hurdle
> >>>> gets so low that it functions as an alternative to the mailing list,
> >> far,
> >>>> and chat.
> >>>>
> >>>>
> >>>> On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> >>> wrote:
> >>>>
> >>>> Getting creds for Jira might be tricky, though Infra may have some way
> >> of
> >>>> resolving issues when PR is merged (please don't Close, only ever
> >> Resolve
> >>>> as closed issues can't have FixVersion changed)
> >>>>
> >>>> This brings me on to another question: what do were actual use Jira
> for
> >>>> that couldn't (or shouldn't) be done with GitHub Issues?
> >>>>
> >>>> The main thing I can think of right now is the Fix version when
> >> resolving
> >>>> to say when we should backport a PR, but this could be achieved with
> >>>> Milestones in GitHub.
> >>>>
> >>>> (A fringe benefit is that most people won't have an ASF Jira account
> so
> >>>> opening issues to ask questions is harder. "Benefit" as it avoids
> issue
> >>>> spam for question.)
> >>>>
> >>>> Is there anything else?
> >>>>
> >>>> -A
> >>>>
> >>>> On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> >>>> tomasz.urbaszek@polidea.com> wrote:
> >>>>> Is there any possibility to use GitHub actions for that?
> >>>>> For example, the one that allows to "Automatically transition an
> issue
> >>>>> to
> >>>>> done when a pull request whose name contains the issue key is
> merged"?
> >>>>> Here is Atlassian repo: https://github.com/atlassian/gajira
> >>>>>
> >>>>> Bests,
> >>>>> Tomek
> >>>>>
> >>>>>
> >>>>> On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I wrote that script. It’s cli only unfortunately.
> >>>>>>
> >>>>>>
> >>>>>> On 18 November 2019 at 18:22:04, Dan Davydov
> >>>>> (ddavydov@twitter.com.invalid
> >>>>>> )
> >>>>>> wrote:
> >>>>>>
> >>>>>> Wait this doesn't happen automatically!? I thought way-back-when
> >>>>> someone
> >>>>>> wrote a script to automatically close the JIRA tickets (maybe that
> >>>>> script
> >>>>>> is not run when changes are merged via the UI). My apologies, will
> >>>>> close
> >>>>>> JIRAs in the future, I don't think I've closed any JIRA tickets
> >>>>> manually.
> >>>>>>
> >>>>>> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> >>>>> <Ja...@polidea.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> And yes. I was one of the culprits - I saw :(. Sorry about that
> >>>>> Kaxil.
> >>>>>>> Just hope we can streamline this :).
> >>>>>>>
> >>>>>>> On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> >>>>> <Ja...@polidea.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Heartily agree with it !
> >>>>>>>>
> >>>>>>>> I try always to close the PRs but sometimes I got distracted and
> >>>>> forget
> >>>>>>> to
> >>>>>>>> resolve an issue - it happend several times that I recalled it
> >>>>> few
> >>>>>> hours
> >>>>>>>> later that I have forgotten to resolve it. I hope it happens
> >>>>> rarely -
> >>>>>> I'd
> >>>>>>>> love to know if I was one of the culprits here :). And whenever
> >> I
> >>>>>> noticed
> >>>>>>>> some of the PRs are not closed but PR is merged by someone else
> >> -
> >>>>> I
> >>>>>>>> sometimes close them. But it's not ideal of course.
> >>>>>>>>
> >>>>>>>> However simple it is - I think we are just humans and we will
> >>>>> forget
> >>>>>> from
> >>>>>>>> time to time. I was wondering if we can (yes, you guessed it)
> >>>>> automate
> >>>>>> it
> >>>>>>>> :). Either with JIRA/Github integration or some automated tool
> >> to
> >>>>> do it
> >>>>>>>> regularly and resolving all already merged tickets. And the more
> >>>>>>>> committers we are going to have, the more it makes sense to
> >>>>> automate
> >>>>>> some
> >>>>>>>> of the work. The less you have to remember about your "chores"
> >>>>> the more
> >>>>>>> you
> >>>>>>>> can focus on the "real" stuff.
> >>>>>>>>
> >>>>>>>> I think there are a few unwritten rules that we have - like what
> >>>>>> version
> >>>>>>>> to set when we cherry-pick change to 1.10* . My understanding is
> >>>>> that
> >>>>>> we
> >>>>>>>> should set fixed version to the first unreleased yet 1.10.
> >>>>> version.
> >>>>>> This
> >>>>>>>> problem will soon be gone, so maybe it's not worth solving it.
> >>>>> There
> >>>>>> are
> >>>>>>>> also some edge cases like bad fixes which got reverted and
> >>>>> reapplied
> >>>>>> but
> >>>>>>> I
> >>>>>>>> think other than that the automation of it can be rather simple.
> >>>>>>>>
> >>>>>>>> And I think there are some scripts in "dev" that already do some
> >>>>> of
> >>>>>> that
> >>>>>>> -
> >>>>>>>> synchronising merges with JIRAs (but I don't think it's common
> >>>>>> knowledge
> >>>>>>>> and it's not regularly run). Maybe we can improve it somehow and
> >>>>> have
> >>>>>> it
> >>>>>>>> fully automated so that we do not even havet to think about it ?
> >>>>>>>>
> >>>>>>>> WDYT? Any ideas?
> >>>>>>>>
> >>>>>>>> J.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <kaxilnaik@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> We have some at
> >>>>>>>>>
> >>>>>>
> >>>>>
> >> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> >>>>>>>>>
> >>>>>>>>> The person who merges the PR to master is the one who would be
> >>>>>>> responsible
> >>>>>>>>> for resolving the JIRA issue as they can add the *target
> >>>>> version*
> >>>>>> based
> >>>>>>> on
> >>>>>>>>> what they think after reviewing the PR.
> >>>>>>>>>
> >>>>>>>>> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> >>>>>>>>> aizhamal@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I think it will be good to document the process. For example,
> >>>>> who is
> >>>>>>>>>> responsible for closing Jira issues: folks who closed PR's or
> >>>>> the
> >>>>>> ones
> >>>>>>>>> who
> >>>>>>>>>> opened?
> >>>>>>>>>>
> >>>>>>>>>> If the documentation already exists, let's bring it back to
> >>>>>> attention.
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> >>>>> <ka...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Committers,
> >>>>>>>>>>>
> >>>>>>>>>>> Please make sure to close the Jira issues if the related
> >> PRs
> >>>>> are
> >>>>>>>>> merged.
> >>>>>>>>>>>
> >>>>>>>>>>> I am going through the Jira Reports (Image:
> >>>>>>> https://imgur.com/n50Ticx
> >>>>>>>>> )
> >>>>>>>>>> and
> >>>>>>>>>>> was concerned with the gap between issues created &
> >> resolved
> >>>>> in
> >>>>>>> recent
> >>>>>>>>>>> months.
> >>>>>>>>>>>
> >>>>>>>>>>> However, I noticed while going through the jira issues that
> >>>>> most
> >>>>>> of
> >>>>>>>>> the
> >>>>>>>>>> PRs
> >>>>>>>>>>> related to the JIRAs have been resolved but the JIRA is not
> >>>>>>> resolved.
> >>>>>>>>>>>
> >>>>>>>>>>> Let's try to resolve all the issues when we merge the PR :)
> >>>>>>>>>>>
> >>>>>>>>>>> This will help the release manager too.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Kaxil
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> Jarek Potiuk
> >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> >> Engineer
> >>>>>>>>
> >>>>>>>> M: +48 660 796 129 <+48660796129>
> >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Jarek Potiuk
> >>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> >>>>>>>
> >>>>>>> M: +48 660 796 129 <+48660796129>
> >>>>>>> [image: Polidea] <https://www.polidea.com/>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Tomasz Urbaszek
> >>>>> Polidea <https://www.polidea.com/> | Junior Software Engineer
> >>>>>
> >>>>> M: +48 505 628 493 <+48505628493>
> >>>>> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >>>>>
> >>>>> Unique Tech
> >>>>> Check out our projects! <https://www.polidea.com/our-work>
> >>>>
> >>>
> >>>
> >>> --
> >>>
> >>> Tomasz Urbaszek
> >>> Polidea <https://www.polidea.com/> | Junior Software Engineer
> >>>
> >>> M: +48 505 628 493 <+48505628493>
> >>> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >>>
> >>> Unique Tech
> >>> Check out our projects! <https://www.polidea.com/our-work>
> >>>
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
>
>

Re: Closing JIRA Issue for Merged PRs

[Ash Berlin-Taylor <as...@apache.org>]

https://github.com/go-jira/jira <https://github.com/go-jira/jira> with some careful scripting would go some way to doing this. There are also a few scripts in the dev/ folder of the repo.

An example of a command I used in the last release:

    jira list -t list-fix -q "Key IN ($(git log --oneline --format='%s' 1.10.5...HEAD | grep -vi 'AIRFLOW-XXX' | grep -i 'AIRFLOW-' | perl -pe 's/.*(AIRFLOW-\d+).*/\U$1/i' | paste -s -d , -)) AND (fixVersion not in ("1.10.6") OR fixVersion is null)"

(This was to find commits in my branch since 1.10.5 that weren't yet marked for fix in 1.10.6. It was never 100% accurate, but was close;

-a

> On 18 Nov 2019, at 22:14, Jarek Potiuk <Ja...@polidea.com> wrote:
> 
> Agree that Github issue are nicely integrated with the code, I don't
> particularly mind which issue tracking system I use as long as it has good
> integration.
> 
> The nice part about github issues that now with github actions we could
> automate more and have full control over it. And a lot of this works
> automagically (Fixes #NN) closes the issue when merged.
> 
> On the other hand It is very limiting. I see it would have been difficult
> to follow the cherry-picking workflow where we decide after the merge if we
> want to cherry-pick or not. Issue can belong to only one milestone - so
> then we'd have to start messing around with labels etc. I don't have
> particularly strong feelings about moving out of JIRA and I think the
> benefits are very small compared to the hassle of changing.
> 
> There is a lot of "boring" work in the commiter's live - mostly connected
> with reviewing list of issues in one of the systems (sometimes many times
> over) and reacting somehow. I think it would be much more enjoyable if we
> had - even manually driven -  some automation in place for that. I think
> about a small but well-rounded tool that could help with managing state of
> the several different system we use.
> 
> I'd love a small "committer" CLI that we will be able to query the state of
> the issues and use it to perform particular tasks - i.e. checking the list
> of open issues assigned to me, issues that I have recently interacted with,
> issues that are in the area of my interest - viewable and discoverable via
> the CLI, and then manageable from the same CLI. I'd love for example to see
> all the issues that I already merged but they are not resolved yet. Or all
> the issues for which build failed recently but they are likely transient
> rebuilds etc. etc. Something that could be a small (CLI) dashboard for all
> the committers where all the typical use-cases for the committers are
> automated. This way we could not only make our life easier but also we
> could start promoting some good committer practices, and we could introduce
> some more sophisticated strategies for dealing with issues (vs. current
> anyone does anything strategy). For example sharing the issues between
> committers, auto-assigning reviewers etc. etc. Of course this can all be
> done without such tool, but that would be far less fun if those are
> "written down" and "manually followed" processes rather than automated ones.
> 
> And of course  myself or anyone could develop such tool myself - but it's
> quite an effort and I think it would only pay off if the effort could be
> divided by a number of people contributing, but benefits multiplied by a
> number of people using it :).
> 
> As we will have more committers (hopefully) we might have more need for
> such tool. Is this a good time to start thinking about it?
> 
> J.
> 
> On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com> wrote:
> 
>> On a slightly irrelevant note, do we ever close tickets as non-reproducable
>> or will-not-fix?
>> Last time I was going through open tickets I found dozens that seemed
>> really old, really not-gonna-happen or already fixed.
>> What actions could we take to decrease this gap?
>> WDYT?
>> 
>> S.
>> 
>> On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <tomasz.urbaszek@polidea.com
>>> 
>> wrote:
>> 
>>> I can agree that GitHub issues may get spammy but I other projects deal
>>> with it somehow. And as a user I like the simplicity of creating an
>> issue.
>>> As per Jira, I think a good part of it is the ability to link issues
>> across
>>> different ASF project (but I don't think it's a killer feature).
>>> 
>>> On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
>> wrote:
>>> 
>>>> I don’t like Jira particularly but I like GitHub issues even less. Both
>>>> don’t feel right. And yes GitHub issues get spammy very quickly. The
>>> hurdle
>>>> gets so low that it functions as an alternative to the mailing list,
>> far,
>>>> and chat.
>>>> 
>>>> 
>>>> On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
>>> wrote:
>>>> 
>>>> Getting creds for Jira might be tricky, though Infra may have some way
>> of
>>>> resolving issues when PR is merged (please don't Close, only ever
>> Resolve
>>>> as closed issues can't have FixVersion changed)
>>>> 
>>>> This brings me on to another question: what do were actual use Jira for
>>>> that couldn't (or shouldn't) be done with GitHub Issues?
>>>> 
>>>> The main thing I can think of right now is the Fix version when
>> resolving
>>>> to say when we should backport a PR, but this could be achieved with
>>>> Milestones in GitHub.
>>>> 
>>>> (A fringe benefit is that most people won't have an ASF Jira account so
>>>> opening issues to ask questions is harder. "Benefit" as it avoids issue
>>>> spam for question.)
>>>> 
>>>> Is there anything else?
>>>> 
>>>> -A
>>>> 
>>>> On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
>>>> tomasz.urbaszek@polidea.com> wrote:
>>>>> Is there any possibility to use GitHub actions for that?
>>>>> For example, the one that allows to "Automatically transition an issue
>>>>> to
>>>>> done when a pull request whose name contains the issue key is merged"?
>>>>> Here is Atlassian repo: https://github.com/atlassian/gajira
>>>>> 
>>>>> Bests,
>>>>> Tomek
>>>>> 
>>>>> 
>>>>> On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> I wrote that script. It’s cli only unfortunately.
>>>>>> 
>>>>>> 
>>>>>> On 18 November 2019 at 18:22:04, Dan Davydov
>>>>> (ddavydov@twitter.com.invalid
>>>>>> )
>>>>>> wrote:
>>>>>> 
>>>>>> Wait this doesn't happen automatically!? I thought way-back-when
>>>>> someone
>>>>>> wrote a script to automatically close the JIRA tickets (maybe that
>>>>> script
>>>>>> is not run when changes are merged via the UI). My apologies, will
>>>>> close
>>>>>> JIRAs in the future, I don't think I've closed any JIRA tickets
>>>>> manually.
>>>>>> 
>>>>>> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
>>>>> <Ja...@polidea.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> And yes. I was one of the culprits - I saw :(. Sorry about that
>>>>> Kaxil.
>>>>>>> Just hope we can streamline this :).
>>>>>>> 
>>>>>>> On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
>>>>> <Ja...@polidea.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Heartily agree with it !
>>>>>>>> 
>>>>>>>> I try always to close the PRs but sometimes I got distracted and
>>>>> forget
>>>>>>> to
>>>>>>>> resolve an issue - it happend several times that I recalled it
>>>>> few
>>>>>> hours
>>>>>>>> later that I have forgotten to resolve it. I hope it happens
>>>>> rarely -
>>>>>> I'd
>>>>>>>> love to know if I was one of the culprits here :). And whenever
>> I
>>>>>> noticed
>>>>>>>> some of the PRs are not closed but PR is merged by someone else
>> -
>>>>> I
>>>>>>>> sometimes close them. But it's not ideal of course.
>>>>>>>> 
>>>>>>>> However simple it is - I think we are just humans and we will
>>>>> forget
>>>>>> from
>>>>>>>> time to time. I was wondering if we can (yes, you guessed it)
>>>>> automate
>>>>>> it
>>>>>>>> :). Either with JIRA/Github integration or some automated tool
>> to
>>>>> do it
>>>>>>>> regularly and resolving all already merged tickets. And the more
>>>>>>>> committers we are going to have, the more it makes sense to
>>>>> automate
>>>>>> some
>>>>>>>> of the work. The less you have to remember about your "chores"
>>>>> the more
>>>>>>> you
>>>>>>>> can focus on the "real" stuff.
>>>>>>>> 
>>>>>>>> I think there are a few unwritten rules that we have - like what
>>>>>> version
>>>>>>>> to set when we cherry-pick change to 1.10* . My understanding is
>>>>> that
>>>>>> we
>>>>>>>> should set fixed version to the first unreleased yet 1.10.
>>>>> version.
>>>>>> This
>>>>>>>> problem will soon be gone, so maybe it's not worth solving it.
>>>>> There
>>>>>> are
>>>>>>>> also some edge cases like bad fixes which got reverted and
>>>>> reapplied
>>>>>> but
>>>>>>> I
>>>>>>>> think other than that the automation of it can be rather simple.
>>>>>>>> 
>>>>>>>> And I think there are some scripts in "dev" that already do some
>>>>> of
>>>>>> that
>>>>>>> -
>>>>>>>> synchronising merges with JIRAs (but I don't think it's common
>>>>>> knowledge
>>>>>>>> and it's not regularly run). Maybe we can improve it somehow and
>>>>> have
>>>>>> it
>>>>>>>> fully automated so that we do not even havet to think about it ?
>>>>>>>> 
>>>>>>>> WDYT? Any ideas?
>>>>>>>> 
>>>>>>>> J.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <kaxilnaik@gmail.com
>>> 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> We have some at
>>>>>>>>> 
>>>>>> 
>>>>> 
>> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
>>>>>>>>> 
>>>>>>>>> The person who merges the PR to master is the one who would be
>>>>>>> responsible
>>>>>>>>> for resolving the JIRA issue as they can add the *target
>>>>> version*
>>>>>> based
>>>>>>> on
>>>>>>>>> what they think after reviewing the PR.
>>>>>>>>> 
>>>>>>>>> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
>>>>>>>>> aizhamal@apache.org>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I think it will be good to document the process. For example,
>>>>> who is
>>>>>>>>>> responsible for closing Jira issues: folks who closed PR's or
>>>>> the
>>>>>> ones
>>>>>>>>> who
>>>>>>>>>> opened?
>>>>>>>>>> 
>>>>>>>>>> If the documentation already exists, let's bring it back to
>>>>>> attention.
>>>>>>>>>> 
>>>>>>>>>> On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
>>>>> <ka...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi Committers,
>>>>>>>>>>> 
>>>>>>>>>>> Please make sure to close the Jira issues if the related
>> PRs
>>>>> are
>>>>>>>>> merged.
>>>>>>>>>>> 
>>>>>>>>>>> I am going through the Jira Reports (Image:
>>>>>>> https://imgur.com/n50Ticx
>>>>>>>>> )
>>>>>>>>>> and
>>>>>>>>>>> was concerned with the gap between issues created &
>> resolved
>>>>> in
>>>>>>> recent
>>>>>>>>>>> months.
>>>>>>>>>>> 
>>>>>>>>>>> However, I noticed while going through the jira issues that
>>>>> most
>>>>>> of
>>>>>>>>> the
>>>>>>>>>> PRs
>>>>>>>>>>> related to the JIRAs have been resolved but the JIRA is not
>>>>>>> resolved.
>>>>>>>>>>> 
>>>>>>>>>>> Let's try to resolve all the issues when we merge the PR :)
>>>>>>>>>>> 
>>>>>>>>>>> This will help the release manager too.
>>>>>>>>>>> 
>>>>>>>>>>> Regards,
>>>>>>>>>>> Kaxil
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> Jarek Potiuk
>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
>> Engineer
>>>>>>>> 
>>>>>>>> M: +48 660 796 129 <+48660796129>
>>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> Jarek Potiuk
>>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>>>>>> 
>>>>>>> M: +48 660 796 129 <+48660796129>
>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Tomasz Urbaszek
>>>>> Polidea <https://www.polidea.com/> | Junior Software Engineer
>>>>> 
>>>>> M: +48 505 628 493 <+48505628493>
>>>>> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>>>>> 
>>>>> Unique Tech
>>>>> Check out our projects! <https://www.polidea.com/our-work>
>>>> 
>>> 
>>> 
>>> --
>>> 
>>> Tomasz Urbaszek
>>> Polidea <https://www.polidea.com/> | Junior Software Engineer
>>> 
>>> M: +48 505 628 493 <+48505628493>
>>> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>>> 
>>> Unique Tech
>>> Check out our projects! <https://www.polidea.com/our-work>
>>> 
>> 
> 
> 
> -- 
> 
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
> 
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>

Re: Closing JIRA Issue for Merged PRs

[Jarek Potiuk <Ja...@polidea.com>]

Agree that Github issue are nicely integrated with the code, I don't
particularly mind which issue tracking system I use as long as it has good
integration.

The nice part about github issues that now with github actions we could
automate more and have full control over it. And a lot of this works
automagically (Fixes #NN) closes the issue when merged.

On the other hand It is very limiting. I see it would have been difficult
to follow the cherry-picking workflow where we decide after the merge if we
want to cherry-pick or not. Issue can belong to only one milestone - so
then we'd have to start messing around with labels etc. I don't have
particularly strong feelings about moving out of JIRA and I think the
benefits are very small compared to the hassle of changing.

There is a lot of "boring" work in the commiter's live - mostly connected
with reviewing list of issues in one of the systems (sometimes many times
over) and reacting somehow. I think it would be much more enjoyable if we
had - even manually driven -  some automation in place for that. I think
about a small but well-rounded tool that could help with managing state of
the several different system we use.

I'd love a small "committer" CLI that we will be able to query the state of
the issues and use it to perform particular tasks - i.e. checking the list
of open issues assigned to me, issues that I have recently interacted with,
issues that are in the area of my interest - viewable and discoverable via
the CLI, and then manageable from the same CLI. I'd love for example to see
all the issues that I already merged but they are not resolved yet. Or all
the issues for which build failed recently but they are likely transient
rebuilds etc. etc. Something that could be a small (CLI) dashboard for all
the committers where all the typical use-cases for the committers are
automated. This way we could not only make our life easier but also we
could start promoting some good committer practices, and we could introduce
some more sophisticated strategies for dealing with issues (vs. current
anyone does anything strategy). For example sharing the issues between
committers, auto-assigning reviewers etc. etc. Of course this can all be
done without such tool, but that would be far less fun if those are
"written down" and "manually followed" processes rather than automated ones.

And of course  myself or anyone could develop such tool myself - but it's
quite an effort and I think it would only pay off if the effort could be
divided by a number of people contributing, but benefits multiplied by a
number of people using it :).

As we will have more committers (hopefully) we might have more need for
such tool. Is this a good time to start thinking about it?

J.

On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <se...@gmail.com> wrote:

> On a slightly irrelevant note, do we ever close tickets as non-reproducable
> or will-not-fix?
> Last time I was going through open tickets I found dozens that seemed
> really old, really not-gonna-happen or already fixed.
> What actions could we take to decrease this gap?
> WDYT?
>
> S.
>
> On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <tomasz.urbaszek@polidea.com
> >
> wrote:
>
> > I can agree that GitHub issues may get spammy but I other projects deal
> > with it somehow. And as a user I like the simplicity of creating an
> issue.
> > As per Jira, I think a good part of it is the ability to link issues
> across
> > different ASF project (but I don't think it's a killer feature).
> >
> > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com>
> wrote:
> >
> > > I don’t like Jira particularly but I like GitHub issues even less. Both
> > > don’t feel right. And yes GitHub issues get spammy very quickly. The
> > hurdle
> > > gets so low that it functions as an alternative to the mailing list,
> far,
> > > and chat.
> > >
> > >
> > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> > wrote:
> > >
> > > Getting creds for Jira might be tricky, though Infra may have some way
> of
> > > resolving issues when PR is merged (please don't Close, only ever
> Resolve
> > > as closed issues can't have FixVersion changed)
> > >
> > > This brings me on to another question: what do were actual use Jira for
> > > that couldn't (or shouldn't) be done with GitHub Issues?
> > >
> > > The main thing I can think of right now is the Fix version when
> resolving
> > > to say when we should backport a PR, but this could be achieved with
> > > Milestones in GitHub.
> > >
> > > (A fringe benefit is that most people won't have an ASF Jira account so
> > > opening issues to ask questions is harder. "Benefit" as it avoids issue
> > > spam for question.)
> > >
> > > Is there anything else?
> > >
> > > -A
> > >
> > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > > tomasz.urbaszek@polidea.com> wrote:
> > > >Is there any possibility to use GitHub actions for that?
> > > >For example, the one that allows to "Automatically transition an issue
> > > >to
> > > >done when a pull request whose name contains the issue key is merged"?
> > > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > > >
> > > >Bests,
> > > >Tomek
> > > >
> > > >
> > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> > > >wrote:
> > > >
> > > >> I wrote that script. It’s cli only unfortunately.
> > > >>
> > > >>
> > > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > > >(ddavydov@twitter.com.invalid
> > > >> )
> > > >> wrote:
> > > >>
> > > >> Wait this doesn't happen automatically!? I thought way-back-when
> > > >someone
> > > >> wrote a script to automatically close the JIRA tickets (maybe that
> > > >script
> > > >> is not run when changes are merged via the UI). My apologies, will
> > > >close
> > > >> JIRAs in the future, I don't think I've closed any JIRA tickets
> > > >manually.
> > > >>
> > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > > ><Ja...@polidea.com>
> > > >> wrote:
> > > >>
> > > >> > And yes. I was one of the culprits - I saw :(. Sorry about that
> > > >Kaxil.
> > > >> > Just hope we can streamline this :).
> > > >> >
> > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > > ><Ja...@polidea.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Heartily agree with it !
> > > >> > >
> > > >> > > I try always to close the PRs but sometimes I got distracted and
> > > >forget
> > > >> > to
> > > >> > > resolve an issue - it happend several times that I recalled it
> > > >few
> > > >> hours
> > > >> > > later that I have forgotten to resolve it. I hope it happens
> > > >rarely -
> > > >> I'd
> > > >> > > love to know if I was one of the culprits here :). And whenever
> I
> > > >> noticed
> > > >> > > some of the PRs are not closed but PR is merged by someone else
> -
> > > >I
> > > >> > > sometimes close them. But it's not ideal of course.
> > > >> > >
> > > >> > > However simple it is - I think we are just humans and we will
> > > >forget
> > > >> from
> > > >> > > time to time. I was wondering if we can (yes, you guessed it)
> > > >automate
> > > >> it
> > > >> > > :). Either with JIRA/Github integration or some automated tool
> to
> > > >do it
> > > >> > > regularly and resolving all already merged tickets. And the more
> > > >> > > committers we are going to have, the more it makes sense to
> > > >automate
> > > >> some
> > > >> > > of the work. The less you have to remember about your "chores"
> > > >the more
> > > >> > you
> > > >> > > can focus on the "real" stuff.
> > > >> > >
> > > >> > > I think there are a few unwritten rules that we have - like what
> > > >> version
> > > >> > > to set when we cherry-pick change to 1.10* . My understanding is
> > > >that
> > > >> we
> > > >> > > should set fixed version to the first unreleased yet 1.10.
> > > >version.
> > > >> This
> > > >> > > problem will soon be gone, so maybe it's not worth solving it.
> > > >There
> > > >> are
> > > >> > > also some edge cases like bad fixes which got reverted and
> > > >reapplied
> > > >> but
> > > >> > I
> > > >> > > think other than that the automation of it can be rather simple.
> > > >> > >
> > > >> > > And I think there are some scripts in "dev" that already do some
> > > >of
> > > >> that
> > > >> > -
> > > >> > > synchronising merges with JIRAs (but I don't think it's common
> > > >> knowledge
> > > >> > > and it's not regularly run). Maybe we can improve it somehow and
> > > >have
> > > >> it
> > > >> > > fully automated so that we do not even havet to think about it ?
> > > >> > >
> > > >> > > WDYT? Any ideas?
> > > >> > >
> > > >> > > J.
> > > >> > >
> > > >> > >
> > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <kaxilnaik@gmail.com
> >
> > > >> wrote:
> > > >> > >
> > > >> > >> We have some at
> > > >> > >>
> > > >>
> > > >
> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > > >> > >>
> > > >> > >> The person who merges the PR to master is the one who would be
> > > >> > responsible
> > > >> > >> for resolving the JIRA issue as they can add the *target
> > > >version*
> > > >> based
> > > >> > on
> > > >> > >> what they think after reviewing the PR.
> > > >> > >>
> > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > > >> > >> aizhamal@apache.org>
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >> > I think it will be good to document the process. For example,
> > > >who is
> > > >> > >> > responsible for closing Jira issues: folks who closed PR's or
> > > >the
> > > >> ones
> > > >> > >> who
> > > >> > >> > opened?
> > > >> > >> >
> > > >> > >> > If the documentation already exists, let's bring it back to
> > > >> attention.
> > > >> > >> >
> > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > > ><ka...@gmail.com>
> > > >> > wrote:
> > > >> > >> >
> > > >> > >> > > Hi Committers,
> > > >> > >> > >
> > > >> > >> > > Please make sure to close the Jira issues if the related
> PRs
> > > >are
> > > >> > >> merged.
> > > >> > >> > >
> > > >> > >> > > I am going through the Jira Reports (Image:
> > > >> > https://imgur.com/n50Ticx
> > > >> > >> )
> > > >> > >> > and
> > > >> > >> > > was concerned with the gap between issues created &
> resolved
> > > >in
> > > >> > recent
> > > >> > >> > > months.
> > > >> > >> > >
> > > >> > >> > > However, I noticed while going through the jira issues that
> > > >most
> > > >> of
> > > >> > >> the
> > > >> > >> > PRs
> > > >> > >> > > related to the JIRAs have been resolved but the JIRA is not
> > > >> > resolved.
> > > >> > >> > >
> > > >> > >> > > Let's try to resolve all the issues when we merge the PR :)
> > > >> > >> > >
> > > >> > >> > > This will help the release manager too.
> > > >> > >> > >
> > > >> > >> > > Regards,
> > > >> > >> > > Kaxil
> > > >> > >> > >
> > > >> > >> >
> > > >> > >>
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > >
> > > >> > > Jarek Potiuk
> > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > >> > >
> > > >> > > M: +48 660 796 129 <+48660796129>
> > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > >> > >
> > > >> > >
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Jarek Potiuk
> > > >> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >> >
> > > >> > M: +48 660 796 129 <+48660796129>
> > > >> > [image: Polidea] <https://www.polidea.com/>
> > > >> >
> > > >>
> > > >
> > > >
> > > >--
> > > >
> > > >Tomasz Urbaszek
> > > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > >
> > > >M: +48 505 628 493 <+48505628493>
> > > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > >
> > > >Unique Tech
> > > >Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
> >
> > --
> >
> > Tomasz Urbaszek
> > Polidea <https://www.polidea.com/> | Junior Software Engineer
> >
> > M: +48 505 628 493 <+48505628493>
> > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >
> > Unique Tech
> > Check out our projects! <https://www.polidea.com/our-work>
> >
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: Closing JIRA Issue for Merged PRs

[Sergio Kef <se...@gmail.com>]

On a slightly irrelevant note, do we ever close tickets as non-reproducable
or will-not-fix?
Last time I was going through open tickets I found dozens that seemed
really old, really not-gonna-happen or already fixed.
What actions could we take to decrease this gap?
WDYT?

S.

On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek <to...@polidea.com>
wrote:

> I can agree that GitHub issues may get spammy but I other projects deal
> with it somehow. And as a user I like the simplicity of creating an issue.
> As per Jira, I think a good part of it is the ability to link issues across
> different ASF project (but I don't think it's a killer feature).
>
> On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com> wrote:
>
> > I don’t like Jira particularly but I like GitHub issues even less. Both
> > don’t feel right. And yes GitHub issues get spammy very quickly. The
> hurdle
> > gets so low that it functions as an alternative to the mailing list, far,
> > and chat.
> >
> >
> > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org)
> wrote:
> >
> > Getting creds for Jira might be tricky, though Infra may have some way of
> > resolving issues when PR is merged (please don't Close, only ever Resolve
> > as closed issues can't have FixVersion changed)
> >
> > This brings me on to another question: what do were actual use Jira for
> > that couldn't (or shouldn't) be done with GitHub Issues?
> >
> > The main thing I can think of right now is the Fix version when resolving
> > to say when we should backport a PR, but this could be achieved with
> > Milestones in GitHub.
> >
> > (A fringe benefit is that most people won't have an ASF Jira account so
> > opening issues to ask questions is harder. "Benefit" as it avoids issue
> > spam for question.)
> >
> > Is there anything else?
> >
> > -A
> >
> > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> > tomasz.urbaszek@polidea.com> wrote:
> > >Is there any possibility to use GitHub actions for that?
> > >For example, the one that allows to "Automatically transition an issue
> > >to
> > >done when a pull request whose name contains the issue key is merged"?
> > >Here is Atlassian repo: https://github.com/atlassian/gajira
> > >
> > >Bests,
> > >Tomek
> > >
> > >
> > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> > >wrote:
> > >
> > >> I wrote that script. It’s cli only unfortunately.
> > >>
> > >>
> > >> On 18 November 2019 at 18:22:04, Dan Davydov
> > >(ddavydov@twitter.com.invalid
> > >> )
> > >> wrote:
> > >>
> > >> Wait this doesn't happen automatically!? I thought way-back-when
> > >someone
> > >> wrote a script to automatically close the JIRA tickets (maybe that
> > >script
> > >> is not run when changes are merged via the UI). My apologies, will
> > >close
> > >> JIRAs in the future, I don't think I've closed any JIRA tickets
> > >manually.
> > >>
> > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> > ><Ja...@polidea.com>
> > >> wrote:
> > >>
> > >> > And yes. I was one of the culprits - I saw :(. Sorry about that
> > >Kaxil.
> > >> > Just hope we can streamline this :).
> > >> >
> > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> > ><Ja...@polidea.com>
> > >> > wrote:
> > >> >
> > >> > > Heartily agree with it !
> > >> > >
> > >> > > I try always to close the PRs but sometimes I got distracted and
> > >forget
> > >> > to
> > >> > > resolve an issue - it happend several times that I recalled it
> > >few
> > >> hours
> > >> > > later that I have forgotten to resolve it. I hope it happens
> > >rarely -
> > >> I'd
> > >> > > love to know if I was one of the culprits here :). And whenever I
> > >> noticed
> > >> > > some of the PRs are not closed but PR is merged by someone else -
> > >I
> > >> > > sometimes close them. But it's not ideal of course.
> > >> > >
> > >> > > However simple it is - I think we are just humans and we will
> > >forget
> > >> from
> > >> > > time to time. I was wondering if we can (yes, you guessed it)
> > >automate
> > >> it
> > >> > > :). Either with JIRA/Github integration or some automated tool to
> > >do it
> > >> > > regularly and resolving all already merged tickets. And the more
> > >> > > committers we are going to have, the more it makes sense to
> > >automate
> > >> some
> > >> > > of the work. The less you have to remember about your "chores"
> > >the more
> > >> > you
> > >> > > can focus on the "real" stuff.
> > >> > >
> > >> > > I think there are a few unwritten rules that we have - like what
> > >> version
> > >> > > to set when we cherry-pick change to 1.10* . My understanding is
> > >that
> > >> we
> > >> > > should set fixed version to the first unreleased yet 1.10.
> > >version.
> > >> This
> > >> > > problem will soon be gone, so maybe it's not worth solving it.
> > >There
> > >> are
> > >> > > also some edge cases like bad fixes which got reverted and
> > >reapplied
> > >> but
> > >> > I
> > >> > > think other than that the automation of it can be rather simple.
> > >> > >
> > >> > > And I think there are some scripts in "dev" that already do some
> > >of
> > >> that
> > >> > -
> > >> > > synchronising merges with JIRAs (but I don't think it's common
> > >> knowledge
> > >> > > and it's not regularly run). Maybe we can improve it somehow and
> > >have
> > >> it
> > >> > > fully automated so that we do not even havet to think about it ?
> > >> > >
> > >> > > WDYT? Any ideas?
> > >> > >
> > >> > > J.
> > >> > >
> > >> > >
> > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > >> We have some at
> > >> > >>
> > >>
> > >https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > >> > >>
> > >> > >> The person who merges the PR to master is the one who would be
> > >> > responsible
> > >> > >> for resolving the JIRA issue as they can add the *target
> > >version*
> > >> based
> > >> > on
> > >> > >> what they think after reviewing the PR.
> > >> > >>
> > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > >> > >> aizhamal@apache.org>
> > >> > >> wrote:
> > >> > >>
> > >> > >> > I think it will be good to document the process. For example,
> > >who is
> > >> > >> > responsible for closing Jira issues: folks who closed PR's or
> > >the
> > >> ones
> > >> > >> who
> > >> > >> > opened?
> > >> > >> >
> > >> > >> > If the documentation already exists, let's bring it back to
> > >> attention.
> > >> > >> >
> > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> > ><ka...@gmail.com>
> > >> > wrote:
> > >> > >> >
> > >> > >> > > Hi Committers,
> > >> > >> > >
> > >> > >> > > Please make sure to close the Jira issues if the related PRs
> > >are
> > >> > >> merged.
> > >> > >> > >
> > >> > >> > > I am going through the Jira Reports (Image:
> > >> > https://imgur.com/n50Ticx
> > >> > >> )
> > >> > >> > and
> > >> > >> > > was concerned with the gap between issues created & resolved
> > >in
> > >> > recent
> > >> > >> > > months.
> > >> > >> > >
> > >> > >> > > However, I noticed while going through the jira issues that
> > >most
> > >> of
> > >> > >> the
> > >> > >> > PRs
> > >> > >> > > related to the JIRAs have been resolved but the JIRA is not
> > >> > resolved.
> > >> > >> > >
> > >> > >> > > Let's try to resolve all the issues when we merge the PR :)
> > >> > >> > >
> > >> > >> > > This will help the release manager too.
> > >> > >> > >
> > >> > >> > > Regards,
> > >> > >> > > Kaxil
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> > >
> > >> > > --
> > >> > >
> > >> > > Jarek Potiuk
> > >> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >> > >
> > >> > > M: +48 660 796 129 <+48660796129>
> > >> > > [image: Polidea] <https://www.polidea.com/>
> > >> > >
> > >> > >
> > >> >
> > >> > --
> > >> >
> > >> > Jarek Potiuk
> > >> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >> >
> > >> > M: +48 660 796 129 <+48660796129>
> > >> > [image: Polidea] <https://www.polidea.com/>
> > >> >
> > >>
> > >
> > >
> > >--
> > >
> > >Tomasz Urbaszek
> > >Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >
> > >M: +48 505 628 493 <+48505628493>
> > >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >
> > >Unique Tech
> > >Check out our projects! <https://www.polidea.com/our-work>
> >
>
>
> --
>
> Tomasz Urbaszek
> Polidea <https://www.polidea.com/> | Junior Software Engineer
>
> M: +48 505 628 493 <+48505628493>
> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>
>

Re: Closing JIRA Issue for Merged PRs

[Tomasz Urbaszek <to...@polidea.com>]

I can agree that GitHub issues may get spammy but I other projects deal
with it somehow. And as a user I like the simplicity of creating an issue.
As per Jira, I think a good part of it is the ability to link issues across
different ASF project (but I don't think it's a killer feature).

On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin <bd...@gmail.com> wrote:

> I don’t like Jira particularly but I like GitHub issues even less. Both
> don’t feel right. And yes GitHub issues get spammy very quickly. The hurdle
> gets so low that it functions as an alternative to the mailing list, far,
> and chat.
>
>
> On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org) wrote:
>
> Getting creds for Jira might be tricky, though Infra may have some way of
> resolving issues when PR is merged (please don't Close, only ever Resolve
> as closed issues can't have FixVersion changed)
>
> This brings me on to another question: what do were actual use Jira for
> that couldn't (or shouldn't) be done with GitHub Issues?
>
> The main thing I can think of right now is the Fix version when resolving
> to say when we should backport a PR, but this could be achieved with
> Milestones in GitHub.
>
> (A fringe benefit is that most people won't have an ASF Jira account so
> opening issues to ask questions is harder. "Benefit" as it avoids issue
> spam for question.)
>
> Is there anything else?
>
> -A
>
> On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com> wrote:
> >Is there any possibility to use GitHub actions for that?
> >For example, the one that allows to "Automatically transition an issue
> >to
> >done when a pull request whose name contains the issue key is merged"?
> >Here is Atlassian repo: https://github.com/atlassian/gajira
> >
> >Bests,
> >Tomek
> >
> >
> >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
> >wrote:
> >
> >> I wrote that script. It’s cli only unfortunately.
> >>
> >>
> >> On 18 November 2019 at 18:22:04, Dan Davydov
> >(ddavydov@twitter.com.invalid
> >> )
> >> wrote:
> >>
> >> Wait this doesn't happen automatically!? I thought way-back-when
> >someone
> >> wrote a script to automatically close the JIRA tickets (maybe that
> >script
> >> is not run when changes are merged via the UI). My apologies, will
> >close
> >> JIRAs in the future, I don't think I've closed any JIRA tickets
> >manually.
> >>
> >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
> ><Ja...@polidea.com>
> >> wrote:
> >>
> >> > And yes. I was one of the culprits - I saw :(. Sorry about that
> >Kaxil.
> >> > Just hope we can streamline this :).
> >> >
> >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
> ><Ja...@polidea.com>
> >> > wrote:
> >> >
> >> > > Heartily agree with it !
> >> > >
> >> > > I try always to close the PRs but sometimes I got distracted and
> >forget
> >> > to
> >> > > resolve an issue - it happend several times that I recalled it
> >few
> >> hours
> >> > > later that I have forgotten to resolve it. I hope it happens
> >rarely -
> >> I'd
> >> > > love to know if I was one of the culprits here :). And whenever I
> >> noticed
> >> > > some of the PRs are not closed but PR is merged by someone else -
> >I
> >> > > sometimes close them. But it's not ideal of course.
> >> > >
> >> > > However simple it is - I think we are just humans and we will
> >forget
> >> from
> >> > > time to time. I was wondering if we can (yes, you guessed it)
> >automate
> >> it
> >> > > :). Either with JIRA/Github integration or some automated tool to
> >do it
> >> > > regularly and resolving all already merged tickets. And the more
> >> > > committers we are going to have, the more it makes sense to
> >automate
> >> some
> >> > > of the work. The less you have to remember about your "chores"
> >the more
> >> > you
> >> > > can focus on the "real" stuff.
> >> > >
> >> > > I think there are a few unwritten rules that we have - like what
> >> version
> >> > > to set when we cherry-pick change to 1.10* . My understanding is
> >that
> >> we
> >> > > should set fixed version to the first unreleased yet 1.10.
> >version.
> >> This
> >> > > problem will soon be gone, so maybe it's not worth solving it.
> >There
> >> are
> >> > > also some edge cases like bad fixes which got reverted and
> >reapplied
> >> but
> >> > I
> >> > > think other than that the automation of it can be rather simple.
> >> > >
> >> > > And I think there are some scripts in "dev" that already do some
> >of
> >> that
> >> > -
> >> > > synchronising merges with JIRAs (but I don't think it's common
> >> knowledge
> >> > > and it's not regularly run). Maybe we can improve it somehow and
> >have
> >> it
> >> > > fully automated so that we do not even havet to think about it ?
> >> > >
> >> > > WDYT? Any ideas?
> >> > >
> >> > > J.
> >> > >
> >> > >
> >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com>
> >> wrote:
> >> > >
> >> > >> We have some at
> >> > >>
> >>
> >https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> >> > >>
> >> > >> The person who merges the PR to master is the one who would be
> >> > responsible
> >> > >> for resolving the JIRA issue as they can add the *target
> >version*
> >> based
> >> > on
> >> > >> what they think after reviewing the PR.
> >> > >>
> >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> >> > >> aizhamal@apache.org>
> >> > >> wrote:
> >> > >>
> >> > >> > I think it will be good to document the process. For example,
> >who is
> >> > >> > responsible for closing Jira issues: folks who closed PR's or
> >the
> >> ones
> >> > >> who
> >> > >> > opened?
> >> > >> >
> >> > >> > If the documentation already exists, let's bring it back to
> >> attention.
> >> > >> >
> >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
> ><ka...@gmail.com>
> >> > wrote:
> >> > >> >
> >> > >> > > Hi Committers,
> >> > >> > >
> >> > >> > > Please make sure to close the Jira issues if the related PRs
> >are
> >> > >> merged.
> >> > >> > >
> >> > >> > > I am going through the Jira Reports (Image:
> >> > https://imgur.com/n50Ticx
> >> > >> )
> >> > >> > and
> >> > >> > > was concerned with the gap between issues created & resolved
> >in
> >> > recent
> >> > >> > > months.
> >> > >> > >
> >> > >> > > However, I noticed while going through the jira issues that
> >most
> >> of
> >> > >> the
> >> > >> > PRs
> >> > >> > > related to the JIRAs have been resolved but the JIRA is not
> >> > resolved.
> >> > >> > >
> >> > >> > > Let's try to resolve all the issues when we merge the PR :)
> >> > >> > >
> >> > >> > > This will help the release manager too.
> >> > >> > >
> >> > >> > > Regards,
> >> > >> > > Kaxil
> >> > >> > >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> > > --
> >> > >
> >> > > Jarek Potiuk
> >> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >> > >
> >> > > M: +48 660 796 129 <+48660796129>
> >> > > [image: Polidea] <https://www.polidea.com/>
> >> > >
> >> > >
> >> >
> >> > --
> >> >
> >> > Jarek Potiuk
> >> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >> >
> >> > M: +48 660 796 129 <+48660796129>
> >> > [image: Polidea] <https://www.polidea.com/>
> >> >
> >>
> >
> >
> >--
> >
> >Tomasz Urbaszek
> >Polidea <https://www.polidea.com/> | Junior Software Engineer
> >
> >M: +48 505 628 493 <+48505628493>
> >E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >
> >Unique Tech
> >Check out our projects! <https://www.polidea.com/our-work>
>


-- 

Tomasz Urbaszek
Polidea <https://www.polidea.com/> | Junior Software Engineer

M: +48 505 628 493 <+48505628493>
E: tomasz.urbaszek@polidea.com <to...@polidea.com>

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

Re: Closing JIRA Issue for Merged PRs

[Bolke de Bruin <bd...@gmail.com>]

I don’t like Jira particularly but I like GitHub issues even less. Both
don’t feel right. And yes GitHub issues get spammy very quickly. The hurdle
gets so low that it functions as an alternative to the mailing list, far,
and chat.


On 18 November 2019 at 21:05:38, Ash Berlin-Taylor (ash@apache.org) wrote:

Getting creds for Jira might be tricky, though Infra may have some way of
resolving issues when PR is merged (please don't Close, only ever Resolve
as closed issues can't have FixVersion changed)

This brings me on to another question: what do were actual use Jira for
that couldn't (or shouldn't) be done with GitHub Issues?

The main thing I can think of right now is the Fix version when resolving
to say when we should backport a PR, but this could be achieved with
Milestones in GitHub.

(A fringe benefit is that most people won't have an ASF Jira account so
opening issues to ask questions is harder. "Benefit" as it avoids issue
spam for question.)

Is there anything else?

-A

On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <
tomasz.urbaszek@polidea.com> wrote:
>Is there any possibility to use GitHub actions for that?
>For example, the one that allows to "Automatically transition an issue
>to
>done when a pull request whose name contains the issue key is merged"?
>Here is Atlassian repo: https://github.com/atlassian/gajira
>
>Bests,
>Tomek
>
>
>On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
>wrote:
>
>> I wrote that script. It’s cli only unfortunately.
>>
>>
>> On 18 November 2019 at 18:22:04, Dan Davydov
>(ddavydov@twitter.com.invalid
>> )
>> wrote:
>>
>> Wait this doesn't happen automatically!? I thought way-back-when
>someone
>> wrote a script to automatically close the JIRA tickets (maybe that
>script
>> is not run when changes are merged via the UI). My apologies, will
>close
>> JIRAs in the future, I don't think I've closed any JIRA tickets
>manually.
>>
>> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
><Ja...@polidea.com>
>> wrote:
>>
>> > And yes. I was one of the culprits - I saw :(. Sorry about that
>Kaxil.
>> > Just hope we can streamline this :).
>> >
>> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
><Ja...@polidea.com>
>> > wrote:
>> >
>> > > Heartily agree with it !
>> > >
>> > > I try always to close the PRs but sometimes I got distracted and
>forget
>> > to
>> > > resolve an issue - it happend several times that I recalled it
>few
>> hours
>> > > later that I have forgotten to resolve it. I hope it happens
>rarely -
>> I'd
>> > > love to know if I was one of the culprits here :). And whenever I
>> noticed
>> > > some of the PRs are not closed but PR is merged by someone else -
>I
>> > > sometimes close them. But it's not ideal of course.
>> > >
>> > > However simple it is - I think we are just humans and we will
>forget
>> from
>> > > time to time. I was wondering if we can (yes, you guessed it)
>automate
>> it
>> > > :). Either with JIRA/Github integration or some automated tool to
>do it
>> > > regularly and resolving all already merged tickets. And the more
>> > > committers we are going to have, the more it makes sense to
>automate
>> some
>> > > of the work. The less you have to remember about your "chores"
>the more
>> > you
>> > > can focus on the "real" stuff.
>> > >
>> > > I think there are a few unwritten rules that we have - like what
>> version
>> > > to set when we cherry-pick change to 1.10* . My understanding is
>that
>> we
>> > > should set fixed version to the first unreleased yet 1.10.
>version.
>> This
>> > > problem will soon be gone, so maybe it's not worth solving it.
>There
>> are
>> > > also some edge cases like bad fixes which got reverted and
>reapplied
>> but
>> > I
>> > > think other than that the automation of it can be rather simple.
>> > >
>> > > And I think there are some scripts in "dev" that already do some
>of
>> that
>> > -
>> > > synchronising merges with JIRAs (but I don't think it's common
>> knowledge
>> > > and it's not regularly run). Maybe we can improve it somehow and
>have
>> it
>> > > fully automated so that we do not even havet to think about it ?
>> > >
>> > > WDYT? Any ideas?
>> > >
>> > > J.
>> > >
>> > >
>> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com>
>> wrote:
>> > >
>> > >> We have some at
>> > >>
>>
>https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
>> > >>
>> > >> The person who merges the PR to master is the one who would be
>> > responsible
>> > >> for resolving the JIRA issue as they can add the *target
>version*
>> based
>> > on
>> > >> what they think after reviewing the PR.
>> > >>
>> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
>> > >> aizhamal@apache.org>
>> > >> wrote:
>> > >>
>> > >> > I think it will be good to document the process. For example,
>who is
>> > >> > responsible for closing Jira issues: folks who closed PR's or
>the
>> ones
>> > >> who
>> > >> > opened?
>> > >> >
>> > >> > If the documentation already exists, let's bring it back to
>> attention.
>> > >> >
>> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
><ka...@gmail.com>
>> > wrote:
>> > >> >
>> > >> > > Hi Committers,
>> > >> > >
>> > >> > > Please make sure to close the Jira issues if the related PRs
>are
>> > >> merged.
>> > >> > >
>> > >> > > I am going through the Jira Reports (Image:
>> > https://imgur.com/n50Ticx
>> > >> )
>> > >> > and
>> > >> > > was concerned with the gap between issues created & resolved
>in
>> > recent
>> > >> > > months.
>> > >> > >
>> > >> > > However, I noticed while going through the jira issues that
>most
>> of
>> > >> the
>> > >> > PRs
>> > >> > > related to the JIRAs have been resolved but the JIRA is not
>> > resolved.
>> > >> > >
>> > >> > > Let's try to resolve all the issues when we merge the PR :)
>> > >> > >
>> > >> > > This will help the release manager too.
>> > >> > >
>> > >> > > Regards,
>> > >> > > Kaxil
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> > > --
>> > >
>> > > Jarek Potiuk
>> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
>> > >
>> > > M: +48 660 796 129 <+48660796129>
>> > > [image: Polidea] <https://www.polidea.com/>
>> > >
>> > >
>> >
>> > --
>> >
>> > Jarek Potiuk
>> > Polidea <https://www.polidea.com/> | Principal Software Engineer
>> >
>> > M: +48 660 796 129 <+48660796129>
>> > [image: Polidea] <https://www.polidea.com/>
>> >
>>
>
>
>--
>
>Tomasz Urbaszek
>Polidea <https://www.polidea.com/> | Junior Software Engineer
>
>M: +48 505 628 493 <+48505628493>
>E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>
>Unique Tech
>Check out our projects! <https://www.polidea.com/our-work>

Re: Closing JIRA Issue for Merged PRs

[Ash Berlin-Taylor <as...@apache.org>]

Getting creds for Jira might be tricky, though Infra may have some way of resolving issues when PR is merged (please don't Close, only ever Resolve as closed issues can't have FixVersion changed)

This brings me on to another question: what do were actual use Jira for that couldn't (or shouldn't) be done with GitHub Issues?

The main thing I can think of right now is the Fix version when resolving to say when we should backport a PR, but this could be achieved with Milestones in GitHub.

(A fringe benefit is that most people won't have an ASF Jira account so opening issues to ask questions is harder. "Benefit" as it avoids issue spam for question.)

Is there anything else?

-A

On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek <to...@polidea.com> wrote:
>Is there any possibility to use GitHub actions for that?
>For example, the one that allows to "Automatically transition an issue
>to
>done when a pull request whose name contains the issue key is merged"?
>Here is Atlassian repo: https://github.com/atlassian/gajira
>
>Bests,
>Tomek
>
>
>On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com>
>wrote:
>
>> I wrote that script. It’s cli only unfortunately.
>>
>>
>> On 18 November 2019 at 18:22:04, Dan Davydov
>(ddavydov@twitter.com.invalid
>> )
>> wrote:
>>
>> Wait this doesn't happen automatically!? I thought way-back-when
>someone
>> wrote a script to automatically close the JIRA tickets (maybe that
>script
>> is not run when changes are merged via the UI). My apologies, will
>close
>> JIRAs in the future, I don't think I've closed any JIRA tickets
>manually.
>>
>> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk
><Ja...@polidea.com>
>> wrote:
>>
>> > And yes. I was one of the culprits - I saw :(. Sorry about that
>Kaxil.
>> > Just hope we can streamline this :).
>> >
>> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk
><Ja...@polidea.com>
>> > wrote:
>> >
>> > > Heartily agree with it !
>> > >
>> > > I try always to close the PRs but sometimes I got distracted and
>forget
>> > to
>> > > resolve an issue - it happend several times that I recalled it
>few
>> hours
>> > > later that I have forgotten to resolve it. I hope it happens
>rarely -
>> I'd
>> > > love to know if I was one of the culprits here :). And whenever I
>> noticed
>> > > some of the PRs are not closed but PR is merged by someone else -
>I
>> > > sometimes close them. But it's not ideal of course.
>> > >
>> > > However simple it is - I think we are just humans and we will
>forget
>> from
>> > > time to time. I was wondering if we can (yes, you guessed it)
>automate
>> it
>> > > :). Either with JIRA/Github integration or some automated tool to
>do it
>> > > regularly and resolving all already merged tickets. And the more
>> > > committers we are going to have, the more it makes sense to
>automate
>> some
>> > > of the work. The less you have to remember about your "chores"
>the more
>> > you
>> > > can focus on the "real" stuff.
>> > >
>> > > I think there are a few unwritten rules that we have - like what
>> version
>> > > to set when we cherry-pick change to 1.10* . My understanding is
>that
>> we
>> > > should set fixed version to the first unreleased yet 1.10.
>version.
>> This
>> > > problem will soon be gone, so maybe it's not worth solving it.
>There
>> are
>> > > also some edge cases like bad fixes which got reverted and
>reapplied
>> but
>> > I
>> > > think other than that the automation of it can be rather simple.
>> > >
>> > > And I think there are some scripts in "dev" that already do some
>of
>> that
>> > -
>> > > synchronising merges with JIRAs (but I don't think it's common
>> knowledge
>> > > and it's not regularly run). Maybe we can improve it somehow and
>have
>> it
>> > > fully automated so that we do not even havet to think about it ?
>> > >
>> > > WDYT? Any ideas?
>> > >
>> > > J.
>> > >
>> > >
>> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com>
>> wrote:
>> > >
>> > >> We have some at
>> > >>
>>
>https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
>> > >>
>> > >> The person who merges the PR to master is the one who would be
>> > responsible
>> > >> for resolving the JIRA issue as they can add the *target
>version*
>> based
>> > on
>> > >> what they think after reviewing the PR.
>> > >>
>> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
>> > >> aizhamal@apache.org>
>> > >> wrote:
>> > >>
>> > >> > I think it will be good to document the process. For example,
>who is
>> > >> > responsible for closing Jira issues: folks who closed PR's or
>the
>> ones
>> > >> who
>> > >> > opened?
>> > >> >
>> > >> > If the documentation already exists, let's bring it back to
>> attention.
>> > >> >
>> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik
><ka...@gmail.com>
>> > wrote:
>> > >> >
>> > >> > > Hi Committers,
>> > >> > >
>> > >> > > Please make sure to close the Jira issues if the related PRs
>are
>> > >> merged.
>> > >> > >
>> > >> > > I am going through the Jira Reports (Image:
>> > https://imgur.com/n50Ticx
>> > >> )
>> > >> > and
>> > >> > > was concerned with the gap between issues created & resolved
>in
>> > recent
>> > >> > > months.
>> > >> > >
>> > >> > > However, I noticed while going through the jira issues that
>most
>> of
>> > >> the
>> > >> > PRs
>> > >> > > related to the JIRAs have been resolved but the JIRA is not
>> > resolved.
>> > >> > >
>> > >> > > Let's try to resolve all the issues when we merge the PR :)
>> > >> > >
>> > >> > > This will help the release manager too.
>> > >> > >
>> > >> > > Regards,
>> > >> > > Kaxil
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> > > --
>> > >
>> > > Jarek Potiuk
>> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
>> > >
>> > > M: +48 660 796 129 <+48660796129>
>> > > [image: Polidea] <https://www.polidea.com/>
>> > >
>> > >
>> >
>> > --
>> >
>> > Jarek Potiuk
>> > Polidea <https://www.polidea.com/> | Principal Software Engineer
>> >
>> > M: +48 660 796 129 <+48660796129>
>> > [image: Polidea] <https://www.polidea.com/>
>> >
>>
>
>
>-- 
>
>Tomasz Urbaszek
>Polidea <https://www.polidea.com/> | Junior Software Engineer
>
>M: +48 505 628 493 <+48505628493>
>E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>
>Unique Tech
>Check out our projects! <https://www.polidea.com/our-work>

Re: Closing JIRA Issue for Merged PRs

[Tomasz Urbaszek <to...@polidea.com>]

Is there any possibility to use GitHub actions for that?
For example, the one that allows to "Automatically transition an issue to
done when a pull request whose name contains the issue key is merged"?
Here is Atlassian repo: https://github.com/atlassian/gajira

Bests,
Tomek


On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin <bd...@gmail.com> wrote:

> I wrote that script. It’s cli only unfortunately.
>
>
> On 18 November 2019 at 18:22:04, Dan Davydov (ddavydov@twitter.com.invalid
> )
> wrote:
>
> Wait this doesn't happen automatically!? I thought way-back-when someone
> wrote a script to automatically close the JIRA tickets (maybe that script
> is not run when changes are merged via the UI). My apologies, will close
> JIRAs in the future, I don't think I've closed any JIRA tickets manually.
>
> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > And yes. I was one of the culprits - I saw :(. Sorry about that Kaxil.
> > Just hope we can streamline this :).
> >
> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > Heartily agree with it !
> > >
> > > I try always to close the PRs but sometimes I got distracted and forget
> > to
> > > resolve an issue - it happend several times that I recalled it few
> hours
> > > later that I have forgotten to resolve it. I hope it happens rarely -
> I'd
> > > love to know if I was one of the culprits here :). And whenever I
> noticed
> > > some of the PRs are not closed but PR is merged by someone else - I
> > > sometimes close them. But it's not ideal of course.
> > >
> > > However simple it is - I think we are just humans and we will forget
> from
> > > time to time. I was wondering if we can (yes, you guessed it) automate
> it
> > > :). Either with JIRA/Github integration or some automated tool to do it
> > > regularly and resolving all already merged tickets. And the more
> > > committers we are going to have, the more it makes sense to automate
> some
> > > of the work. The less you have to remember about your "chores" the more
> > you
> > > can focus on the "real" stuff.
> > >
> > > I think there are a few unwritten rules that we have - like what
> version
> > > to set when we cherry-pick change to 1.10* . My understanding is that
> we
> > > should set fixed version to the first unreleased yet 1.10. version.
> This
> > > problem will soon be gone, so maybe it's not worth solving it. There
> are
> > > also some edge cases like bad fixes which got reverted and reapplied
> but
> > I
> > > think other than that the automation of it can be rather simple.
> > >
> > > And I think there are some scripts in "dev" that already do some of
> that
> > -
> > > synchronising merges with JIRAs (but I don't think it's common
> knowledge
> > > and it's not regularly run). Maybe we can improve it somehow and have
> it
> > > fully automated so that we do not even havet to think about it ?
> > >
> > > WDYT? Any ideas?
> > >
> > > J.
> > >
> > >
> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >
> > >> We have some at
> > >>
> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> > >>
> > >> The person who merges the PR to master is the one who would be
> > responsible
> > >> for resolving the JIRA issue as they can add the *target version*
> based
> > on
> > >> what they think after reviewing the PR.
> > >>
> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> > >> aizhamal@apache.org>
> > >> wrote:
> > >>
> > >> > I think it will be good to document the process. For example, who is
> > >> > responsible for closing Jira issues: folks who closed PR's or the
> ones
> > >> who
> > >> > opened?
> > >> >
> > >> > If the documentation already exists, let's bring it back to
> attention.
> > >> >
> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik <ka...@gmail.com>
> > wrote:
> > >> >
> > >> > > Hi Committers,
> > >> > >
> > >> > > Please make sure to close the Jira issues if the related PRs are
> > >> merged.
> > >> > >
> > >> > > I am going through the Jira Reports (Image:
> > https://imgur.com/n50Ticx
> > >> )
> > >> > and
> > >> > > was concerned with the gap between issues created & resolved in
> > recent
> > >> > > months.
> > >> > >
> > >> > > However, I noticed while going through the jira issues that most
> of
> > >> the
> > >> > PRs
> > >> > > related to the JIRAs have been resolved but the JIRA is not
> > resolved.
> > >> > >
> > >> > > Let's try to resolve all the issues when we merge the PR :)
> > >> > >
> > >> > > This will help the release manager too.
> > >> > >
> > >> > > Regards,
> > >> > > Kaxil
> > >> > >
> > >> >
> > >>
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> > >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
>


-- 

Tomasz Urbaszek
Polidea <https://www.polidea.com/> | Junior Software Engineer

M: +48 505 628 493 <+48505628493>
E: tomasz.urbaszek@polidea.com <to...@polidea.com>

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

Re: Closing JIRA Issue for Merged PRs

[Bolke de Bruin <bd...@gmail.com>]

I wrote that script. It’s cli only unfortunately.


On 18 November 2019 at 18:22:04, Dan Davydov (ddavydov@twitter.com.invalid)
wrote:

Wait this doesn't happen automatically!? I thought way-back-when someone
wrote a script to automatically close the JIRA tickets (maybe that script
is not run when changes are merged via the UI). My apologies, will close
JIRAs in the future, I don't think I've closed any JIRA tickets manually.

On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk <Ja...@polidea.com>
wrote:

> And yes. I was one of the culprits - I saw :(. Sorry about that Kaxil.
> Just hope we can streamline this :).
>
> On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Heartily agree with it !
> >
> > I try always to close the PRs but sometimes I got distracted and forget
> to
> > resolve an issue - it happend several times that I recalled it few
hours
> > later that I have forgotten to resolve it. I hope it happens rarely -
I'd
> > love to know if I was one of the culprits here :). And whenever I
noticed
> > some of the PRs are not closed but PR is merged by someone else - I
> > sometimes close them. But it's not ideal of course.
> >
> > However simple it is - I think we are just humans and we will forget
from
> > time to time. I was wondering if we can (yes, you guessed it) automate
it
> > :). Either with JIRA/Github integration or some automated tool to do it
> > regularly and resolving all already merged tickets. And the more
> > committers we are going to have, the more it makes sense to automate
some
> > of the work. The less you have to remember about your "chores" the more
> you
> > can focus on the "real" stuff.
> >
> > I think there are a few unwritten rules that we have - like what
version
> > to set when we cherry-pick change to 1.10* . My understanding is that
we
> > should set fixed version to the first unreleased yet 1.10. version.
This
> > problem will soon be gone, so maybe it's not worth solving it. There
are
> > also some edge cases like bad fixes which got reverted and reapplied
but
> I
> > think other than that the automation of it can be rather simple.
> >
> > And I think there are some scripts in "dev" that already do some of
that
> -
> > synchronising merges with JIRAs (but I don't think it's common
knowledge
> > and it's not regularly run). Maybe we can improve it somehow and have
it
> > fully automated so that we do not even havet to think about it ?
> >
> > WDYT? Any ideas?
> >
> > J.
> >
> >
> > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> >> We have some at
> >> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> >>
> >> The person who merges the PR to master is the one who would be
> responsible
> >> for resolving the JIRA issue as they can add the *target version*
based
> on
> >> what they think after reviewing the PR.
> >>
> >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> >> aizhamal@apache.org>
> >> wrote:
> >>
> >> > I think it will be good to document the process. For example, who is
> >> > responsible for closing Jira issues: folks who closed PR's or the
ones
> >> who
> >> > opened?
> >> >
> >> > If the documentation already exists, let's bring it back to
attention.
> >> >
> >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik <ka...@gmail.com>
> wrote:
> >> >
> >> > > Hi Committers,
> >> > >
> >> > > Please make sure to close the Jira issues if the related PRs are
> >> merged.
> >> > >
> >> > > I am going through the Jira Reports (Image:
> https://imgur.com/n50Ticx
> >> )
> >> > and
> >> > > was concerned with the gap between issues created & resolved in
> recent
> >> > > months.
> >> > >
> >> > > However, I noticed while going through the jira issues that most
of
> >> the
> >> > PRs
> >> > > related to the JIRAs have been resolved but the JIRA is not
> resolved.
> >> > >
> >> > > Let's try to resolve all the issues when we merge the PR :)
> >> > >
> >> > > This will help the release manager too.
> >> > >
> >> > > Regards,
> >> > > Kaxil
> >> > >
> >> >
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
> >
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: Closing JIRA Issue for Merged PRs

[Dan Davydov <dd...@twitter.com.INVALID>]

Wait this doesn't happen automatically!? I thought way-back-when someone
wrote a script to automatically close the JIRA tickets (maybe that script
is not run when changes are merged via the UI). My apologies, will close
JIRAs in the future, I don't think I've closed any JIRA tickets manually.

On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk <Ja...@polidea.com>
wrote:

> And yes. I was one of the culprits -  I saw :(. Sorry about that Kaxil.
> Just hope we can streamline this :).
>
> On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Heartily agree with it !
> >
> > I try always to close the PRs but sometimes I got distracted and forget
> to
> > resolve an issue - it happend several times that I recalled it few hours
> > later that I have forgotten to resolve it. I hope it happens rarely - I'd
> > love to know if I was one of the culprits here :). And whenever I noticed
> > some of the PRs are not closed but PR is merged by someone else - I
> > sometimes close them. But it's not ideal of course.
> >
> > However simple it is - I think we are just humans and we will forget from
> > time to time. I was wondering if we can (yes, you guessed it) automate it
> > :). Either with JIRA/Github integration or some automated tool to do it
> > regularly and resolving all already merged tickets. And the more
> > committers we are going to have, the more it makes sense to automate some
> > of the work. The less you have to remember about your "chores" the more
> you
> > can focus on the "real" stuff.
> >
> > I think there are a few unwritten rules that we have - like what version
> > to set when we cherry-pick change to 1.10* . My understanding is that we
> > should set fixed version to the first unreleased yet 1.10. version. This
> > problem will soon be gone, so maybe it's not worth solving it. There are
> > also some edge cases like bad fixes which got reverted and reapplied but
> I
> > think other than that the automation of it can be rather simple.
> >
> > And I think there are some scripts in "dev" that already do some of that
> -
> > synchronising merges with JIRAs (but I don't think it's common knowledge
> > and it's not regularly run). Maybe we can improve it somehow and have it
> > fully automated so that we do not even havet to think about it ?
> >
> > WDYT? Any ideas?
> >
> > J.
> >
> >
> > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> >> We have some at
> >> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
> >>
> >> The person who merges the PR to master is the one who would be
> responsible
> >> for resolving the JIRA issue as they can add the *target version* based
> on
> >> what they think after reviewing the PR.
> >>
> >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> >> aizhamal@apache.org>
> >> wrote:
> >>
> >> > I think it will be good to document the process. For example, who is
> >> > responsible for closing Jira issues: folks who closed PR's or the ones
> >> who
> >> > opened?
> >> >
> >> > If the documentation already exists, let's bring it back to attention.
> >> >
> >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik <ka...@gmail.com>
> wrote:
> >> >
> >> > > Hi Committers,
> >> > >
> >> > > Please make sure to close the Jira issues if the related PRs are
> >> merged.
> >> > >
> >> > > I am going through the Jira Reports (Image:
> https://imgur.com/n50Ticx
> >> )
> >> > and
> >> > > was concerned with the gap between issues created & resolved in
> recent
> >> > > months.
> >> > >
> >> > > However, I noticed while going through the jira issues that most of
> >> the
> >> > PRs
> >> > > related to the JIRAs have been resolved but the JIRA is not
> resolved.
> >> > >
> >> > > Let's try to resolve all the issues when we merge the PR :)
> >> > >
> >> > > This will help the release manager too.
> >> > >
> >> > > Regards,
> >> > > Kaxil
> >> > >
> >> >
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
> >
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: Closing JIRA Issue for Merged PRs

[Jarek Potiuk <Ja...@polidea.com>]

And yes. I was one of the culprits -  I saw :(. Sorry about that Kaxil.
Just hope we can streamline this :).

On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk <Ja...@polidea.com>
wrote:

> Heartily agree with it !
>
> I try always to close the PRs but sometimes I got distracted and forget to
> resolve an issue - it happend several times that I recalled it few hours
> later that I have forgotten to resolve it. I hope it happens rarely - I'd
> love to know if I was one of the culprits here :). And whenever I noticed
> some of the PRs are not closed but PR is merged by someone else - I
> sometimes close them. But it's not ideal of course.
>
> However simple it is - I think we are just humans and we will forget from
> time to time. I was wondering if we can (yes, you guessed it) automate it
> :). Either with JIRA/Github integration or some automated tool to do it
> regularly and resolving all already merged tickets. And the more
> committers we are going to have, the more it makes sense to automate some
> of the work. The less you have to remember about your "chores" the more you
> can focus on the "real" stuff.
>
> I think there are a few unwritten rules that we have - like what version
> to set when we cherry-pick change to 1.10* . My understanding is that we
> should set fixed version to the first unreleased yet 1.10. version. This
> problem will soon be gone, so maybe it's not worth solving it. There are
> also some edge cases like bad fixes which got reverted and reapplied but I
> think other than that the automation of it can be rather simple.
>
> And I think there are some scripts in "dev" that already do some of that -
> synchronising merges with JIRAs (but I don't think it's common knowledge
> and it's not regularly run). Maybe we can improve it somehow and have it
> fully automated so that we do not even havet to think about it ?
>
> WDYT? Any ideas?
>
> J.
>
>
> On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com> wrote:
>
>> We have some at
>> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
>>
>> The person who merges the PR to master is the one who would be responsible
>> for resolving the JIRA issue as they can add the *target version* based on
>> what they think after reviewing the PR.
>>
>> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
>> aizhamal@apache.org>
>> wrote:
>>
>> > I think it will be good to document the process. For example, who is
>> > responsible for closing Jira issues: folks who closed PR's or the ones
>> who
>> > opened?
>> >
>> > If the documentation already exists, let's bring it back to attention.
>> >
>> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik <ka...@gmail.com> wrote:
>> >
>> > > Hi Committers,
>> > >
>> > > Please make sure to close the Jira issues if the related PRs are
>> merged.
>> > >
>> > > I am going through the Jira Reports (Image: https://imgur.com/n50Ticx
>> )
>> > and
>> > > was concerned with the gap between issues created & resolved in recent
>> > > months.
>> > >
>> > > However, I noticed while going through the jira issues that most of
>> the
>> > PRs
>> > > related to the JIRAs have been resolved but the JIRA is not resolved.
>> > >
>> > > Let's try to resolve all the issues when we merge the PR :)
>> > >
>> > > This will help the release manager too.
>> > >
>> > > Regards,
>> > > Kaxil
>> > >
>> >
>>
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
>

-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: Closing JIRA Issue for Merged PRs

[Jarek Potiuk <Ja...@polidea.com>]

Heartily agree with it !

I try always to close the PRs but sometimes I got distracted and forget to
resolve an issue - it happend several times that I recalled it few hours
later that I have forgotten to resolve it. I hope it happens rarely - I'd
love to know if I was one of the culprits here :). And whenever I noticed
some of the PRs are not closed but PR is merged by someone else - I
sometimes close them. But it's not ideal of course.

However simple it is - I think we are just humans and we will forget from
time to time. I was wondering if we can (yes, you guessed it) automate it
:). Either with JIRA/Github integration or some automated tool to do it
regularly and resolving all already merged tickets. And the more
committers we are going to have, the more it makes sense to automate some
of the work. The less you have to remember about your "chores" the more you
can focus on the "real" stuff.

I think there are a few unwritten rules that we have - like what version to
set when we cherry-pick change to 1.10* . My understanding is that we
should set fixed version to the first unreleased yet 1.10. version. This
problem will soon be gone, so maybe it's not worth solving it. There are
also some edge cases like bad fixes which got reverted and reapplied but I
think other than that the automation of it can be rather simple.

And I think there are some scripts in "dev" that already do some of that -
synchronising merges with JIRAs (but I don't think it's common knowledge
and it's not regularly run). Maybe we can improve it somehow and have it
fully automated so that we do not even havet to think about it ?

WDYT? Any ideas?

J.


On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik <ka...@gmail.com> wrote:

> We have some at
> https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide
>
> The person who merges the PR to master is the one who would be responsible
> for resolving the JIRA issue as they can add the *target version* based on
> what they think after reviewing the PR.
>
> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <
> aizhamal@apache.org>
> wrote:
>
> > I think it will be good to document the process. For example, who is
> > responsible for closing Jira issues: folks who closed PR's or the ones
> who
> > opened?
> >
> > If the documentation already exists, let's bring it back to attention.
> >
> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > Hi Committers,
> > >
> > > Please make sure to close the Jira issues if the related PRs are
> merged.
> > >
> > > I am going through the Jira Reports (Image: https://imgur.com/n50Ticx)
> > and
> > > was concerned with the gap between issues created & resolved in recent
> > > months.
> > >
> > > However, I noticed while going through the jira issues that most of the
> > PRs
> > > related to the JIRAs have been resolved but the JIRA is not resolved.
> > >
> > > Let's try to resolve all the issues when we merge the PR :)
> > >
> > > This will help the release manager too.
> > >
> > > Regards,
> > > Kaxil
> > >
> >
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: Closing JIRA Issue for Merged PRs

[Kaxil Naik <ka...@gmail.com>]

We have some at
https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide

The person who merges the PR to master is the one who would be responsible
for resolving the JIRA issue as they can add the *target version* based on
what they think after reviewing the PR.

On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat kyzy <ai...@apache.org>
wrote:

> I think it will be good to document the process. For example, who is
> responsible for closing Jira issues: folks who closed PR's or the ones who
> opened?
>
> If the documentation already exists, let's bring it back to attention.
>
> On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik <ka...@gmail.com> wrote:
>
> > Hi Committers,
> >
> > Please make sure to close the Jira issues if the related PRs are merged.
> >
> > I am going through the Jira Reports (Image: https://imgur.com/n50Ticx)
> and
> > was concerned with the gap between issues created & resolved in recent
> > months.
> >
> > However, I noticed while going through the jira issues that most of the
> PRs
> > related to the JIRAs have been resolved but the JIRA is not resolved.
> >
> > Let's try to resolve all the issues when we merge the PR :)
> >
> > This will help the release manager too.
> >
> > Regards,
> > Kaxil
> >
>

Re: Closing JIRA Issue for Merged PRs

[Aizhamal Nurmamat kyzy <ai...@apache.org>]

I think it will be good to document the process. For example, who is
responsible for closing Jira issues: folks who closed PR's or the ones who
opened?

If the documentation already exists, let's bring it back to attention.

On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik <ka...@gmail.com> wrote:

> Hi Committers,
>
> Please make sure to close the Jira issues if the related PRs are merged.
>
> I am going through the Jira Reports (Image: https://imgur.com/n50Ticx) and
> was concerned with the gap between issues created & resolved in recent
> months.
>
> However, I noticed while going through the jira issues that most of the PRs
> related to the JIRAs have been resolved but the JIRA is not resolved.
>
> Let's try to resolve all the issues when we merge the PR :)
>
> This will help the release manager too.
>
> Regards,
> Kaxil
>