Le 18/06/2015 15:32, Jon Robson a écrit :
I also would recommend 2. We had this issue recently with some tweaks Kaldari made to our main menu.
Given that lightning deploys happen we really should make master stable always.
If Jenkins is barfing on this there may be other extensions out there which will also barf. It also makes rolling back a lot easier if things do go wrong.
It takes a bit more time to do and seems silly but really is the right way to do this sort of thing. Smaller commits generally are better and I wish we broke down a lot of our patch sets more (due to code review being slow I think sometimes we tend to bundle too many things into any given patch).
Hello,
+2 on having master branches stable together. Eventually down the road we would have a set of (repo, commit sha1) that are known to work together, we could send that to a git repo and deploy it continuously.
OpenStack does exactly that though it is not used for releasing. But that gives you a stable set of repo at the tip of their branches.
https://github.com/openstack/openstack#openstack-tracking-repo
Every single commit here had all tests passing.