[Releasing] Meeting minutes from Qt Release Team meeting 01.09.2020

[Edward Welbourne]

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.

Adding features part way through the beta phase destroys the meaning of
the boundary between alpha and beta.

> 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.

> [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.

> [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.

> [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).

> [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.

> [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.