[Development] Qt 5.8 branching & Feature Freeze

[Jędrzej Nowacki]

On Thursday 16 of June 2016 06:57:50 Tony Sarajärvi wrote:
> Hi,
> 
> Our aim was to get new platforms in immediately after the previous platforms
> branched away from dev branch. Meaning, when 5.7 branch was created and it
> branched away from dev branch, all new platforms aiming for 5.8 should have
> been put into dev branch. However, in practice it didn't quite go as
> expected. Not to blame anyone, but all focus was to get 5.6.x and 5.7.x
> out. Meaning, dev branch was left broken for several months. The individual
> submodules did pass in the CI, but the last time Qt5 has passed is 4 months
> ago.
> 
> To tackle this we agreed that we can start inserting new platforms submodule
> by submodule, but right after that we froze Coin setup so that we don't
> break 5.7.x by accident. And by having several branches, with alphas,
> betas, release candidates and releases themselves we have a lot of these
> freezes, which means that the time window, where we can put in any new
> platform, is very short. And if the submodule in dev don't happen to have
> everything merged from earlier branches and finally work, an insertion
> won't happen.
> 
> This is why we've not been successful in bringing openSUSE 42.1, Ubuntu
> 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for
> months.
> 
> So back to this day. Currently we can't put anything new in, since Coin
> setup is frozen. We have holidays coming up and we have a skeleton crew
> working the entire summer. Right as we get back to work, we have 5.8 branch
> coming up and feature freeze right after that. When did you expect us to
> push in these new platforms? According to process, we shouldn't put them
> into 5.8 after FF. If we bend this rule (as we usually do), we might get
> them in there as people focus on fixing issues there, or the same thing
> happens as happened with 5.7: the new platforms simply never passed
> autotests so that they could be brought in (we actually did try to get them
> into 5.7 early on, but not lately due to release being too close).
> 
> Ok...perhaps I should propose something. Let's postpone branching 5.8. As
> much as I like the motto of Blizzard Entertainment "done when it's done" ,
> I've found that people like time schedules as well. Alas, I have to suggest
> that we postpone it as much as possible. I think that we can fix the things
> we want to fix in 5.8 in dev branch as well. When we get a more mature dev
> branch that actually works, we can generate the alpha package for 5.8 much
> faster after the branch, as 5.8 already worked right of the bat (because
> dev worked). Also, we'll get a working dev branch as well simultaneously.
> 
> Also, we've noticed that often when people fix problems found in autotests,
> being it a bug in the autotest itself or as it actually more often is, a
> problem in Qt sources themselves, people push the fix to the most mature
> branch available. In this case, when we report that we can't get openSUSE
> 42.1 in, because this and that fails, the fix is pushed into 5.6 as it
> already appears there but haven't been found or studied before. Then we
> have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7 -> dev
> merge. With all the general flakiness in the system, that usually takes a
> fortnight at least.
> 
> So by fixing dev, we can skip doing merges from 5.8 -> dev when we
> eventually find the problems for these new platforms.
> 
> With regards,
> -Tony
> 
> PS: The list with new platforms actually increases yet with OS X...ehm macOS
> Sierra (10.12) beta coming up, tvOS etc...

Hi,
	Ok, the process here is suboptimal, let' me extract certain aspects that 
can be handled separately.

 	Qt5 dev is in disastrous state, nobody managed to pass CI from February. 
Having  Qt5 working is crucial because otherwise, how can we distinguish 
between regressions in a new platform and just standard regressions. As you 
wrote Qt5 dev was not prioritized, because of two concurrent releases. That 
has to change, because state of Qt5 dev directly affects a next release. We 
have to accept the fact that we are doing 3-4 releases in parallel: LTS, 
current (potentially could be two of them) and next. Down-prioritizing one is 
just moving problems in time, which doesn't work with time based releases.

 	We were not updating Coin in any way for last 2 weeks. That is an 
exceptional situation. I strongly believe that in future it will not be 
requested and we will limit such freeze just to test configurations not the 
whole system. 

	New platforms are features, they affect releases in exactly the same way as 
code. So feature freeze should apply to them too and it is great that it was 
enforced. Now, porting to new platform also should be done as a feature 
development. No need to wait for branching.

	Technically waiting for merges is not necessary. Coin is able to test 
arbitrary refs from gerrit, I encourage you to not wait for the system, but 
just make bunch of changes and tests the expected combination, before it gets 
merged from stable branches. You can also request a feature branch for testing 
if you want to work that way. In the same time I agree, the merge cycle is too 
slow, it is just annoying. In my opinion the system should automatically 
create merge patches after each successful integration and warn if it was not 
possible because of conflicts. It seems also that I'm extremist in that area, 
but one merge per day seems to be a reasonable compromise. Sometimes it also 
makes sense to start porting to a new platform from LTS branch. Then you do 
not need to wait for merges at all and most of fixes goes to LTS anyway. 

	Last, but probably the most important thing. Every time someone asks for a 
new platform, the request has to come together with resources. New platforms 
are not coming for free. I'm sure that Tony is willing to help as much as 
possible, but porting should be a team effort and expecting him to solve all 
tests problems is a bit unfair. So please coordinate such tasks :-)

Cheers,
 Jędrek