[Development] Qt 5.12 schedule proposal & proposal for release process change

[Edward Welbourne]

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)
> I have to disagree a bit: Alpha and beta phases are important and
> schedule for FF (and Alpha) as well. But for beta and RC we really
> don't need it: After API review is done we will enter in beta phase
> (and at this same time beta1 is released). And we should release RC
> when all blockers are fixed.  If we schedule the RC beforehand it
> seems to affect how developers are prioritizing their work. And that's
> why I think we shouldn't even estimate when the RC is going to be
> happen: It is released when we are ready for it.

Interesting reasoning.  There is a degree to which, for each of these
transitions, "it's ready when it's ready"; but that doesn't mean we
shouldn't even attempt to guess when that'll be in advance.  Perhaps
rather than a "planned date" we should work with the date we hope for,
as that may focus folk's attention more closely on getting things fixed
early.

> So  I think the way to proceed with this should be like Lars proposed:
> - Snapshot packages from the dev branch
> - FF and branching occur together and packages are getting the ‘alpha’ tag
> - 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

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.

I don't see anyone volunteering to write that QUIP, so I'll do so when
time permits, unless someone else speaks up first.

* [0] http://lists.qt-project.org/pipermail/development/2018-March/032362.html

> - RC once we have the release branch and all currently known blockers are fixed

You'll have the release branch just after alpha, if you follow the plan
above, so the only condition left here is the known blockers.  Even on
those, we've had some flexibility in the past - some blockers do get
downgraded sometimes - which can serve to steer a release towards
fitting a schedule.

To paraphrase and possibly mangle Jani's plan (without opinion on
whether I like it; this is about making sure I understand the plan):

Summary:
* Make snapshots and FF, not release, the time-based part of our process.

Details:
* Make snap-shots regularly, merely changing their naming as we move
  through the phases below.
* Branch, release first alpha and start API review at FF.  Ever step
  after this takes as long as it does; and we try to keep each short.
* Name snap-shots alpha n; all API changes must be notified to the
  review for their module, prompting an update to that review.
* When API review is complete and all features are completely
  implemented, transition to beta.  Only bug-fixes come in after this.
* Name snap-shots beta n after this; ask folk to test beta 1 and report
  bugs; triage bugs, fix blockers.
* When the blocker list is empty, transition to RC.  If we can't find
  any "brown paper bag" issues, ship it; otherwise, fix, rinse and
  repeat.

Jani: how far have I mangled your intent in expressing it thus ?

	Eddy.