You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Jarek Potiuk <Ja...@polidea.com> on 2019/12/17 21:44:23 UTC
Setting fixVersion and "Resolved" status in JIRA
Hello Commiters,
I think the current way of managing JIRA issues "fixVersion" and resolving
tickets does not work well. We have an agreement that we set the
"fixVersion" to either 1.10.<to be released> or 2.0.0 depending on whether
we cherry-pick it to v1-10-test or not. But many of us (including myself)
forgetts to do it from time to time.
I worked with Kaxil today to fix some tests for 1.10.7 and Kaxil asked me
to check if there are any missing issues I cherry-picked and have not set
fixedVersion in JIRA. I found a few that were missing, so I figured that I
will check all of them. I did some semi-automated way of checking it and ...
I found 99 (!) tickets that were already fixed in master which were either
not resolved yet or had fixVersion set to Empty.
I am fixing the JIRA fixVersion now one by one - but it is fairly slow
proces (as I want to make sure there is no mistake).
There is no single person to blame (I am as guilty as anyone else there),
but it is clear indication that the process we have now does not work well.
I think we need to work out some way to make this process better and really
automate this part. I will clean the issues up now, but then any future
commits/cherry-picks will again cause problems.
Maybe someone has an idea how we can solve it quickly and permanently ?
J.
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: Setting fixVersion and "Resolved" status in JIRA
Posted by Jarek Potiuk <Ja...@polidea.com>.
Yeah Bjorn. I think we already discussed/agreed that we are going to use
probot. Might be the best idea to use it for that purpose.
J.
On Wed, Dec 18, 2019 at 6:38 AM Bjorn Olsen <bj...@gmail.com> wrote:
> Hi all,
>
> Perhaps something like probot would work.
>
> My 2 cents :)
>
>
> On Wed, 18 Dec 2019, 00:32 Kaxil Naik, <ka...@gmail.com> wrote:
>
> > Yea that's how the idea actually popped up :D as I remember we have a
> daily
> > CRON job already configured.
> >
> > On Tue, Dec 17, 2019 at 10:16 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > I love the idea of the daily check. We actually already have a daily
> CRON
> > > job that runs nightly - we can use it for that purpose :)
> > >
> > > Continuing working on reviewing the issues for now 20/99 to go.
> > >
> > > BTW. If you are interested. This will produce a list of all issues that
> > > were implemented since 2.0.0/1.10 branches diverged:
> > >
> > > git log ecf68c7d3133b2cb9847b2f21b674482cd076358..HEAD --oneline | awk
> > > '{print $2}' | sort | uniq | grep -e
> '^\[AIRFLOW\-[0-9][0-9][0-9][0-9]]'
> > |
> > > sed 's/^.*\[\(AIRFLOW\-[0-9][0-9][0-9][0-9]\)\].*$/\1/' | tr "\n" ","
> > >
> > > In the form that can be pasted in JIRA advanced search query:
> > >
> > > project = "Apache Airflow" AND fixVersion is EMPTY AND issue in
> > > (<PASTE_YOUR_ISSUES_HERE>)
> > >
> > > To find all "missed" issues.
> > >
> > > J.
> > >
> > > On Tue, Dec 17, 2019 at 11:00 PM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >
> > > > I think until we find the solution all of us (PMC + Committers) need
> to
> > > own
> > > > it up and *Resolve* the Jira issues when we merge the PRs.
> > > >
> > > > Previously we use the CLI that Bolke created to Close/Merge the PR
> > which
> > > > would also automatically Resolve the Jira issue with the correct
> > version.
> > > > Check this:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97553054
> > > >
> > > > At some point in time, we moved to GitBox so that committers were
> able
> > to
> > > > directly merge the PRs from the Github UI, however, because of which
> we
> > > no
> > > > longer have an automated process to close JIRAs.
> > > >
> > > > Also, I have seen PRs and JIRA issues that have no description at all
> > and
> > > > are just empty. We need to be careful about it and make sure we add
> > > > necessary details and close the JIRAs.
> > > >
> > > > Regarding how we can automate this: I think we can add a step in CI
> > that
> > > > runs via CRON that would check that the JIRA associated with the PRs
> > > merged
> > > > in the last 1 days have been Resolved with a Fix Version. This is not
> > > hard
> > > > to implement. I can work on it once I have some time after we release
> > > > 1.10.7 but no promises :)
> > > >
> > > > Regards,
> > > > Kaxil
> > > >
> > > > On Tue, Dec 17, 2019 at 9:44 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > > > wrote:
> > > >
> > > > > Hello Commiters,
> > > > >
> > > > > I think the current way of managing JIRA issues "fixVersion" and
> > > > resolving
> > > > > tickets does not work well. We have an agreement that we set the
> > > > > "fixVersion" to either 1.10.<to be released> or 2.0.0 depending on
> > > > whether
> > > > > we cherry-pick it to v1-10-test or not. But many of us (including
> > > myself)
> > > > > forgetts to do it from time to time.
> > > > >
> > > > > I worked with Kaxil today to fix some tests for 1.10.7 and Kaxil
> > asked
> > > me
> > > > > to check if there are any missing issues I cherry-picked and have
> not
> > > set
> > > > > fixedVersion in JIRA. I found a few that were missing, so I figured
> > > that
> > > > I
> > > > > will check all of them. I did some semi-automated way of checking
> it
> > > and
> > > > > ...
> > > > >
> > > > > I found 99 (!) tickets that were already fixed in master which were
> > > > either
> > > > > not resolved yet or had fixVersion set to Empty.
> > > > >
> > > > > I am fixing the JIRA fixVersion now one by one - but it is fairly
> > slow
> > > > > proces (as I want to make sure there is no mistake).
> > > > >
> > > > > There is no single person to blame (I am as guilty as anyone else
> > > there),
> > > > > but it is clear indication that the process we have now does not
> work
> > > > well.
> > > > >
> > > > > I think we need to work out some way to make this process better
> and
> > > > really
> > > > > automate this part. I will clean the issues up now, but then any
> > future
> > > > > commits/cherry-picks will again cause problems.
> > > > >
> > > > > Maybe someone has an idea how we can solve it quickly and
> > permanently ?
> > > > >
> > > > > J.
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > 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: Setting fixVersion and "Resolved" status in JIRA
Posted by Bjorn Olsen <bj...@gmail.com>.
Hi all,
Perhaps something like probot would work.
My 2 cents :)
On Wed, 18 Dec 2019, 00:32 Kaxil Naik, <ka...@gmail.com> wrote:
> Yea that's how the idea actually popped up :D as I remember we have a daily
> CRON job already configured.
>
> On Tue, Dec 17, 2019 at 10:16 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > I love the idea of the daily check. We actually already have a daily CRON
> > job that runs nightly - we can use it for that purpose :)
> >
> > Continuing working on reviewing the issues for now 20/99 to go.
> >
> > BTW. If you are interested. This will produce a list of all issues that
> > were implemented since 2.0.0/1.10 branches diverged:
> >
> > git log ecf68c7d3133b2cb9847b2f21b674482cd076358..HEAD --oneline | awk
> > '{print $2}' | sort | uniq | grep -e '^\[AIRFLOW\-[0-9][0-9][0-9][0-9]]'
> |
> > sed 's/^.*\[\(AIRFLOW\-[0-9][0-9][0-9][0-9]\)\].*$/\1/' | tr "\n" ","
> >
> > In the form that can be pasted in JIRA advanced search query:
> >
> > project = "Apache Airflow" AND fixVersion is EMPTY AND issue in
> > (<PASTE_YOUR_ISSUES_HERE>)
> >
> > To find all "missed" issues.
> >
> > J.
> >
> > On Tue, Dec 17, 2019 at 11:00 PM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > I think until we find the solution all of us (PMC + Committers) need to
> > own
> > > it up and *Resolve* the Jira issues when we merge the PRs.
> > >
> > > Previously we use the CLI that Bolke created to Close/Merge the PR
> which
> > > would also automatically Resolve the Jira issue with the correct
> version.
> > > Check this:
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97553054
> > >
> > > At some point in time, we moved to GitBox so that committers were able
> to
> > > directly merge the PRs from the Github UI, however, because of which we
> > no
> > > longer have an automated process to close JIRAs.
> > >
> > > Also, I have seen PRs and JIRA issues that have no description at all
> and
> > > are just empty. We need to be careful about it and make sure we add
> > > necessary details and close the JIRAs.
> > >
> > > Regarding how we can automate this: I think we can add a step in CI
> that
> > > runs via CRON that would check that the JIRA associated with the PRs
> > merged
> > > in the last 1 days have been Resolved with a Fix Version. This is not
> > hard
> > > to implement. I can work on it once I have some time after we release
> > > 1.10.7 but no promises :)
> > >
> > > Regards,
> > > Kaxil
> > >
> > > On Tue, Dec 17, 2019 at 9:44 PM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > wrote:
> > >
> > > > Hello Commiters,
> > > >
> > > > I think the current way of managing JIRA issues "fixVersion" and
> > > resolving
> > > > tickets does not work well. We have an agreement that we set the
> > > > "fixVersion" to either 1.10.<to be released> or 2.0.0 depending on
> > > whether
> > > > we cherry-pick it to v1-10-test or not. But many of us (including
> > myself)
> > > > forgetts to do it from time to time.
> > > >
> > > > I worked with Kaxil today to fix some tests for 1.10.7 and Kaxil
> asked
> > me
> > > > to check if there are any missing issues I cherry-picked and have not
> > set
> > > > fixedVersion in JIRA. I found a few that were missing, so I figured
> > that
> > > I
> > > > will check all of them. I did some semi-automated way of checking it
> > and
> > > > ...
> > > >
> > > > I found 99 (!) tickets that were already fixed in master which were
> > > either
> > > > not resolved yet or had fixVersion set to Empty.
> > > >
> > > > I am fixing the JIRA fixVersion now one by one - but it is fairly
> slow
> > > > proces (as I want to make sure there is no mistake).
> > > >
> > > > There is no single person to blame (I am as guilty as anyone else
> > there),
> > > > but it is clear indication that the process we have now does not work
> > > well.
> > > >
> > > > I think we need to work out some way to make this process better and
> > > really
> > > > automate this part. I will clean the issues up now, but then any
> future
> > > > commits/cherry-picks will again cause problems.
> > > >
> > > > Maybe someone has an idea how we can solve it quickly and
> permanently ?
> > > >
> > > > J.
> > > >
> > > >
> > > > --
> > > >
> > > > 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: Setting fixVersion and "Resolved" status in JIRA
Posted by Kaxil Naik <ka...@gmail.com>.
Yea that's how the idea actually popped up :D as I remember we have a daily
CRON job already configured.
On Tue, Dec 17, 2019 at 10:16 PM Jarek Potiuk <Ja...@polidea.com>
wrote:
> I love the idea of the daily check. We actually already have a daily CRON
> job that runs nightly - we can use it for that purpose :)
>
> Continuing working on reviewing the issues for now 20/99 to go.
>
> BTW. If you are interested. This will produce a list of all issues that
> were implemented since 2.0.0/1.10 branches diverged:
>
> git log ecf68c7d3133b2cb9847b2f21b674482cd076358..HEAD --oneline | awk
> '{print $2}' | sort | uniq | grep -e '^\[AIRFLOW\-[0-9][0-9][0-9][0-9]]' |
> sed 's/^.*\[\(AIRFLOW\-[0-9][0-9][0-9][0-9]\)\].*$/\1/' | tr "\n" ","
>
> In the form that can be pasted in JIRA advanced search query:
>
> project = "Apache Airflow" AND fixVersion is EMPTY AND issue in
> (<PASTE_YOUR_ISSUES_HERE>)
>
> To find all "missed" issues.
>
> J.
>
> On Tue, Dec 17, 2019 at 11:00 PM Kaxil Naik <ka...@gmail.com> wrote:
>
> > I think until we find the solution all of us (PMC + Committers) need to
> own
> > it up and *Resolve* the Jira issues when we merge the PRs.
> >
> > Previously we use the CLI that Bolke created to Close/Merge the PR which
> > would also automatically Resolve the Jira issue with the correct version.
> > Check this:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97553054
> >
> > At some point in time, we moved to GitBox so that committers were able to
> > directly merge the PRs from the Github UI, however, because of which we
> no
> > longer have an automated process to close JIRAs.
> >
> > Also, I have seen PRs and JIRA issues that have no description at all and
> > are just empty. We need to be careful about it and make sure we add
> > necessary details and close the JIRAs.
> >
> > Regarding how we can automate this: I think we can add a step in CI that
> > runs via CRON that would check that the JIRA associated with the PRs
> merged
> > in the last 1 days have been Resolved with a Fix Version. This is not
> hard
> > to implement. I can work on it once I have some time after we release
> > 1.10.7 but no promises :)
> >
> > Regards,
> > Kaxil
> >
> > On Tue, Dec 17, 2019 at 9:44 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > Hello Commiters,
> > >
> > > I think the current way of managing JIRA issues "fixVersion" and
> > resolving
> > > tickets does not work well. We have an agreement that we set the
> > > "fixVersion" to either 1.10.<to be released> or 2.0.0 depending on
> > whether
> > > we cherry-pick it to v1-10-test or not. But many of us (including
> myself)
> > > forgetts to do it from time to time.
> > >
> > > I worked with Kaxil today to fix some tests for 1.10.7 and Kaxil asked
> me
> > > to check if there are any missing issues I cherry-picked and have not
> set
> > > fixedVersion in JIRA. I found a few that were missing, so I figured
> that
> > I
> > > will check all of them. I did some semi-automated way of checking it
> and
> > > ...
> > >
> > > I found 99 (!) tickets that were already fixed in master which were
> > either
> > > not resolved yet or had fixVersion set to Empty.
> > >
> > > I am fixing the JIRA fixVersion now one by one - but it is fairly slow
> > > proces (as I want to make sure there is no mistake).
> > >
> > > There is no single person to blame (I am as guilty as anyone else
> there),
> > > but it is clear indication that the process we have now does not work
> > well.
> > >
> > > I think we need to work out some way to make this process better and
> > really
> > > automate this part. I will clean the issues up now, but then any future
> > > commits/cherry-picks will again cause problems.
> > >
> > > Maybe someone has an idea how we can solve it quickly and permanently ?
> > >
> > > J.
> > >
> > >
> > > --
> > >
> > > 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: Setting fixVersion and "Resolved" status in JIRA
Posted by Jarek Potiuk <Ja...@polidea.com>.
I love the idea of the daily check. We actually already have a daily CRON
job that runs nightly - we can use it for that purpose :)
Continuing working on reviewing the issues for now 20/99 to go.
BTW. If you are interested. This will produce a list of all issues that
were implemented since 2.0.0/1.10 branches diverged:
git log ecf68c7d3133b2cb9847b2f21b674482cd076358..HEAD --oneline | awk
'{print $2}' | sort | uniq | grep -e '^\[AIRFLOW\-[0-9][0-9][0-9][0-9]]' |
sed 's/^.*\[\(AIRFLOW\-[0-9][0-9][0-9][0-9]\)\].*$/\1/' | tr "\n" ","
In the form that can be pasted in JIRA advanced search query:
project = "Apache Airflow" AND fixVersion is EMPTY AND issue in
(<PASTE_YOUR_ISSUES_HERE>)
To find all "missed" issues.
J.
On Tue, Dec 17, 2019 at 11:00 PM Kaxil Naik <ka...@gmail.com> wrote:
> I think until we find the solution all of us (PMC + Committers) need to own
> it up and *Resolve* the Jira issues when we merge the PRs.
>
> Previously we use the CLI that Bolke created to Close/Merge the PR which
> would also automatically Resolve the Jira issue with the correct version.
> Check this:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97553054
>
> At some point in time, we moved to GitBox so that committers were able to
> directly merge the PRs from the Github UI, however, because of which we no
> longer have an automated process to close JIRAs.
>
> Also, I have seen PRs and JIRA issues that have no description at all and
> are just empty. We need to be careful about it and make sure we add
> necessary details and close the JIRAs.
>
> Regarding how we can automate this: I think we can add a step in CI that
> runs via CRON that would check that the JIRA associated with the PRs merged
> in the last 1 days have been Resolved with a Fix Version. This is not hard
> to implement. I can work on it once I have some time after we release
> 1.10.7 but no promises :)
>
> Regards,
> Kaxil
>
> On Tue, Dec 17, 2019 at 9:44 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Hello Commiters,
> >
> > I think the current way of managing JIRA issues "fixVersion" and
> resolving
> > tickets does not work well. We have an agreement that we set the
> > "fixVersion" to either 1.10.<to be released> or 2.0.0 depending on
> whether
> > we cherry-pick it to v1-10-test or not. But many of us (including myself)
> > forgetts to do it from time to time.
> >
> > I worked with Kaxil today to fix some tests for 1.10.7 and Kaxil asked me
> > to check if there are any missing issues I cherry-picked and have not set
> > fixedVersion in JIRA. I found a few that were missing, so I figured that
> I
> > will check all of them. I did some semi-automated way of checking it and
> > ...
> >
> > I found 99 (!) tickets that were already fixed in master which were
> either
> > not resolved yet or had fixVersion set to Empty.
> >
> > I am fixing the JIRA fixVersion now one by one - but it is fairly slow
> > proces (as I want to make sure there is no mistake).
> >
> > There is no single person to blame (I am as guilty as anyone else there),
> > but it is clear indication that the process we have now does not work
> well.
> >
> > I think we need to work out some way to make this process better and
> really
> > automate this part. I will clean the issues up now, but then any future
> > commits/cherry-picks will again cause problems.
> >
> > Maybe someone has an idea how we can solve it quickly and permanently ?
> >
> > J.
> >
> >
> > --
> >
> > 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: Setting fixVersion and "Resolved" status in JIRA
Posted by Kaxil Naik <ka...@gmail.com>.
I think until we find the solution all of us (PMC + Committers) need to own
it up and *Resolve* the Jira issues when we merge the PRs.
Previously we use the CLI that Bolke created to Close/Merge the PR which
would also automatically Resolve the Jira issue with the correct version.
Check this:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97553054
At some point in time, we moved to GitBox so that committers were able to
directly merge the PRs from the Github UI, however, because of which we no
longer have an automated process to close JIRAs.
Also, I have seen PRs and JIRA issues that have no description at all and
are just empty. We need to be careful about it and make sure we add
necessary details and close the JIRAs.
Regarding how we can automate this: I think we can add a step in CI that
runs via CRON that would check that the JIRA associated with the PRs merged
in the last 1 days have been Resolved with a Fix Version. This is not hard
to implement. I can work on it once I have some time after we release
1.10.7 but no promises :)
Regards,
Kaxil
On Tue, Dec 17, 2019 at 9:44 PM Jarek Potiuk <Ja...@polidea.com>
wrote:
> Hello Commiters,
>
> I think the current way of managing JIRA issues "fixVersion" and resolving
> tickets does not work well. We have an agreement that we set the
> "fixVersion" to either 1.10.<to be released> or 2.0.0 depending on whether
> we cherry-pick it to v1-10-test or not. But many of us (including myself)
> forgetts to do it from time to time.
>
> I worked with Kaxil today to fix some tests for 1.10.7 and Kaxil asked me
> to check if there are any missing issues I cherry-picked and have not set
> fixedVersion in JIRA. I found a few that were missing, so I figured that I
> will check all of them. I did some semi-automated way of checking it and
> ...
>
> I found 99 (!) tickets that were already fixed in master which were either
> not resolved yet or had fixVersion set to Empty.
>
> I am fixing the JIRA fixVersion now one by one - but it is fairly slow
> proces (as I want to make sure there is no mistake).
>
> There is no single person to blame (I am as guilty as anyone else there),
> but it is clear indication that the process we have now does not work well.
>
> I think we need to work out some way to make this process better and really
> automate this part. I will clean the issues up now, but then any future
> commits/cherry-picks will again cause problems.
>
> Maybe someone has an idea how we can solve it quickly and permanently ?
>
> J.
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>