(comment below) > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Jani Heikkinen > Subject: [Development] Qt API review process (was: Re: Qt 5.11 Alpha > released) > > Hi all, > > We have API review ongoing for Qt 5.11. For me our process for that is a bit > unclear; At which point we can say the review is really done? There are > comments in the reviews but then pretty much nothing... At some there is -1, > few +1 but that's it. I think we should clarify the process so that we can > more > easily see the status there. That's why I propose following: > > 1) API review for the module is ready when there is '+2' (from Module/Chief > Maintainer) > 2) During the review reviewer must add 'Code Review -1/-2' if there is > something which should be corrected before we can agree API review to be > ready. And vice versa: if API seems to be OK +1 should be added to indicate > API > is reviewed. > 3) Reviewer needs to create a bug report about the findings. That makes it > easier to follow up & we can add needed ones in the release blocker list. > * These bug reports should be added in review's comment field as well. And > if > one is something which really needs to be fixed before release reviewer should > add the issue in release blocker list. > 4) API review for module needs to be updated in gerrit until it gets '+2'. > After > that no more updates. That way we can link the approved review in releasing > wiki for the evidence :D
I would rather create a task in JIRA for the review itself, with priority 1 and appropriate fixVersion. Any subsequent findings could be made subtasks of this task. This automatically makes the API review part of the blockers list, and makes sure everyone understands that this needs to be done before a release. Regards Kai _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
