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 <kaxiln...@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.pot...@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/>
