[Releasing] Meeting minutes from Qt Release Team meeting 01.09.2020

[Lars Knoll]

> On 2 Sep 2020, at 12:48, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Jani Heikkinen (2 September 2020 08:28) wrote:
>> Meeting minutes from Qt Release Team meeting Tue 1st September 2020
> [snip]
>> - Target is to release Qt 6.0 Alpha ~mid September
>>  * FF exceptions should be in Alpha but if not those can be added later
> 
> I do not understand your "but ..." clause.
> 
> The things that don't need to be in (the last) alpha surely aren't
> actually features, just tidy-up after the feature's addition, So they
> aren't FF exceptions.  If it really is a feature, so really an exception
> to FF, I don't think an alpha without it can be a final alpha.

No, but an initial one. The goal is to have usable packages out as soon as possible, so we can start collecting feedback from a larger audience. We can in principle release Alpha1 with one or two features still missing (but we will then need another Alpha once they are in).
> 
> Adding features part way through the beta phase destroys the meaning of
> the boundary between alpha and beta.

The final Alpha needs to be feature complete. Ie. we can’t move over to Beta with features missing.
> 
>> irc log below:
> [snip]
>> [17:05:26] <jaheikki3> There is few exceptions given but otherwise we
>> should start focusing to maturize content for coming release
>> [17:05:56] <thiago> I assume API is not frozen
>> [17:06:05] <lars> as I said in the mail, no.
>> [17:06:02] <thiago> so we're allowed to fix API mistakes still
>> [17:06:34] <jaheikki3> Yeah, API reviews should be start now
>> [17:06:35] <lars> I'll start with a full API review round from next week.
>> [17:06:51] <lars> (need to finish the property work this week)
>> [17:07:25] <jaheikki3> I'll ask addy to run his scripts for API
>> review; that will be good starting point for review
> 
> Be aware that this will only document *changes* the the APIs.  Still,
> Gerrit lets you show the rest of each file, and most files that matter
> should be in the review, so you can use it as a start-point for review
> of whole APIs, not just the changes.  Just don't forget there are other
> files to look at - the fact that they haven't changed doesn't mean we
> don't need to review their APIs, if only for impact from the changes we
> have made.
> 
> Please check for any "fix this at Qt 6" comments that didn't match the
> greps various of us have been doing ... although the first draft of the
> reviews still won't contain all the fixes resulting from those sweeps -
> I'm still kicking corelib's ones through Coin, there may be others ...
> 
>> [17:08:25] <thiago> I'll keep my questions on this to the email
>> [17:08:34] <lars> Yes, please. At the minimum it'll help us identify
>> the areas where we need to look closely
>> [17:09:09] <lars> sure :)
>> [17:09:45] <jaheikki3> Usually we have branched at this time but after
>> discussion in qt company I propose we will delay branching a while; it
>> will make qt6 development easier and there is no hurry to start Qt6.1
>> development yet
>> [17:11:03] <lars> +1. I don't want to start cherry-picking into 6.0
>> just yet
>> [17:11:36] <thiago> makes sense
>> [17:11:40] <thiago> we still have too much API to fix
>> [17:11:50] <thiago> no one should be really working on 6.1 features
> 
> That means those of us who're having to defer features we were working
> on, but didn't have ready in time for 6.0, are stuck not integrating
> them until you *do* branch 6.0 off from dev - so please don't leave it
> *too* long.  Still, the fact that they're not ready yet does indeed mean
> we won't be ready to integrate for a while, if only due to working on
> 6.0 things instead.
> 
>> [17:12:29] <jaheikki3> true
>> [17:13:21] <lars> At the minimum the API review should be done before
>> we consider branching
> 
> As a practical matter, that's going to oblige me to adapt my scripts so
> that I can tell them the release version number (or get them to look it
> up in a relevant header), instead of exploiting the fact that the
> release number *is* the branch name (always assumed until now), so that
> the review subject (and local review-branch names) are sensible.
> But it shouldn't be tricky.
> 
> I am uncomfortable about "should be done" - as in finished - although
> I'm fine with "should be *started*" (modulo the script-fixing above)
> but ... see note below on post-alpha API changes.

I want us to be through with at least a full round of reviews before branching, so that we avoid excessive cherry-picking.

But API reviews for 6.0 need to be more than the sanity checking we have usually done for API changes in minor releases. We need to look at the whole class (or functionality group) and review the API as a whole.
> 
>> [17:14:17] <jaheikki3> Agree
>> [17:14:18] <thiago> we may wish to delay even further, given this is
>> the first feature release with the new branching model
> 
> This amounts to closing dev to new features until you get round to
> branching 6.0, which adds to the pain for those whose features weren't
> ready in time for 6.0 FF.  I get that it does have its benefits
> (including that changes made after such dev-features would suffer
> pick-conflicts on the way to 6.0), but don't lose sight of the pain
> you're causing for developers who had too many things to do for 6.0 and
> are now left holding the ones we didn't have ready in time.

The focus for all of us has to be to get Qt 6.0 ready, not work on features that will only make it into 6.x. Let those patches sit on gerrit for a while and pick them up again when we’re ready to start 6.1 feature development.
> 
>> [17:15:28] <lars> agree. let's see when we get to a more stable
>> state. The RCs should be done from a branch IMO, anything else we can
>> discuss.
> 
> The RCs *should* be done from a 6.0.0 branch *off* a by-then-extant 6.0
> branch (that shall subsequently fork side-branches for 6.0.n for
> successive n).  Please do not try to delay branching 6.0 any later than
> that.  I recommend branching 6.0 no later than during the beta phase.

Of course we’ll need both a 6.0 and a 6.0.0 branch as usual. But let’s take the decision when exactly to branch when we get closer to beta and have a better overview over the state of Qt 6.
> 
>> [17:16:21] <jaheikki3> Yeah, let's agree the branching time later
>> [17:16:49] <jaheikki3> Branching in cherry-pick mode is quite easy and
>> it won't take that long time to complete...
> 
> Therefore it doesn't need to be delayed much, although doing so does
> save the need for Pick-to: 6.0 for a while.  Whenever you *do* branch
> 6.0 out, there shall be some reviews caught without Pick-to: 6.0 that
> have to be manually picked to 6.0, possibly after those involved with
> them notice the change didn't make it to 6.0, so branching earlier gives
> those who *do* get caught by this longer to sort it out (and to notice
> that they *need* to sort it out).

It’s not the branching that’s the problem, but the added overhead for all of us trying to get 6.0 out of the door. The cherry-pick mode adds delay until the fix reaches the 6.0 branch (it needs to integrate into dev first). While this is ok for a stable branch as 5.15, we really don’t want this right now for what will become 6.0.
> 
>> [17:17:41] <jaheikki3>  Qt 6.0 alpha is planned to be released ~mid
>> September but on the other hand those FF exceptions needs to be in
>> alpha
>> [17:17:47] <jaheikki3>  so let's see if we can keep that plan or not...
>> [17:18:08] <lars> let's say they should be in the alpha.
>> [17:18:25] <jaheikki3> Yes, agree :D
>> [17:18:41] <lars> but as we're still going to do API changes to react
>> to feedback from the alpha it's not a 100% must.
> 
> Which means that API change review can't be declared finished until
> after alpha and the subsequent wave of API changes.  So if you intend to
> defer branching until after API change review is done, you're in fact
> deferring it until some time during the beta phase.  As noted above, I
> think that's the latest it can be sensible to delay it.
> 
> ... and, as noted above, while this countenances API changes, I consider
> it unwise to be making feature changes any later than the end of the
> alpha phase.  API clean-ups to the new feature, or consequent upon it,
> are understandable, although we should try to get them sorted during
> alpha; and the API change review can't close until they're done.

I guess that’s understood. The final Alpha has to be feature complete. And we don’t do new feature work on 6.0 anymore (with the given exceptions).

Cheers,
Lars

> 
>> [17:19:20] <lars> if we have usable packages that work at least on the
>> desktop platforms, I'd be ok to label that alpha 1, and rather add a
>> alpha2 a week later
>> [17:20:18] <thiago> we should release an alpha 1 ASAP
> 
> hmm ... QA may need to check some scripts cope with numbering of alphas
> - they probably do, but haven't been used with numbered alphas
> previously ... @Dan, please check our python code using the version class ...
> 
> 	Eddy.
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> https://lists.qt-project.org/listinfo/releasing