Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) >>> ... I do like to emphasize though that the dates for first beta and >>> first RC are important (and FF is alpha) because they define times >>> when certain level of changes are no longer permitted (e.g. after >>> first beta no API changes). Therefore, you will not get around >>> setting a target date for first Beta and RC.
Jani Heikkinen (17 April 2018 08:28) >> - Agree that we should start with the API review immediately. >> - Beta once API review is done. Lets agree the 'Done' properly to get >> it clear for everyone. I already tried to start discussion about it in >> http://lists.qt-project.org/pipermail/development/2018-March/032338.html Edward Welbourne (17 April 2018 11:08) > As noted in [0], this looks like QUIP material. Kai proposed, in a > reply to [0], having a Jira ticket to track the review, with each issue > it raises being turned into a sub-task of it. Your Done condition would > then be the closing of that ticket, which would happen when every API > review has got a +2, upon which I abandon it. I'll re-open a review, > though, if I see any further apparently-material API changes, when I'm > preparing updates to other reviews. > > * [0] http://lists.qt-project.org/pipermail/development/2018-March/032362.html > > I don't see anyone volunteering to write that QUIP, so I'll do so when > time permits, unless someone else speaks up first. Here's my first attempt at that QUIP: https://codereview.qt-project.org/226574 Eddy. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
