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@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@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
