[Releasing] Qt API review process (was: Re: Qt 5.11 Alpha released)

Kai Koehne Kai.Koehne at qt.io
Tue Mar 20 09:34:35 CET 2018


(comment below)

> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at 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




More information about the Releasing mailing list