658692 - Make adjustments to the priority setting for project branches

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P1)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

http://hg.mozilla.org/build/buildbot-configs/file/6fa2a8b0d677/mozilla/master_common.py#l20

Looks like project branches default to 2 and even though mozilla-central is a 1, when there's a backlog they are all clumped up.  Revisit this prioritizing, set the disposables lower (and Tracemonkey?)

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Basically, what I think we want is

1. release builds
2. mozilla-beta
3. mozilla-central/mozilla-aurora
4. project branches
5. try

It's possible that aurora should be kicked up to beta. (we're currently doing double-pushes to aurora and beta, but that will hopefully go away in a matter of days, so not something I think we should optimize for)

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Adds aurora/beta and disposable branches to priority list

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think we really want the project branches to have higher priority than try, otherwise we are going to make it a lot harder for the people working on those project branches to get any test feedback.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to comment #3)
> I think we really want the project branches to have higher priority than
> try, otherwise we are going to make it a lot harder for the people working
> on those project branches to get any test feedback.

There are still many project branches that have a higher priority than try, but the disposable ones where half are not even being used seem like good candidates to me for lower priority. If you are working on a project branch then you are doing work for a more significant amount of time than someone who really needs try results to be able to land on trunk so I think the priority on this makes sense for that reason. Rentable project branches give you lots of room to work out your kinks before landing a lump of code on trunk and that merge can be done on a higher priority branch (like mozilla-incoming?) before pushing to trunk.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I can't speak for other branches, but ceder is currently being used in much the same fashion as tracemonkey. I.e. changes are being landed there first by people that work on similar areas of the code, and then pushed to mozilla-central. This in an effort to keep traffic on m-c down.

I suspect we could move that work to some other project branch which have a higher priority though, if one is available?

Comment 6

[Boris Zbarsky [:bzbarsky]]

cedar _is_ mozilla-incoming at the moment....

Comment 7

[Mounir Lamouri (:mounir)]

Cedar is used to reduce tree watching and tree burning on mozilla-central. Only patches ready to be pushed on mozilla-central can be pushed on cedar. This is very close to the "mozilla-random" idea from Mike Connor.

I think cedar's priority should be higher than try priority otherwise devs might loose interest in pushing in cedar. I'm ok with creating another repo (like mozilla-random or whatever the final name was) as long as we have a repo with a good priority to push patches that have to go to mozilla-central.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

mozilla-inbound is in the works: https://bugzilla.mozilla.org/show_bug.cgi?id=659638 and when that lands it will have a default priority of 2.  This patch is just up for review, not landed. Landing it can wait until mozilla-inbound is up and running if that is deemed necessary.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 536592 [details] [diff] [review]
Adds aurora/beta and disposable branches to priority list

http://hg.mozilla.org/build/buildbot-configs/rev/7c00ac95c87b

landed on default, and the mozilla-inbound branch should be created/landed around the same time for minimal time when cedar is low-priority before mozilla-inbound becomes the go-to branch for integration patches.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Er... how minimal is "minimal"?  Can we please have a hard number (as well as hard dates on when exactly cedar becomes low-priority and when mozilla-incoming goes live, so we can avoid landing on cedar in the interim)?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Or in other words, what the heck happened to "landing it can wait until mozilla-inbound is up and running"?

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

landing it on default != production, this won't be live until the next reconfig which is typically on Tuesdays.  When I land the mozilla-inbound branch configs today they too will be in the queue for tomorrow's reconfig so at the same time that cedar is lower priority, mozilla-inbound will be active and ready for traffic.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  Great!  So we should just stop using cedar and start using mozilla-inbound after the reconfig tomorrow, right?

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to comment #13)
> Ah, ok.  Great!  So we should just stop using cedar and start using
> mozilla-inbound after the reconfig tomorrow, right?

with the disclaimer that the first round of builds always fails because of leak logs not being present, yes.

Comment 15

[Boris Zbarsky [:bzbarsky]]

So... did that reconfig yesterday happen?  Because mozilla-inbound is not open for changes yet, but as far as I can tell, cedar's priority already got bumped down.

Comment 16

[Nick Thomas [:nthomas] (UTC+12)]

philikon pushed to mozilla-inbound today.

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

mozilla-inbound is up and running, please use that instead of cedar now. resolving this bug now.