Alex, +1
From the jenkins side we could make more jobs with parameters so anyone can kick-off a test run on his/her branch. I don't know if that would work for the BVT tests though. This only thing i'm a bit afraid of is the technical side of reverting a merge. It's one of those this that you need to be careful with in git. Cheers, Hugo On Jun 28, 2013, at 5:18 PM, Alex Huang <alex.hu...@citrix.com> wrote: > After Dave's complain in the vmsync [MERGE] thread about BVT in horrible > shape on master, I went around to figure out what exactly happened. The best > I can figure is that after a certain merge (I will leave out which merge as > that's not important), BVT no longer runs automatically. It was promised to > be fixed and there are people who are actively fixing it but it's been in > this way for about two weeks. People running BVTs are working around the > problem but it's not automated anymore and so it's no longer running on > master. I understand people are nice and tried to be accommodating to other > people by working around the problem but sometimes we just have to be an > arse. So let me be that arse... > > New Rule.... > If BVT or automated regression tests break on master or any release branch, > we revert all commits that broke it. It doesn't matter if they promise to > fix it within the next hour. If it's broken, the release manager will revert > the commits and developers must resubmit. It sounds mean but it's the only > way this problem can be fixed. > > To avoid having a bunch of reverts and resubmits, the developers should be > able to request that BVT run on their branch and don't merge until BVT on > their branch is at 100%. We will work on figuring out how to do that. > > Comments? > > --Alex
