cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [DISCUSS] If BVT breaks, revert the commits...
Date Sat, 29 Jun 2013 16:31:31 GMT
On Sat, Jun 29, 2013 at 12:45 AM, Prasanna Santhanam <tsp@apache.org> wrote:
> On Sat, Jun 29, 2013 at 12:18:17AM +0000, Alex Huang 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?
>>
> Quick questions:
>
> 1. How do we test contributor code (from github/reviewboard) because
> we have no staging area/branch?
>

Take a look at the pre-commit testing that hadoop does, that might be
usable for us. Olamy did a blog post about it recently.


> 2. Squashing into a big patch is not a good idea. I prefer that we
> keep the clean commit history rebased atop master in the topic branch
> and run the bvt on it. This can be requested and there is ability in
> the test jobs to switch branches already.
>
> Hit Build (test-matrix job) -> choose <topic-branch> on the form.
>
> 3. BVTs have long runtime (3 HVs - 4hrs). For large merges it makes
> sense since we're going to be waiting 72h for the review/merge
> request. But rest of the time I propose we run it against master only.
> Is this the same as you're proposing?
>
> 4. Who will fix the tests which are broken?
>

Well if we treat master as frozen until the tests are fixed, then I'd
suppose that folks wanting to get code in will be incentivized to at
least help fix them so that master can start getting code again :)

--David

Mime
View raw message