Release Management/Keep Builds Green
Firstly, there are 2 clear goals with all this:
- Make development branch (2.3x, 2.40, pi) healthier and other developer's life easier.
- Learn from our mistakes, learn to be correct and improve the tools if they can help us make less mistakes.
With this considered, there are 3 kind of build failures that are considered basic or *unacceptable*:
- Full builds (install.source) fail in Oracle or in PostgreSQL.
- incremental builds (smartbuild, update.database) fail in Oracle or in PostgreSQL.
- Junit tests fail.
- The database is not consistent.
If a developer breaks a build twice in the last 30 days, push access will be removed for 2 weeks. And he'll ask a friend to push for him. This friend will be responsible of the sanity of the entire push.
There is one salvation clause for the developer, 24h to react and make the build stable again. Note that making the build stable again doesn't necessarily mean fixing the bad changeset. Feel free to backout your faulty changeset. Whatever to make the build stable in less than 24h. If the issue is solved in less than 24h no actions are taken.
Finally, the developer who fixes a broken build should reply to the e-mail sent by Hudson to this mailing list, explaining why the build failed and how it was fixed. This way we'll be able to see the reason behind it and figure out a way to make it easier for everyone, if it applies (like with synchronize terminology).
Any comments are welcome !!!