Bug 1675037 Comment 12 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Hi Chris, thank you for improving our code. Code quality is crucial.

Let me flesh this out for you a bit.

(In reply to Magnus Melin [:mkmelin] from comment #7)
> AH, this is from https://hg.mozilla.org/comm-central/rev/28e58c1b88e1 which was v 71 already.

That's where the patch for bug 1562157 was landed, which probably overlooked this detail per comment 1 and comment 4.
As this "error in code" does not affect the application behaviouris like a regular "defect", we can consider it a mere code refactoring: I have changed the type of this bug from "defect" to "task".

> We use the status + target milestone for trunk, then the flags for tracking uplifts to branches.

Thunderbird release channels:
- `Daily -> Beta -> Release`
Code changes first land on "Trunk" from which Daily release is created, well, *daily*... ;-)
They then ride the train according to the [Rapid Release Calendar](https://wiki.mozilla.org/Release_Management/Calendar) (that's Firefox, but TB is roughly following that).

You can see from the first row of **Past Branch Dates** table that as of today, for Thunderbird:
- Trunk/Daily is 84 (FF Central, for TB: comm-central)
- Beta is 83
- Release is 82. Thunderbird uses the ESR cycle so we stick to 78 and push point releases, currently on 78.4.3 (Firefox 78.4).

So your patch here was landed on Trunk and automatically picked up by Daily, hence Target Milestone: 84 Branch (first landing).
Then there are tracking flags *on the bug* like tracking?thunderbird83 to request tracking, and determine "affected" or "wontfix".
For important fixes, uplifts can be requested (after landing) on the patch itself (attachment 9186671 [details] [diff] [review]), via `Details > Edit details. > approval-comm-beta? | approval-comm-release? (that's probably mailnews core) | approval-comm-esr78?`.

> But this additional parameter is just ignored, right? So it's just a matter of code cleanness.

This bug was set tracking?thunderbird83: *wontfix* so release drivers have decided uplifting to beta (and release) isn't needed.
So your patch will ride the trains as per above, see **Future branch dates** table in the release calender:
- now: Trunk/Daily 84 (as seen in: past branch dates).
- merge date 2020-11-16 (tentative): Beta 84
- merge date 2020-12-14 (tentative): Release 84, which will be branded as ESR TB 78.6 (as seen in that table, ESR: Firefox 78.6).

Hth, and hope that I got that right (any errors, please correct me). ;-)
Hi Chris, thank you for improving our code. Code quality is crucial.

Let me flesh this out for you a bit.

(In reply to Magnus Melin [:mkmelin] from comment #7)
> AH, this is from https://hg.mozilla.org/comm-central/rev/28e58c1b88e1 which was v 71 already.

That's where the patch for bug 1562157 was landed, which probably overlooked this detail per comment 1 and comment 4.
As this "error in code" does not affect the application behaviour like a regular "defect", we can consider it a mere code refactoring: I have changed the type of this bug from "defect" to "task".

> We use the status + target milestone for trunk, then the flags for tracking uplifts to branches.

Thunderbird release channels:
- `Daily -> Beta -> Release`
Code changes first land on "Trunk" from which Daily release is created, well, *daily*... ;-)
They then ride the train according to the [Rapid Release Calendar](https://wiki.mozilla.org/Release_Management/Calendar) (that's Firefox, but TB is roughly following that).

You can see from the first row of **Past Branch Dates** table that as of today, for Thunderbird:
- Trunk/Daily is 84 (FF Central, for TB: comm-central)
- Beta is 83
- Release is 82. Thunderbird uses the ESR cycle so we stick to 78 and push point releases, currently on 78.4.3 (Firefox 78.4).

So your patch here was landed on Trunk and automatically picked up by Daily, hence Target Milestone: 84 Branch (first landing).
Then there are tracking flags *on the bug* like tracking?thunderbird83 to request tracking, and determine "affected" or "wontfix".
For important fixes, uplifts can be requested (after landing) on the patch itself (attachment 9186671 [details] [diff] [review]), via `Details > Edit details. > approval-comm-beta? | approval-comm-release? (that's probably mailnews core) | approval-comm-esr78?`.

> But this additional parameter is just ignored, right? So it's just a matter of code cleanness.

This bug was set tracking?thunderbird83: *wontfix* so release drivers have decided uplifting to beta (and release) isn't needed.
So your patch will ride the trains as per above, see **Future branch dates** table in the release calender:
- now: Trunk/Daily 84 (as seen in: past branch dates).
- merge date 2020-11-16 (tentative): Beta 84
- merge date 2020-12-14 (tentative): Release 84, which will be branded as ESR TB 78.6 (as seen in that table, ESR: Firefox 78.6).

Hth, and hope that I got that right (any errors, please correct me). ;-)
Hi Chris, thank you for improving our code. Code quality is crucial.

Let me flesh this out for you a bit.

(In reply to Magnus Melin [:mkmelin] from comment #7)
> AH, this is from https://hg.mozilla.org/comm-central/rev/28e58c1b88e1 which was v 71 already.

That's where the patch for bug 1562157 was landed, which probably overlooked this detail per comment 1 and comment 4.
As this "error in code" does not affect the application behaviour like a regular "defect", we can consider it a mere code refactoring: I have changed the type of this bug from "defect" to "task".

> We use the status + target milestone for trunk, then the flags for tracking uplifts to branches.

Thunderbird release channels:
- `Daily -> Beta -> Release`

Code changes first land on "Trunk" from which Daily release is created, well, *daily*... ;-)
They then ride the train according to the [Rapid Release Calendar](https://wiki.mozilla.org/Release_Management/Calendar) (that's Firefox, but TB is roughly following that).

You can see from the first row of **Past Branch Dates** table that as of today, for Thunderbird:
- Trunk/Daily is 84 (FF Central, for TB: comm-central)
- Beta is 83
- Release is 82. Thunderbird uses the ESR cycle so we stick to 78 and push point releases, currently on 78.4.3 (Firefox 78.4).

So your patch here was landed on Trunk and automatically picked up by Daily, hence Target Milestone: 84 Branch (first landing).
Then there are tracking flags *on the bug* like tracking?thunderbird83 to request tracking, and determine "affected" or "wontfix".
For important fixes, uplifts can be requested (after landing) on the patch itself (attachment 9186671 [details] [diff] [review]), via `Details > Edit details. > approval-comm-beta? | approval-comm-release? (that's probably mailnews core) | approval-comm-esr78?`.

> But this additional parameter is just ignored, right? So it's just a matter of code cleanness.

This bug was set tracking?thunderbird83: *wontfix* so release drivers have decided uplifting to beta (and release) isn't needed.
So your patch will ride the trains as per above, see **Future branch dates** table in the release calender:
- now: Trunk/Daily 84 (as seen in: past branch dates).
- merge date 2020-11-16 (tentative): Beta 84
- merge date 2020-12-14 (tentative): Release 84, which will be branded as ESR TB 78.6 (as seen in that table, ESR: Firefox 78.6).

Hth, and hope that I got that right (any errors, please correct me). ;-)

Back to Bug 1675037 Comment 12