May 17th, 2018
- Review Process for Commits
- How many approves are required
- Who is going to commit ?
- How is allowed to make the *last call*
RFC: my policy has been that if someone accepts one of my patches and doesn't immediately merge, I ping and ask if they are planning to it's the responsibility of the patch author to ensure that their patch is merged but the person who reviews the patch should have the first say in merging since the most likely workflow will be review+test -> accept+merge since a reviewer should pull the changes down from arc and verify that they work until we have CI integrated enough that this is not a requiremen -zmike
- 1.21 Release (Including Dates, Freezes, Flat Theme, Interface Preview, Etc...
- Matrix Server Hosting - jaquilna?
- Help for Stefan - Raster?
- Progress on infrastructure ideas for things like Jenkins and other CI?
For smaller patches: One reviewer is enough For bigger patches (accross widgets/subsystems): more than one reviewer
1.2 & 1.3
The one that clicks accept has the responsibility of the patch submission. - code review on phab - pull patch to local tree - test builds, etc - click approve in phab - push patch to git and let phab close (unless communicated differently from the author)
freeze in week 21 exceptions for feature branches or revisions can be added
We wait with any new matrix/chat software etc. on our infra until our infra is cleaned up and settled.
Raster takes over "people poking" in the second half of june First half of june should be bug fixing.
Status update about the CI will be sent to the ML irc notifications will be enabled
- document review flow and how arc tooling should be used (Nobody yet)
- Trigger jenkins jobs for Coverity analysis (Stefan)
- enable irc notifications for travis and mail the list about it (Stefan)