On Mon, 2013-01-07 at 07:40 +0100, Didier Roche wrote: > > I second as well on the speed issue, please again, check within your > team with the responsible of those tools to see what they can do so > that the merge answer is way faster. I know that Jibel started to have > a look as well and it seems the machines on which they are merging are > swapping a lot, he will adjust in the coming days the infra to help > your team.
Perhaps speed is the wrong term to be using here. Faster build times aren't the problem, the problem is feedback loops and communication patterns. I'm quite convinced every developer is committed to getting things landed to a quality trunk, but that's not the only place that problems can happen. I think I'm going to have to switch to a quick diagram :-) http://ubuntuone.com/1bTq20mlpAvPwwjYLjrv7x The first part of that I see as the developers responsibility. There's a feedback loop that they get directly notified of and get e-mailed as part of the merge process. The area outside of the dotted box I think the feedback loop is through LP bugs. So if anything "after trunk" there breaks, a bug should be filled and prioritized appropriately. But, to be clear, that shouldn't be a "revert from trunk" action, it should be another merge request to fix the problem. What ever that merge request may contain. Partially this is a matter of language, if caught further down the line it is "we found a bug" not a "you broke the build." Ted
signature.asc
Description: This is a digitally signed message part
-- Mailing list: https://launchpad.net/~unity-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~unity-dev More help : https://help.launchpad.net/ListHelp
