[Development] Closing issues automatically with new keyword

[Frederik Gladhorn]

On onsdag 8. august 2018 12.13.46 CEST André Hartmann wrote:
> Hi Frederik,
> 
> one more question: does the script also sets the final Git-SHA1 in the
> Jira "commits" field?
> 
> If yes, that would really be a *big* improvement.

Yes, that's the plan.

Frederik


> 
>  > Everything else (wip/foobar, other branch names) will be ignored,
>  > unless someone explains what to do with them otherwise.
> 
> I think that's acceptable.
> 
> André
> 
> Am 08.08.2018 um 11:58 schrieb Frederik Gladhorn:
> > On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> >>> -----Original Message-----
> >>> From: Development <development-bounces+alexander.blasche=qt.io at qt-
> >>> project.org> On Behalf Of Jani Heikkinen
> >>> 
> >>>> The plan is to update the fix versions and close the task as done when
> >>>> a line in the commit message starts with "Fixes:".
> >>>> If the issue is already closed (e.g. cherry-pick) it can add an
> >>>> additional fix version (e.g. 5.9.7).
> >> 
> >> The devil is in the detail. We don't want FixVersion to be set to 5.11
> >> but
> >> set to 5.11.x.  When you look at a bug 6 month down the road you don't
> >> want
> >> to know that it was fixed in 5.11 but you want to know the exact patch
> >> level release. Especially the LTS releases tend to have many patch lvl
> >> number.
> >> 
> >> This implies that the script needs to know when 5.11.x was branched off
> >> and
> >> that every following commit to 5.11 branch will imply 5.11.x+1. Whether
> >> x+1
> >> may never be released is irrelevant though as that's a simple bulk change
> >> when the decision to not have x+1 comes through. Is this what you intend
> >> to
> >> do?
> > 
> > Indeed, I have to make some assumptions.
> > Right now I have the simple case done: branch == x.y.z -> set fix version
> > to x.y.z.
> > 
> > Then there are two cases that I will handle:
> > branch is 'dev' or 'master' -> find the next minor version
> > branch is x.y -> find the next valid patch version
> > 
> > Everything else (wip/foobar, other branch names) will be ignored, unless
> > someone explains what to do with them otherwise.
> > 
> >>> I see at least one problem there: If bug is affecting to several
> >>> branches
> >>> it will be closed when fix for first branch is done even in that case it
> >>> shouldn't be closed until every branch has a fix...
> >> 
> >> That's the developer's decision as much as it is today already. If you
> >> know
> >> that the fix should go to multiple branches you should probably not use
> >> the
> >> "Fixes" keyword for the first commit but the existing "Task-number"
> >> keyword.
> > 
> > My plan was to let the bot add additional fix versions as changes move
> > through branches.
> > So if a Fixes: QTBUG-9999 goes into 5.12.1, the bug gets closed and fix
> > version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot
> > will see the change again and will add a fix version 5.9.8.
> > 
> >>> Another concern or question is that in which phase we should close the
> >>> bug; is it done immediately when fix is in or should it be done when fix
> >>> is in the packages and someone can verify that fix is there and really
> >>> fixes the problem...
> >> 
> >> It can only ever be when it is in the code line. That's correct for 90%
> >> of
> >> all cases. We cannot optimize for the case when releasing becomes
> >> creative
> >> and starts shifting around SHA's or decides to create the package. I am
> >> sure releasing does not want to be responsible for setting the fix
> >> version
> >> across all tasks. It does not scale. In other words the status quo
> >> applies.
> > 
> > Agreed. There is no magic solution and we need to close bugs, even when
> > the
> > fix is not released yet, otherwise JIRA becomes useless.
> > Everyone will understand that if something is closed for 5.12.0 today, it
> > will not be in their copy of Qt 5.11.0.
> > Right now we often don't set the fix version at all, which is even more
> > harmful in my opinion.
> > 
> > Frederik
> > 
> >> --
> >> Alex
> > 
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development