Closed Bug 840997 Opened 11 years ago Closed 11 years ago

Adjust branch priorities so that random unlisted trees aren't more important than mozilla-central

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: sheriffing-P1)

By dropping the priority of *-central and *-aurora down to 3, bug 803682 actually made mozilla-central less important than, say, ionmonkey. That ain't right.
Keywords: sheriffing-P1
That bug has no reference to why I did that which makes me think it was just an oversight.

mozilla-central used to be priority 1 and the default was 2
mozilla-central is now priority 3 (because we wanted release > esr > beta > aurora/central), which makes me want to change the default to priority 4. This would put unlisted things in the same class as try -- meaning lower priority than release/esr/beta/aurora/central, but higher priority than twigs. mozilla-inbound, ionmonkey, etc. would all fall into that.
Having mozilla-inbound be the same priority as try would be... problematic. We already typically have 7-8 hour end-to-end times on inbound, which is really *the* tree; having it be 24-36 hours like try gets to be, and having it be possible for someone who needs to trigger 50 runs of something on try to catch an intermittent to take every single slave away from inbound isn't going to work.

Unless we want to put try and twigs on the same level (which I have wanted from the start), we might need another digit, so try can be 5 and twigs can be 6.
(In reply to Phil Ringnalda (:philor) from comment #2)
> Having mozilla-inbound be the same priority as try would be... problematic.
> We already typically have 7-8 hour end-to-end times on inbound, which is
> really *the* tree; having it be 24-36 hours like try gets to be, and having
> it be possible for someone who needs to trigger 50 runs of something on try
> to catch an intermittent to take every single slave away from inbound isn't
> going to work.
> 
> Unless we want to put try and twigs on the same level (which I have wanted
> from the start), we might need another digit, so try can be 5 and twigs can
> be 6.

What if we put mozilla-inbound at 3? In some ways, it *is* the new mozilla-central....
16:12 < philor> hmm, I wonder whether http://hg.mozilla.org/build/buildbot-configs/rev/2ca0e7f7e68d is when branch_priority broke
16:13 <@bhearsum> hm
16:13 <@bhearsum> that seems...likely
Flags: needinfo?(catlee)
Though really that's for bug 659222, on which this (now) depends, because it really doesn't matter what we set as the branch priority while branch priority isn't having much of any effect.
Depends on: 659222
It's possible, but I can't spot a problem in that patch. How would the branch priorities be different after that patch?
Flags: needinfo?(catlee)
Actually, this both depends on and blocks bug 659222, since if that fixes things so that branch prioritization strictly works, we'll have twigs only running linux32/b2g on Saturday after we drain the week's backlog from try, and inbound completely choking out aurora and central.

Probably what we want is to move unlisted to 4, and move try and try-comm-central to 5 along with the twigs. I'm considerably less sure whether we want to move inbound from unlisted to 3, since inbound casts a pretty big shadow during the day, and that might make it impossible for any other project branches (and, of course, try and twigs, which are going to get hosed anyway) to run any tests at all before 10pm.
Did we do this right in bug 659222?
Yep.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.