QtCS2017 Releasing
Jump to navigation
Jump to search
Slides
To be added
Discussion
Too much changes
- Rolling back creator nearly impossible
- Patch releases faster and more often
- they fix problems customers are seeing
late changes
- blocker found too late
- Let's drop it as the next patch release comes in two weeks
- Case by case, sometimes they really are blockers
- Just mention it in the release note, that this and that just doesn't work. Better than not releasing.
Change logs
- Gerrit update is blocking Ossys "automated" thingie
- They still need manual editorial work
- At least mention all fixed bugs by simply grepping all "QTBUG-xxxxx" and is it close etc.
- Jira isn't a reliable tool to know if something has been fixed. It has been previously decided that manually created change logs are better.
- Manually prod maintainers doesn't work currently
- "Task-number: QTBUG-xxxxx" in footer is used for all purposes
- proposal to use smt like "fixes: QTBUG-xxxxx". "Task-number: QTBUG-xxxxx" is left for references to a Jira ticket.
- Test cases should be created whenever anyone fixes a bug. That's a policy already existing.
Manual work: package configurations.
- Things are being automated so that they are at least semi automatic.
Agreed actions
- Let's proceed with automatic merge and automatic +2 for qt5 -> tqtc-qt5.git.
- Submodule commits could trigger and automated submodule update for the super module. But it shouldn't be automerged to the next branch (say 5.9 -> 5.10)
- submodule updates could be run more often. As often as we can.
- Manual restarts of qt5 don't make sense. Let's proceed with automating restage.
- Creator to be tested with Coin and external triggerings, but that's proably for tomorrows CI session