Closed Bug 1431363 Opened 6 years ago Closed 6 years ago

Tracking bug for 2018-03-13 migration work

Categories

(Release Engineering :: Release Requests, defect)

Product:
Release Engineering
Component:
Release Requests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox59+ fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox59 + fixed

People

(Reporter: mtabara, Assigned: mtabara)

References

Details

Attachments

(2 files, 1 obsolete file)

bump gecko version in m-b and m-r
316 bytes, patch
jlund
: review+
mtabara
: checked-in+
Details | Diff | Splinter Review
mozharness_migrations_central_gecko_bump2.patch
5.16 KB, patch
mtabara
: review+
rail
: feedback+
Details | Diff | Splinter Review 
+++ This bug was initially created as a clone of Bug #1412962 +++

Filing this in advance for the 59.0 release.
See Also: → 1441631
Mihai and I will both be doing this.
Assignee: nobody → bhearsum
@mtabara, @bhearsum - this patch allows us to:

1. run beta_to_central.py without worrying about bumping central.
2. run a new configuration, bump_central.py, that allows us to tag and bump mozilla-central only (no merge)

Since 57 we have been doing both of these via a hack:

https://bugzilla.mozilla.org/show_bug.cgi?id=1407602#c14
https://bugzilla.mozilla.org/show_bug.cgi?id=1412962#c2

Associated doc changes: https://github.com/mozilla-releng/releasewarrior-2.0/pull/74
Attachment #8954678 - Flags: review?(mtabara)
@mtabara - if you are not comfortable reviewing, rail is pretty familiar with this script too.

Also, you will see I have a TODO at one of the tags. I need to sanity check with relman/ryanvm about what expectations we have for tagging. Looking at https://hg.mozilla.org/mozilla-central/tags we sometimes have FIREFOX_BETA_%(d)_BASE and sometimes we do not. We also have FIREFOX_NIGHTLY_%(d)_END but never the _BASE equivalent.
Thanks for this @jlund. Am slightly confused as to why we have "beta to central" name in the script but I guess it's just a misspelled naming convention. Will glance at patch and potentially add :bhearsum or :rail too. 

Thanks!
Depends on: 1441782
(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #5)
> Thanks for this @jlund. Am slightly confused as to why we have "beta to
> central" name in the script but I guess it's just a misspelled naming
> convention.


(In reply to Jordan Lund (:jlund) from comment #3)
> Created attachment 8954678 [details] [diff] [review]
> mozharness_migrations_central_gecko_bump.patch

> 1. run beta_to_central.py without worrying about bumping central.

sorry, I mean central_to_beta.py
As per the remote instance,

Steps that have been done:

* started it back up
* cleared unneeded disk space
* setup my ssh pub key and configured hg to use it
* done a no-op trial run of beta_to_central, central_to_beta.py, bump_esr.py so that we have:
  * the repos checked out already all in the same dir (should be fine)
  * the migrations this cycle all worked fine so we shouldn't merge conflicts
* sanity checked bump_central.py via comment 3 works as expected.

It be good if releaseduty tried to copy this by following docs here: https://github.com/mozilla-releng/releasewarrior-2.0/pull/74/commits/310a786fa5062b803ca2225f56399d3b738e0173
Comment on attachment 8954678 [details] [diff] [review]
mozharness_migrations_central_gecko_bump.patch

Review of attachment 8954678 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me but I'd feel much comfortable if rail glanced at this too.

::: testing/mozharness/scripts/merge_day/gecko_migration.py
@@ +351,5 @@
> +            bump_major=True,
> +            use_config_suffix=False
> +        )
> +        # touch clobber files
> +        self.touch_clobber_file(dirs['abs_to_dir'])

`abs_from_dir` instead? not sure though, just looking at what the value was before.
Attachment #8954678 - Flags: review?(mtabara)
Attachment #8954678 - Flags: review+
Attachment #8954678 - Flags: feedback?
Attachment #8954678 - Flags: feedback? → feedback?(rail)
(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #8)
> Comment on attachment 8954678 [details] [diff] [review]
> mozharness_migrations_central_gecko_bump.patch
> 
> Review of attachment 8954678 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good to me but I'd feel much comfortable if rail glanced at this too.
> 
> ::: testing/mozharness/scripts/merge_day/gecko_migration.py
> @@ +351,5 @@
> > +            bump_major=True,
> > +            use_config_suffix=False
> > +        )
> > +        # touch clobber files
> > +        self.touch_clobber_file(dirs['abs_to_dir'])
> 
> `abs_from_dir` instead? not sure though, just looking at what the value was
> before.

disclaimer: non expert in this script.

Yeah, you would think so! The reason I changed this is because in the bump_esr.py config, I define the "abs_to_dir" as: "to_repo_url": "https://hg.mozilla.org/mozilla-central", rather than as the "abs_from_dir" like it is in central_to_beta.py. context, "abs_to_dir" is defined via "to_repo_url"[1]. Reason to use "to" vs "from" is because it makes committing and pushing easier[3]

[1] https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/merge_day/gecko_migration.py#137
[2] https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/merge_day/gecko_migration.py#172
[3] https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/merge_day/gecko_migration.py#182
(In reply to Jordan Lund (:jlund) from comment #9)

> Yeah, you would think so! The reason I changed this is because in the
> bump_esr.py config, I define the "abs_to_dir" as: "to_repo_url":
>

s/bump_esr.py/bump_central.py.
reminder about using the remote instance[1]

until https://bugzilla.mozilla.org/attachment.cgi?id=8954678&action=edit lands, we need to use "mozharness-custom" dir for mozharness runs as that contains the patch. So from `~/merge_day_59.0` use `mozharness-custom` instead of `mozharness-central` until this patch lands on central and we update mozharness-central on the merge instance.

e.g. for all gecko_migration.py calls use the following paths:

```
ubuntu@ip-10-99-215-157:~/merge_day_59.0$ python mozharness-custom/scripts/merge_day/gecko_migration.py -c merge_day/beta_to_release.py
```


[1] https://github.com/mozilla-releng/releasewarrior-2.0/blob/master/docs/mergeduty/merge-and-staging-instance.md
(In reply to Jordan Lund (:jlund) from comment #4)
> Also, you will see I have a TODO at one of the tags. I need to sanity check
> with relman/ryanvm about what expectations we have for tagging. Looking at
> https://hg.mozilla.org/mozilla-central/tags we sometimes have
> FIREFOX_BETA_%(d)_BASE and sometimes we do not. We also have
> FIREFOX_NIGHTLY_%(d)_END but never the _BASE equivalent.

@ryanvm - would you have a few min to chat about tagging throughout the merges. Also, want to touch base about how to handle m-b branching for Fennec and subsequent m-c->m-b merges prior to m-c version bump. We will need assistance for this again but we have bugs on file to automate it.
Flags: needinfo?(ryanvm)
Assignee: bhearsum → mtabara

        Attachment #8954965 -
        Flags: review?(jlund)

    
    

    
  
(In reply to Jordan Lund (:jlund) from comment #4)

> Also, you will see I have a TODO at one of the tags. I need to sanity check
> with relman/ryanvm about what expectations we have for tagging. Looking at
> https://hg.mozilla.org/mozilla-central/tags we sometimes have
> FIREFOX_BETA_%(d)_BASE and sometimes we do not. We also have
> FIREFOX_NIGHTLY_%(d)_END but never the _BASE equivalent.

So I have some concrete info regarding m-b relbranch, subsequent m-c->m-b uplifts after Merge day tomorrow, and expected tagging.

tldr:

* m-b relbranch: not actually needed until Monday, March 5th before Fennec 59.0b15 gtb. ryanvm and aryx will create the branch on Friday, March 2nd.
   * desktop 59.0b14 will gtb tomorrow, March 1st before we migrate m-c->m-b so relbranch is not needed before that. Version bump task will likely fail and we will need to manually bump on the 59 relbranch when it is created since we are migrating during b14 automation[1].
   * fridays devedition 60.0b1 doesn't need the relbranch

* subsequent m-c->m-b uplifts: As needed, ryanvm and aryx will handle whatever patches need to merge from m-c to m-b default and respective relbranch after Merge day and before we bump m-c for real

* expected tags:
   * after merge day tomorrow
      * m-c should have: FIREFOX_BETA_60_BASE (this means we can leave this tag as is[2])
      * m-b should have: FIREFOX_BETA_60_BASE (since we tag m-c before merging to m-b), FIREFOX_BETA_59_END
   * after m-c version bump on ~Monday, March 12th
      * m-c should have: FIREFOX_NIGHTLY_60_END (this is handled by my gecko_migration.py bump_central.py patch in this bug)


more context:
```
jlund [2:38 PM]
last few cycles you created a relbranch off beta and handled post official m-c->m-b uplifts until we actually version bumped m-c


ryanvm [2:38 PM]
yeah, but that can wait until Friday
anyway, Aryx will probably be handling more of that this cycle

jlund [2:42 PM]
okay, I’m trying to remember what we branch. last 59 beta rev prior to migration yeah? So b14 gtb will happen before we merge? Then Friday we devedition-b1 gtb? And next mon we do fennec b15 gtb?
I guess that means we don’t have to do it until we fennec b15 gtb?

ryanvm [2:42 PM]
yeah, we should gtb b14 before merging m-b to m-r
and yeah, fennec b15 gtb on Monday

jlund [2:42 PM]
okay

ryanvm [2:43 PM]
and RC1 gtb on Monday

jlund [2:43 PM]
tries to remember what that means if we version bump m-b during b14 automation and merge in between

ryanvm [2:44 PM]
i believe it just fails to bump
and we have to manually bump to b15 on the relbranch

jlund [2:48 PM]
yeah. sounds right
okay! one more question
when we migrate m-c->m-b tomorrow, what tags do you expect on both m-c and m-b, if any?

ryanvm [2:49 PM]
FIREFOX_BETA_60_BASE on m-c (though it looks like 59 never got tagged....)

jlund [2:50 PM]
yeah, which is motivation for question

ryanvm [2:50 PM]
and FIREFOX_BETA_59_END on m-b
I see we did a FIREFOX_BETA_59_BASE tag on m-b

jlund [2:51 PM]
and I guess we tag m-c with FIREFOX_BETA_60_BASE before merge so m-b gets that tomorrow too

ryanvm [2:51 PM]
huh, maybe it went to the wrong repo?
yeah, I think we just tagged it on the wrong repo for 59 :slightly_smiling_face:
https://hg.mozilla.org/releases/mozilla-beta/rev/FIREFOX_BETA_59_BASE

jlund [2:52 PM]
yeah, I think we stubbed out the m-c FIREFOX_BETA_59_BASE tag altogether last cycle

ryanvm [2:53 PM]
anyway, yeah, I agree with what you said about 60_BASE
tag on m-c, then uplift to beta

jlund [2:55 PM]
and what about when we bump m-c repo for real 1.5 weeks from now? FIREFOX_NIGHTLY_60_END? Is that useful? There doesn’t seem to be a FIREFOX_NIGHTLY_60_BASE equivalents ever

ryanvm [2:56 PM]
yeah, we added that tag when we started doing this disjointed merging
since in the past, the 59_BASE tag was implicitly the NIGHTLY_END tagging too

jlund [2:56 PM]
right. makes sense

ryanvm [2:56 PM]
I think there's value in both since they're not the same anymore

jlund [2:57 PM]
okay I think that about covers it. Just to be explicit, should I expect you to do the relbranch on beta on Friday? And handle all next week’s uplifts? Or should I reach out to Aryx?

ryanvm [2:58 PM]
it'll probably be Aryx doing it with me assisting as needed
```

[1] we should revisit that version bump issue
[2] https://dxr.mozilla.org/mozilla-central/rev/5297541590781af40ff09e067646f3115960af75/testing/mozharness/scripts/merge_day/gecko_migration.py#480-483

    
    

    
  


  
motivation: https://bugzilla.mozilla.org/show_bug.cgi?id=1431363#c14

just changed some comments to reflect reality

        Attachment #8954678 -
        Attachment is obsolete: true

        Attachment #8954678 -
        Flags: feedback?(rail)

        Attachment #8954973 -
        Flags: review?(mtabara)

        Attachment #8954973 -
        Flags: feedback?(rail)

    
  

        Attachment #8954973 -
        Flags: review?(mtabara) → review+

    
    

    
  
(In reply to Jordan Lund (:jlund) from comment #15)
> Created attachment 8954973 [details] [diff] [review]
> mozharness_migrations_central_gecko_bump2.patch
> 
> motivation: https://bugzilla.mozilla.org/show_bug.cgi?id=1431363#c14
> 
> just changed some comments to reflect reality

fwiw the diff:

--- /Users/jlund/gecko_migration.py     2018-02-28 15:32:35.000000000 -0800
+++ /Users/jlund/gecko_migration_new.py 2018-02-28 15:33:30.000000000 -0800
@@ -340,10 +340,15 @@
         next_mc_version = str(int(curr_mc_version) + 1)
         to_fx_major_version = self.get_version(dirs['abs_to_dir'])[0]
         end_tag = self.config['end_tag'] % {'major_version': to_fx_major_version}
         base_to_rev = self.query_to_revision()

+        # tag m-c again since there are csets between tagging during m-c->m-b merge
+        # e.g.
+        # m-c tag during m-c->m-b migration: FIREFOX_BETA_60_BASE
+        # m-c tag we are doing in this method now: FIREFOX_NIGHTLY_60_END
+        # context: https://bugzilla.mozilla.org/show_bug.cgi?id=1431363#c14
         self.hg_tag(
             dirs['abs_to_dir'], end_tag, user=self.config['hg_user'],
             revision=base_to_rev, force=True,
         )
         self.bump_version(
@@ -492,13 +497,11 @@
         from_fx_major_version = self.get_version(dirs['abs_from_dir'])[0]
         to_fx_major_version = self.get_version(dirs['abs_to_dir'])[0]
         base_from_rev = self.query_from_revision()
         base_to_rev = self.query_to_revision()
         base_tag = self.config['base_tag'] % {'major_version': from_fx_major_version}
-        # TODO - determine if we should tag m-c here (from_dir) with something like
-        # FIREFOX_BETA_%(major_version)s_BASE prior to migrating to m-b
-        self.hg_tag(
+        self.hg_tag(  # tag the base of the from repo
             dirs['abs_from_dir'], base_tag, user=self.config['hg_user'],
             revision=base_from_rev,
         )
         new_from_rev = self.query_from_revision()

    
    

    
  
Pushed by jlund@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/b996cabc7ef5
Tracking bug for 2018-03-13 migration work, a=testing r=mtabara

    
    

    
  
(In reply to Jordan Lund (:jlund) from comment #11)
> reminder about using the remote instance[1]
> 
> until https://bugzilla.mozilla.org/attachment.cgi?id=8954678&action=edit
> lands, we need to use "mozharness-custom" dir for mozharness runs as that
> contains the patch.

This no longer holds true anymore. The cset that lived in mozharness-custom landed on central. See comment 18.

I updated the mozharness-central copy on the remote instance to take central tip and moved mozharness-custom to a backup location.

ignore: /home/ubuntu/merge_day_59.0/backups/mozharness-custom

use: /home/ubuntu/merge_day_59.0/mozharness-central

    
    

    
  
Comment on attachment 8954965 [details] [diff] [review]
bump gecko version in m-b and m-r

Review of attachment 8954965 [details] [diff] [review]:
-----------------------------------------------------------------

::: mozilla/gecko_versions.json
@@ -4,2 @@
>      "mozilla-central": 60,
>      "comm-beta": 59

tom: how should we handle the timing of bumping comm-beta and communicating with tb? Could you also glance at our docs[1] and suggest a way for us to know when to bump it?

[1] https://github.com/mozilla-releng/releasewarrior-2.0/blob/master/docs/mergeduty/howto.md#buildbot-re-config-part-1

        Attachment #8954965 -
        Flags: review?(jlund) → review+

    
    

    
  
(In reply to Jordan Lund (:jlund) from comment #20)
> Comment on attachment 8954965 [details] [diff] [review]
> bump gecko version in m-b and m-r
> 
> Review of attachment 8954965 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: mozilla/gecko_versions.json
> @@ -4,2 @@
> >      "mozilla-central": 60,
> >      "comm-beta": 59
> 
> tom: how should we handle the timing of bumping comm-beta and communicating
> with tb? Could you also glance at our docs[1] and suggest a way for us to
> know when to bump it?
> 
> [1]
> https://github.com/mozilla-releng/releasewarrior-2.0/blob/master/docs/
> mergeduty/howto.md#buildbot-re-config-part-1
Flags: needinfo?(ryanvm) → needinfo?(mozilla)

    
    

    
  
Merged bbconfigs to production + reconfig: https://hg.mozilla.org/build/buildbot-configs/rev/7bb91970e9e1

    
    

    
  
For some reason push to mozilla-release failed. 

11:58:58     INFO - pushing to ssh://hg.mozilla.org/releases/mozilla-release
11:58:58     INFO -  searching for changes
11:58:58     INFO -  remote: adding changesets
11:58:58     INFO -  remote: adding manifests
11:58:58     INFO -  remote: adding file changes
11:58:58     INFO -  remote: added 9352 changesets with 97122 changes to 58670 files
11:58:58     INFO -  remote: recorded push in pushlog
11:58:58     INFO -  remote: replication log not available; cannot close transaction
11:58:58     INFO -  remote: transaction abort!
11:58:58     INFO -  remote: rolling back pushlog
11:58:58     INFO -  remote: rollback completed
11:58:58     INFO -  remote: pretxnclose.vcsreplicator hook failed
11:58:58    ERROR -  abort: push failed on remote
11:58:58    ERROR -  Automation Error: hg not responding
11:58:58    ERROR - Return code: 255
11:58:58    FATAL - Push failed!  If there was a push race, try rerunning
11:58:58    FATAL - the script (--clean-repos --pull --migrate).  The second run will be faster.
11:58:58    FATAL - Running post_fatal callback...

I'm backing[2] out the tag[1] from mozilla-beta and rerun the things.

[1]: https://hg.mozilla.org/releases/mozilla-beta/rev/5a21c2f52c78
[2]: https://hg.mozilla.org/releases/mozilla-beta/rev/8eb7e5c863ed

    
    

    
  
12:21:13 <~mtabara|mergeduty> I'm redoing things to see if it was just a hg infra issue or not
12:22:14 <~mtabara|mergeduty> seems like last time the push to release step indeed took ~15-16 mins
12:22:56 <~mtabara|mergeduty> today failed after 22mins, maybe there's some hg timeout I hit or 59.0 was simply larger to bundle? 
12:23:05 <~mtabara|mergeduty> let's see how this goes the second time
12:23:10 <~mtabara|mergeduty> the rest of the steps seem accurate (commiting, venv creation, etc)

++ to having previous versions logs btw!

    
    

    
  
Partial status update:
* beta to release is now completed
* waiting for confirmation from RelMan to proceed with the rest of merges once we have green tree.

    
    

    
  
Comment on attachment 8954973 [details] [diff] [review]
mozharness_migrations_central_gecko_bump2.patch

Review of attachment 8954973 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM!

        Attachment #8954973 -
        Flags: feedback?(rail) → feedback+

    
    

    
  
For mozilla-central => mozilla-beta:

Mozilla-beat is now as central:
* pushlog is https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?changeset=15334014dc6752581cab545eb7c9f94d725a8bc5
* other commits that ended up in the repo:
TODO
* Tree herder entry is: https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&revision=15334014dc6752581cab545eb7c9f94d725a8bc5

Mozilla-central has been tagged:
* https://hg.mozilla.org/mozilla-central/rev/426ef843d356

    
    

    
  
(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #29)
> For mozilla-central => mozilla-beta:
> 
> Mozilla-beat is now as central:
> * pushlog is
> https://hg.mozilla.org/releases/mozilla-beta/
> pushloghtml?changeset=15334014dc6752581cab545eb7c9f94d725a8bc5
> * other commits that ended up in the repo:
> TODO
> * Tree herder entry is:
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-
> beta&revision=15334014dc6752581cab545eb7c9f94d725a8bc5
> 
> Mozilla-central has been tagged:
> * https://hg.mozilla.org/mozilla-central/rev/426ef843d356

+ these four on mozilla-beta
* https://hg.mozilla.org/releases/mozilla-beta/rev/87fcc2ab5607
* https://hg.mozilla.org/releases/mozilla-beta/rev/23889a541696
* https://hg.mozilla.org/releases/mozilla-beta/rev/fb732e4aebfc
* https://hg.mozilla.org/releases/mozilla-beta/rev/15334014dc67

    
    

    
  
Got some issues while trying to push to esr52. Investigating and asking in #vcs

17:13:41     INFO - [mozharness: 2018-03-01 17:13:41.528433Z] Finished commit-changes step (success)
17:13:41     INFO - [mozharness: 2018-03-01 17:13:41.528629Z] Running push step.
17:13:41     INFO - Running main action method: push
17:13:41  WARNING - Skipping None
17:13:41     INFO - Running command: ['hg', 'push', '-r', '.'] in /home/ubuntu/merge_day_59.0/build/mozilla-esr52
17:13:41     INFO - Copy/paste: hg push -r .
17:13:44     INFO -  pushing to https://hg.mozilla.org/releases/mozilla-esr52
17:13:44     INFO -  searching for changes
17:13:44    ERROR -  abort: authorization failed
17:13:44    ERROR -  Automation Error: hg not responding
17:13:44    ERROR - Return code: 255
17:13:44    FATAL - Push failed!  If there was a push race, try rerunning
17:13:44    FATAL - the script (--clean-repos --pull --migrate).  The second run will be faster.
17:13:44    FATAL - Running post_fatal callback...
17:13:44    FATAL - Exiting -1

    
    

    
  
Pushing to esr52:

* pushlog is https://hg.mozilla.org/releases/mozilla-esr52/rev/7f25d7aaa076b93393f2084d3e6d79339cbe5f96
* Tree herder entry is: https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52&revision=7f25d7aaa076b93393f2084d3e6d79339cbe5f96

Auth issues from comment 31 were because I wasn't pushing via ssh but https.
Tweaking .hg/hgrc within the repo solved the problem.

cat build/mozilla-esr52/.hg/hgrc
[paths]
default = https://hg.mozilla.org/releases/mozilla-esr52
default-push = ssh://hg.mozilla.org/releases/mozilla-esr52

    
    

    
  
Is there anything else needed here? Just double checking since it's on my list of tracked bugs.
Flags: needinfo?(mtabara)

    
    

    
  
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #36)
> Is there anything else needed here? Just double checking since it's on my
> list of tracked bugs.

Yes, on Monday we still need to:
* make sure we do the last merge from central to beta
* tag central and bump version to 61
* update wikipedia
* update bouncer for nightlies
* trigger new nightlies

More about the steps here[1]
[1]: https://github.com/mozilla-releng/releasewarrior-2.0/blob/master/docs/mergeduty/howto.md#bump-and-tag-mozilla-central---1-week-after-merge-day
Flags: needinfo?(mtabara)

    
    

    
  
* triggering new nightlies
* update wiki entries
* replied to RelMan's email

Leftover:
* bouncer stuff that depends on green builds with 61 version

    
    

    
  
Leftover:
* we need to update bouncer aliases for nightly as soon as 61 builds are ready
* approve and land Ship-it nightly version bump (e.g. https://github.com/mozilla-releng/ship-it/pull/214)

    
    

    
  
(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #40)
> Leftover:
> * we need to update bouncer aliases for nightly as soon as 61 builds are
> ready
> * approve and land Ship-it nightly version bump (e.g.
> https://github.com/mozilla-releng/ship-it/pull/214)

Both of them are now done.

(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #41)
> More fixes in the docs here -
> https://github.com/mozilla-releng/releasewarrior-2.0/pull/97

Merged.

Also, clearing :tomprince's NI as we're no longer relying on the gecko_version file. RIP BB!
Nothing left to be done here.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(mozilla)
Resolution: --- → FIXED

    
    

    
  
(In reply to Jordan Lund (:jlund) - PTO until 2018-03-18 from comment #20)
> tom: how should we handle the timing of bumping comm-beta and communicating
> with tb? Could you also glance at our docs[1] and suggest a way for us to
> know when to bump it?
> 
> [1] https://github.com/mozilla-releng/releasewarrior-2.0/blob/master/docs/mergeduty/howto.md#buildbot-re-config-part-1


Sorry for the long delay in replying to this. Due to limited resources, Thunderbird only merge c-c to c-b 
after the final merge of m-c to m-b, so that is probably the right time to make the change. Or, perhaps it can be added as a step of the TB merge (https://wiki.mozilla.org/Thunderbird/Release_Driving/Rapid_Release_Activities/Merge_Repositories) (cc: Patrick).
Flags: needinfo?(clokep)
Flags: needinfo?(clokep)
No longer depends on: 1575613

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: