1079937 - Kill the mozilla-b2g28_v1_3t branch in automation

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

We're currently bumping up against the limit of the number of different jobs our Linux test slaves can run. This is hindering efforts like bug 1078507 where we're hitting frequent failures *now* due to not being able to spread the tests over enough chunks. While going through what jobs we can kill to give us some breathing room, b2g28 v1.3t came up as a good candidate.

There have been a few comments made to the effect that 1.3t is EOL on our end of things at this point (as a recent example, we declined to take the NSS chemspill on it). Bhavana, can you please "officially" bless this so we can add it to the list of things to do on Monday? :)

Comment 1

[Ryan VanderMeulen [:RyanVM]]

I spoke with Bhavana in person about this today. She's OK with us turning off builds/tests on v1.3t provided we do so in a way that leaves us the ability to turn them back on if circumstances were to dictate it for some reason or another.

It should be doable to do that without ripping out all the code, right? And that should still accomplish the goal of reducing the number of builders IIUC.

Comment 2

[bhavana bajaj [:bajaj]]

Agree with Ryanvm here, keeping in mind the partner releases ahead related to https://bugzilla.mozilla.org/show_bug.cgi?id=1064636, did not want to kill this branch entirely until the next 2-3 weeks to make sure we do not have any urgent landing done that may be needed. Although, I am fine to turn-off builds/tests until really necessary.

Comment 3

[[e-mail] (:bhearsum)]

If we're looking to do this to make room for other builders, and we need to maintain the ability to turn them back on - it sounds like we shouldn't do this. Otherwise we'll quickly replace the builders with other ones, and won't be able to turn these back on if necessary...

Comment 4

[bhavana bajaj [:bajaj]]

Hey relenger's,

I've discussed with TAM's maintaining the 1.3T product and at this point I think we can kill this branch in terms of automation support given there are no new landings. I just want to be sure that the repo's will still exists for partners to pick-up code in case we see more releases from the tip of this branch.

Ni Hal/rail to get going on the above.

Comment 5

[Rail Aliiev [:rail]]

Yay! If no ones picks it this week, I can slash and burn it early next week.

Comment 6

[Rail Aliiev [:rail]]

This also means update.boot2gecko.org dies

Comment 7

[Hal Wine [:hwine] use NI!]

(In reply to bhavana bajaj [:bajaj] from comment #4)
> I just want to be sure that the repo's will still exists
> for partners to pick-up code in case we see more releases from the tip of
> this branch.

We'll leave the associated gecko repository in place (where any new commits would land):
  http://hg.mozilla.org/releases/mozilla-b2g28_v1_3t

We'll also leave the mirroring in place that puts those changes on the v1.3t branch in:
  https://git.mozilla.org/releases/gecko.git
  https://github.com/mozilla/gecko-dev
  
With the build configs gone, I see no need to maintain the gaia mirror. It can be regenerated within several hours.
  http://hg.mozilla.org/integration/gaia-1_3t/

n/i: rail do you agree with removal of integration repository?

Comment 8

[Rail Aliiev [:rail]]

comment 7 sounds good to me

Comment 9

[Hal Wine [:hwine] use NI!]

Okay - after all builds are disabled, assign the bug to me to take care of the repository stuff.

Comment 10

[Rail Aliiev [:rail]]

Attachment: kill_v1_3t-buildbotcustom.diff

Comment 11

[Rail Aliiev [:rail]]

Attachment: kill_v1_3t-buildbot-configs.diff

Comment 12

[Rail Aliiev [:rail]]

Attachment: kill_v1_3t-tools.diff

Comment 13

[Rail Aliiev [:rail]]

Attachment: kill_v1_3t-mozharness.diff

not touching vcssync

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Removed from TBPL. I've pinged in #treeherder about getting it done for that as well.
https://hg.mozilla.org/webtools/tbpl/rev/a97ed7f7ece3

Comment 15

[Rail Aliiev [:rail]]

Comment on attachment 8539321 [details] [diff] [review]
kill_v1_3t-buildbotcustom.diff

https://hg.mozilla.org/build/buildbotcustom/rev/a748312e9aa5

Comment 16

[Rail Aliiev [:rail]]

Comment on attachment 8539325 [details] [diff] [review]
kill_v1_3t-buildbot-configs.diff

https://hg.mozilla.org/build/buildbot-configs/rev/390650d81a26

Comment 17

[Rail Aliiev [:rail]]

Comment on attachment 8539327 [details] [diff] [review]
kill_v1_3t-tools.diff

https://hg.mozilla.org/build/tools/rev/2399669ab652

Comment 18

[Rail Aliiev [:rail]]

Comment on attachment 8539328 [details] [diff] [review]
kill_v1_3t-mozharness.diff

https://hg.mozilla.org/build/mozharness/rev/d6b5b9268f62

Comment 19

[Rail Aliiev [:rail]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #14)
> Removed from TBPL. I've pinged in #treeherder about getting it done for that
> as well.
> https://hg.mozilla.org/webtools/tbpl/rev/a97ed7f7ece3

Thanks!

Comment 20

[Ed Morley [:emorley]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #14)
> Removed from TBPL. I've pinged in #treeherder about getting it done for that
> as well.

File a bug and assign it to me and I'll take care of it :-)

(Whilst realtime IRC conversations are valuable for many things, I think lower priority items like this that can be communicated asynchronously should use Bugzilla as the primary means of communication - if only because the treeherder devs are so keen to attempt "to please all the people all the time", that they'll end up diverting away from whatever they are working on to discuss/fix an issue that could have waited a day, incurring the context switch cost for something that could have just been filed as a bug)

Comment 21

[Rail Aliiev [:rail]]

assigning to hwine per comment 9

Comment 22

[Rail Aliiev [:rail]]

FTR, it's in production