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.
--
Antoine "hashar" Musso