MozillaWiki - User contributions [en]

Sheriffing/How To/Landing patches

2019-06-10T15:24:11Z

Smacleod: Replace instructions with updated ones detailing #Check-in Needed using Phabricator and Lando.

{{Sheriffing How To|Landing check-needed patches}}
Sheriffs have the responsibility for landing checkin-needed patches on behalf of others who do not have the needed commit access to do so themselves or those who do not have the ability to watch their pushes afterwards. 
Usually, patches should be landed after the merges and after the nightly builds started running. Of course, it can also be done when requested.

= Phabricator queries for revisions requiring check-in =
* There is a saved Phabricator differential query that may be used to find revisions requiring check-in.
** Visit https://phabricator.services.mozilla.com/differential/ and click the '''#Check-in Needed''' link in the left menu’s list of queries.
** It is important to follow the link in this menu rather than use a direct link as if the query is modified the URL will be changed.
[[File:Check-in needed phabricator query menu.png|frame|center|Location of the menu link for '''#Check-in Needed''' Query]]

= How to land '''#Check-in Needed''' revisions =
The only supported method for landing check-in needed patches from Phabricator is Lando.

== Landing revisions via Lando (to [https://hg.mozilla.org/integration/autoland integration/autoland]) ==
=== Steps: ===
* Access the revision and click '''View Stack in Lando''' at the top right of the page:
[[File:Check-in needed phabricator view stack in lando.png|frame|center|Location of the '''View Stack in Lando''' link]]

* Verify that the reviewers who have accepted the revision have proper authority.
** Look at the reviewers column in the table showing the stack of revisions and identify the reviewers who have accepted each revision.
** Verify these reviewers are [[Modules/All|Module Owners/Peers]] and have the authority to review code for Firefox.
[[File:Check-in needed lando verify reviewers.png|frame|center|Location of reviewers in Lando]]

* Click the '''Preview Landing''' button in the bottom right corner of the page.
[[File:Check-in needed lando click preview landing.png|frame|center|Location of the '''Preview Landing''' button]]

* Quickly look over each commit message’s first line in the landing preview to ensure it is formatted correctly. Note that the preview pane scrolls vertically to list all of the commits.
[[File:Check-in needed lando inspect commit messages.png|frame|center|Location of each commit message's first line.]]

* Check the landing warnings.
** The bottom of the landing preview might contain a list of warnings that block landing unless acknowledged.
** Warnings should not be acknowledged without consideration.
** '''Only the "Has Previously landed." warning is acceptable to acknowledge''' and continue landing. If there are any other warnings present landing should halt.
[[File:Check-in needed lando warnings list.png|frame|center|A list of warnings in the Landing Preview]]

=== If you cannot land the patch from the GUI: ===
* Remove the '''#Check-in Needed''' project tag.
** To do this access the revision and click '''Edit Revision''' at the top right of the page.
[[File:Check-in needed phabricator edit revision.png|frame|center|Location of the '''Edit Revision''' link]]
* Comment on the revision that it could not be checked-in, providing the reason.

File:Check-in needed phabricator edit revision.png

2019-06-10T15:21:17Z

Smacleod:

Location of the edit revision link in Phabricator.

File:Check-in needed lando warnings list.png

2019-06-10T15:16:16Z

Smacleod:

A list of warnings in Lando's landing preview.

File:Check-in needed lando inspect commit messages.png

2019-06-10T15:13:59Z

Smacleod:

Where to inspect commit messages in lando.

File:Check-in needed lando click preview landing.png

2019-06-10T15:11:59Z

Smacleod:

Location of the preview landing button.

File:Check-in needed lando verify reviewers.png

2019-06-10T15:10:07Z

Smacleod:

Indication of where reviewers are listed in Lando

File:Check-in needed phabricator view stack in lando.png

2019-06-10T15:03:23Z

Smacleod:

Indication of how to visit lando from a Phabricator revision

File:Check-in needed phabricator query menu.png

2019-06-10T14:52:07Z

Smacleod:

Depiction of how to find the query for #Check-in Needed revisions in Phabricator.

Phabricator/Bugzilla Equivalents

2019-02-06T03:11:04Z

Smacleod: Finish off last WIP items.

Some common tasks in Bugzilla do not have direct analogues in Phabricator and others may not be obvious to a new user. This page serves to document these common tasks and how to handle similar situations when using Phabricator.

= Making requests to other users =

== Request '''review?''' on a patch ==
Patches may be [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#submitting-patches submitted to Phabricator] for review using [https://github.com/mozilla-conduit/review '''moz-phab''']. It is possible to ask for review as part of patch submission (See the [https://github.com/mozilla-conduit/review#execution '''moz-phab''' documentation]).

Note that Phabricator has two reviewer designations, normal and "blocking". Setting a user as a "blocking" reviewer is similar to the common use of a '''review?''' flag in that it requires review from that user or an explicit removal. Normal reviewers work differently in that acceptance from any reviewer removes the review from that user's queue (i.e. Only a single reviewer must accept). Using blocking reviewers mimics the Bugzilla workflow most closely, and there is a '''submit.always_blocking''' [https://github.com/mozilla-conduit/review#configuration configuration] option in '''moz-phab''' which will default to making all reviewers blocking.

== Request '''feedback?''' on a patch ==
Phabricator does not distinguish between asking for final review and requesting other forms of feedback. It is best to use an explicit comment explaining you would like feedback, along with one of:

* Requesting review from the user you'd like feedback from.
[[File:Non-blocking-review.png|320px]]

* Using an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you are expecting feedback.
[[File:At-mention.png|479px]]

== Make a '''needinfo?''' request ==
Phabricator does not have a feature directly comparable to Bugzilla's '''needinfo?''' request. We suggest one of the following alternatives:

* Use an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you expect a response.
[[File:At-mention.png|479px]]

* Add the user as a '''blocking reviewer''' and indicate your intent by including a comment. The Phabricator revision cannot be '''Accepted''' until the indicated user has either '''Accepted''' the revision, '''Resigned''' as a reviewer, or removed as a reviewer. Since this is re-purposing the normal request for review it is best to include a comment making your intended use clear.
[[File:Blocking-reviewer.png|324px]]

== Request '''review?''' of an image file ==
If you have a stand-alone image you'd like feedback on you may still do so using Bugzilla. Since the '''review?''' flag may be disabled for the component, please use a '''needinfo?''' or '''feedback?''' flag.

Phabricator does have the [https://phabricator.services.mozilla.com/pholio/ Pholio] application for commenting on mocks. Unfortunately it is not well integrated with the rest of our workflows and you cannot flag specific users for review. You can find Pholio in the main menu as "Design Review", and a new image can be uploaded by clicking [https://phabricator.services.mozilla.com/pholio/create/ "Create Mock"] on the main Pholio page.

== Clear a '''review?''' flag from your own patch ==
There are two ways to remove a patch from the queue of your reviewers:

* Explicitly edit the reviewers and remove the reviewer using the "Change Reviewers" action.
[[File:Change-Reviewers.png|206px]]

* "Plan Changes" to your revision, which removes the revision from their queue until you have posted a new version of the diff.
[[File:Plan-Changes.png|205px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments) you must click the "Submit" button.

== Request '''approval-mozilla-<repo>?''' uplift on a patch ==
At this time '''approval-mozilla-<repo>?''' requests should use the current [[Release Management/Uplift rules]]. '''approval-mozilla-<repo>?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move uplift approval to Phabricator fully, look out for an announcement when that is further along.

== Request '''sec-approval?''' on a patch ==
At this time '''sec-approval?''' requests should use the current [[Security/Bug Approval Process]]. '''sec-approval?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move '''sec-approval''' to Phabricator fully, look out for an announcement when that is further along.

== Request '''checkin-needed''' to land your changes ==
At this time '''checkin-needed''' requests should use the current [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch#Getting_the_patch_checked_into_the_tree checkin-needed process]. '''checkin-needed''' can be set on the bug linked to the Phabricator revision you wish to land. There is a plan to move '''checkin-needed''' to Phabricator fully, look out for an announcement when that is further along (Tracking [https://bugzilla.mozilla.org/show_bug.cgi?id=1514807 Bug 1514807]).

= Responding to requests =

== Clear a '''review?''' flag asked of you ==
If you'd like to remove yourself as a reviewer you can do so in one of two ways:

* Explicitly edit the reviewers and remove yourself using the "Change Reviewers" action.
[[File:Change-Reviewers-reviewer.png|216px]]

* Add the "Resign as Reviewer" action, which marks you as resigned. Resigning has mostly the same effect as removing yourself from the reviewer list except for the case when a project you're a member of has been asked for review. Resigning in the project case explicitly marks you as not a reviewer and is easier than removing the project and re-adding all other members.
[[File:Resign-As-Reviewer.png|204px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments), you must click the "Submit" button.

= Querying for Information =

== Query a user's review queue ==
You may query a user's review queue by crafting an advanced differential search query. Take the following steps:
# Visit this example query page: https://phabricator.services.mozilla.com/differential/query/IeE2zgiqj9EX/
# Change "Responsible Users" to the user you're interested in.
#* You probably do ''not'' want "Exact User: <username>" as it excludes revisions for the user's projects.
# Click "Search".
# The user's review queue are items under the "Must Review" and "Ready to Review" headings.

== Query a user's activity ==
You may query a user's activity by visiting their profile page: https://phabricator.services.mozilla.com/p/<username>/. An example user's profile page is here: https://phabricator.services.mozilla.com/p/bzbarsky/. The "Recent Activity" box lists only recent activity, but you may click the "View All" button to be taken to an advanced query of the user's activity.

== Save a frequently used query ==
Most query advanced query pages have a "Save Query" button on the results page. Clicking this allows you to give the query a name and add it to your personal query list. After saving a query you can share it with others by copying the URL of the results page (Note, this URL does not include the saved query name and is quite opaque).

= Other Tasks =

== Upload a WIP patch ==
Work in progress patches can be uploaded to Phabricator in the same way as a normal patch, although generally you would not add reviewers. If you'd like someone to look at your WIP patch you may add reviewers but it is best to explicitly mention what you expect from the reviewer.

== Watch a component ==
Phabricator has a notification system, [https://phabricator.services.mozilla.com/herald/ Herald], which allows you to create custom notification rules. This can be used to subscribe yourself to revisions that touch certain parts of the code base, or even add yourself as a reviewer. You can view example rules other user's have created [https://phabricator.services.mozilla.com/herald/query/all/ here].

Phabricator/Bugzilla Equivalents

2019-02-04T16:59:39Z

Smacleod: Fill out checkin-needed task.

Some common tasks in Bugzilla do not have direct analogues in Phabricator and others may not be obvious to a new user. This page serves to document these common tasks and how to handle similar situations when using Phabricator.

= Making requests to other users =

== Request '''review?''' on a patch ==
Patches may be [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#submitting-patches submitted to Phabricator] for review using [https://github.com/mozilla-conduit/review '''moz-phab''']. It is possible to ask for review as part of patch submission (See the [https://github.com/mozilla-conduit/review#execution '''moz-phab''' documentation]).

Note that Phabricator has two reviewer designations, normal and "blocking". Setting a user as a "blocking" reviewer is similar to the common use of a '''review?''' flag in that it requires review from that user or an explicit removal. Normal reviewers work differently in that acceptance from any reviewer removes the review from that user's queue (i.e. Only a single reviewer must accept). Using blocking reviewers mimics the Bugzilla workflow most closely, and there is a '''submit.always_blocking''' [https://github.com/mozilla-conduit/review#configuration configuration] option in '''moz-phab''' which will default to making all reviewers blocking.

== Request '''feedback?''' on a patch ==
Phabricator does not distinguish between asking for final review and requesting other forms of feedback. It is best to use an explicit comment explaining you would like feedback, along with one of:

* Requesting review from the user you'd like feedback from.
[[File:Non-blocking-review.png|320px]]

* Using an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you are expecting feedback.
[[File:At-mention.png|479px]]

== Make a '''needinfo?''' request ==
Phabricator does not have a feature directly comparable to Bugzilla's '''needinfo?''' request. We suggest one of the following alternatives:

* Use an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you expect a response.
[[File:At-mention.png|479px]]

* Add the user as a '''blocking reviewer''' and indicate your intent by including a comment. The Phabricator revision cannot be '''Accepted''' until the indicated user has either '''Accepted''' the revision, '''Resigned''' as a reviewer, or removed as a reviewer. Since this is re-purposing the normal request for review it is best to include a comment making your intended use clear.
[[File:Blocking-reviewer.png|324px]]

== Request '''review?''' of an image file ==
If you have a stand-alone image you'd like feedback on you may still do so using Bugzilla. Since the '''review?''' flag may be disabled for the component, please use a '''needinfo?''' or '''feedback?''' flag.

Phabricator does have the [https://phabricator.services.mozilla.com/pholio/ Pholio] application for commenting on mocks. Unfortunately it is not well integrated with the rest of our workflows and you cannot flag specific users for review. You can find Pholio in the main menu as "Design Review", and a new image can be uploaded by clicking [https://phabricator.services.mozilla.com/pholio/create/ "Create Mock"] on the main Pholio page.

== Clear a '''review?''' flag from your own patch ==
There are two ways to remove a patch from the queue of your reviewers:

* Explicitly edit the reviewers and remove the reviewer using the "Change Reviewers" action.
[[File:Change-Reviewers.png|206px]]

* "Plan Changes" to your revision, which removes the revision from their queue until you have posted a new version of the diff.
[[File:Plan-Changes.png|205px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments) you must click the "Submit" button.

== Request '''approval-mozilla-<repo>?''' uplift on a patch ==
At this time '''approval-mozilla-<repo>?''' requests should use the current [[Release Management/Uplift rules]]. '''approval-mozilla-<repo>?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move uplift approval to Phabricator fully, look out for an announcement when that is further along.

== Request '''sec-approval?''' on a patch ==
At this time '''sec-approval?''' requests should use the current [[Security/Bug Approval Process]]. '''sec-approval?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move '''sec-approval''' to Phabricator fully, look out for an announcement when that is further along.

== Request '''checkin-needed''' to land your changes ==
At this time '''checkin-needed''' requests should use the current [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch#Getting_the_patch_checked_into_the_tree checkin-needed process]. '''checkin-needed''' can be set on the bug linked to the Phabricator revision you wish to land. There is a plan to move '''checkin-needed''' to Phabricator fully, look out for an announcement when that is further along (Tracking [https://bugzilla.mozilla.org/show_bug.cgi?id=1514807 Bug 1514807]).

= Responding to requests =

== Clear a '''review?''' flag asked of you ==
If you'd like to remove yourself as a reviewer you can do so in one of two ways:

* Explicitly edit the reviewers and remove yourself using the "Change Reviewers" action.
[[File:Change-Reviewers-reviewer.png|216px]]

* Add the "Resign as Reviewer" action, which marks you as resigned. Resigning has mostly the same effect as removing yourself from the reviewer list except for the case when a project you're a member of has been asked for review. Resigning in the project case explicitly marks you as not a reviewer and is easier than removing the project and re-adding all other members.
[[File:Resign-As-Reviewer.png|204px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments), you must click the "Submit" button.

= Querying for Information =

== Query a user's review queue ==
You may query a user's review queue by crafting an advanced differential search query. Take the following steps:
# Visit this example query page: https://phabricator.services.mozilla.com/differential/query/IeE2zgiqj9EX/
# Change "Responsible Users" to the user you're interested in.
#* You probably do ''not'' want "Exact User: <username>" as it excludes revisions for the user's projects.
# Click "Search".
# The user's review queue are items under the "Must Review" and "Ready to Review" headings.

== Query a user's activity ==
You may query a user's activity by visiting their profile page: https://phabricator.services.mozilla.com/p/<username>/. An example user's profile page is here: https://phabricator.services.mozilla.com/p/bzbarsky/. The "Recent Activity" box lists only recent activity, but you may click the "View All" button to be taken to an advanced query of the user's activity.

== Save a frequently used query ==
Most query advanced query pages have a "Save Query" button on the results page. Clicking this allows you to give the query a name and add it to your personal query list. After saving a query you can share it with others by copying the URL of the results page (Note, this URL does not include the saved query name and is quite opaque).

= Other Tasks =

== Upload a WIP patch ==
TODO: Not sure if this workflow should be integrated into the request feedback section.

== Watch a component ==
TODO: Herald for subscribing to file changes.

Phabricator/Bugzilla Equivalents

2019-02-04T15:51:22Z

Smacleod: Document Pholio as a not well integrated workflow, recommending bugzilla still.

Some common tasks in Bugzilla do not have direct analogues in Phabricator and others may not be obvious to a new user. This page serves to document these common tasks and how to handle similar situations when using Phabricator.

= Making requests to other users =

== Request '''review?''' on a patch ==
Patches may be [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#submitting-patches submitted to Phabricator] for review using [https://github.com/mozilla-conduit/review '''moz-phab''']. It is possible to ask for review as part of patch submission (See the [https://github.com/mozilla-conduit/review#execution '''moz-phab''' documentation]).

Note that Phabricator has two reviewer designations, normal and "blocking". Setting a user as a "blocking" reviewer is similar to the common use of a '''review?''' flag in that it requires review from that user or an explicit removal. Normal reviewers work differently in that acceptance from any reviewer removes the review from that user's queue (i.e. Only a single reviewer must accept). Using blocking reviewers mimics the Bugzilla workflow most closely, and there is a '''submit.always_blocking''' [https://github.com/mozilla-conduit/review#configuration configuration] option in '''moz-phab''' which will default to making all reviewers blocking.

== Request '''feedback?''' on a patch ==
Phabricator does not distinguish between asking for final review and requesting other forms of feedback. It is best to use an explicit comment explaining you would like feedback, along with one of:

* Requesting review from the user you'd like feedback from.
[[File:Non-blocking-review.png|320px]]

* Using an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you are expecting feedback.
[[File:At-mention.png|479px]]

== Make a '''needinfo?''' request ==

Phabricator does not have a feature directly comparable to Bugzilla's '''needinfo?''' request. We suggest one of the following alternatives:

* Use an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you expect a response.
[[File:At-mention.png|479px]]

* Add the user as a '''blocking reviewer''' and indicate your intent by including a comment. The Phabricator revision cannot be '''Accepted''' until the indicated user has either '''Accepted''' the revision, '''Resigned''' as a reviewer, or removed as a reviewer. Since this is re-purposing the normal request for review it is best to include a comment making your intended use clear.
[[File:Blocking-reviewer.png|324px]]

== Request '''review?''' of an image file ==
If you have a stand-alone image you'd like feedback on you may still do so using Bugzilla. Since the '''review?''' flag may be disabled for the component, please use a '''needinfo?''' or '''feedback?''' flag.

Phabricator does have the [https://phabricator.services.mozilla.com/pholio/ Pholio] application for commenting on mocks. Unfortunately it is not well integrated with the rest of our workflows and you cannot flag specific users for review. You can find Pholio in the main menu as "Design Review", and a new image can be uploaded by clicking [https://phabricator.services.mozilla.com/pholio/create/ "Create Mock"] on the main Pholio page.

== Clear a '''review?''' flag from your own patch ==

There are two ways to remove a patch from the queue of your reviewers:

* Explicitly edit the reviewers and remove the reviewer using the "Change Reviewers" action.
[[File:Change-Reviewers.png|206px]]

* "Plan Changes" to your revision, which removes the revision from their queue until you have posted a new version of the diff.
[[File:Plan-Changes.png|205px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments) you must click the "Submit" button.

== Request '''approval-mozilla-<repo>?''' uplift on a patch ==
At this time '''approval-mozilla-<repo>?''' requests should use the current [[Release Management/Uplift rules]]. '''approval-mozilla-<repo>?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move uplift approval to Phabricator fully, look out for an announcement when that is further along.

== Request '''sec-approval?''' on a patch ==
At this time '''sec-approval?''' requests should use the current [[Security/Bug Approval Process]]. '''sec-approval?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move '''sec-approval''' to Phabricator fully, look out for an announcement when that is further along.

== Request '''checkin-needed''' to land your changes ==
TODO: Move to phabricator tag.

= Responding to requests =

== Clear a '''review?''' flag asked of you ==
If you'd like to remove yourself as a reviewer you can do so in one of two ways:

* Explicitly edit the reviewers and remove yourself using the "Change Reviewers" action.
[[File:Change-Reviewers-reviewer.png|216px]]

* Add the "Resign as Reviewer" action, which marks you as resigned. Resigning has mostly the same effect as removing yourself from the reviewer list except for the case when a project you're a member of has been asked for review. Resigning in the project case explicitly marks you as not a reviewer and is easier than removing the project and re-adding all other members.
[[File:Resign-As-Reviewer.png|204px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments), you must click the "Submit" button.

= Querying for Information =

== Query a user's review queue ==
You may query a user's review queue by crafting an advanced differential search query. Take the following steps:
# Visit this example query page: https://phabricator.services.mozilla.com/differential/query/IeE2zgiqj9EX/
# Change "Responsible Users" to the user you're interested in.
#* You probably do ''not'' want "Exact User: <username>" as it excludes revisions for the user's projects.
# Click "Search".
# The user's review queue are items under the "Must Review" and "Ready to Review" headings.

== Query a user's activity ==
You may query a user's activity by visiting their profile page: https://phabricator.services.mozilla.com/p/<username>/. An example user's profile page is here: https://phabricator.services.mozilla.com/p/bzbarsky/. The "Recent Activity" box lists only recent activity, but you may click the "View All" button to be taken to an advanced query of the user's activity.

== Save a frequently used query ==
Most query advanced query pages have a "Save Query" button on the results page. Clicking this allows you to give the query a name and add it to your personal query list. After saving a query you can share it with others by copying the URL of the results page (Note, this URL does not include the saved query name and is quite opaque).

= Other Tasks =

== Upload a WIP patch ==
TODO: Not sure if this workflow should be integrated into the request feedback section.

== Watch a component ==
TODO: Herald for subscribing to file changes.

Phabricator/Bugzilla Equivalents

2019-02-04T15:45:59Z

Smacleod: Clear up some whitespace.

Some common tasks in Bugzilla do not have direct analogues in Phabricator and others may not be obvious to a new user. This page serves to document these common tasks and how to handle similar situations when using Phabricator.

= Making requests to other users =

== Request '''review?''' on a patch ==
Patches may be [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#submitting-patches submitted to Phabricator] for review using [https://github.com/mozilla-conduit/review '''moz-phab''']. It is possible to ask for review as part of patch submission (See the [https://github.com/mozilla-conduit/review#execution '''moz-phab''' documentation]).

Note that Phabricator has two reviewer designations, normal and "blocking". Setting a user as a "blocking" reviewer is similar to the common use of a '''review?''' flag in that it requires review from that user or an explicit removal. Normal reviewers work differently in that acceptance from any reviewer removes the review from that user's queue (i.e. Only a single reviewer must accept). Using blocking reviewers mimics the Bugzilla workflow most closely, and there is a '''submit.always_blocking''' [https://github.com/mozilla-conduit/review#configuration configuration] option in '''moz-phab''' which will default to making all reviewers blocking.

== Request '''feedback?''' on a patch ==
Phabricator does not distinguish between asking for final review and requesting other forms of feedback. It is best to use an explicit comment explaining you would like feedback, along with one of:

* Requesting review from the user you'd like feedback from.
[[File:Non-blocking-review.png|320px]]

* Using an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you are expecting feedback.
[[File:At-mention.png|479px]]

== Make a '''needinfo?''' request ==

Phabricator does not have a feature directly comparable to Bugzilla's '''needinfo?''' request. We suggest one of the following alternatives:

* Use an '''@''' mention. Including '''@<username>''' in a comment on Phabricator notifies the provided user of your message. The notification is a one-time action which does not require acknowledgement, so it is best to make it clear with your text that you expect a response.
[[File:At-mention.png|479px]]

* Add the user as a '''blocking reviewer''' and indicate your intent by including a comment. The Phabricator revision cannot be '''Accepted''' until the indicated user has either '''Accepted''' the revision, '''Resigned''' as a reviewer, or removed as a reviewer. Since this is re-purposing the normal request for review it is best to include a comment making your intended use clear.
[[File:Blocking-reviewer.png|324px]]

== Request '''review?''' of an image file ==
If you have a stand-alone image you'd like to ask for review on you may do so using the [https://phabricator.services.mozilla.com/pholio/ Pholio] Phabricator application. You can find Pholio in the main menu as "Design Review", and a new image can be uploaded by clicking [https://phabricator.services.mozilla.com/pholio/create/ "Create Mock"] on the main Pholio page.

== Clear a '''review?''' flag from your own patch ==

There are two ways to remove a patch from the queue of your reviewers:

* Explicitly edit the reviewers and remove the reviewer using the "Change Reviewers" action.
[[File:Change-Reviewers.png|206px]]

* "Plan Changes" to your revision, which removes the revision from their queue until you have posted a new version of the diff.
[[File:Plan-Changes.png|205px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments) you must click the "Submit" button.

== Request '''approval-mozilla-<repo>?''' uplift on a patch ==
At this time '''approval-mozilla-<repo>?''' requests should use the current [[Release Management/Uplift rules]]. '''approval-mozilla-<repo>?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move uplift approval to Phabricator fully, look out for an announcement when that is further along.

== Request '''sec-approval?''' on a patch ==
At this time '''sec-approval?''' requests should use the current [[Security/Bug Approval Process]]. '''sec-approval?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move '''sec-approval''' to Phabricator fully, look out for an announcement when that is further along.

== Request '''checkin-needed''' to land your changes ==
TODO: Move to phabricator tag.

= Responding to requests =

== Clear a '''review?''' flag asked of you ==
If you'd like to remove yourself as a reviewer you can do so in one of two ways:

* Explicitly edit the reviewers and remove yourself using the "Change Reviewers" action.
[[File:Change-Reviewers-reviewer.png|216px]]

* Add the "Resign as Reviewer" action, which marks you as resigned. Resigning has mostly the same effect as removing yourself from the reviewer list except for the case when a project you're a member of has been asked for review. Resigning in the project case explicitly marks you as not a reviewer and is easier than removing the project and re-adding all other members.
[[File:Resign-As-Reviewer.png|204px]]

Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments), you must click the "Submit" button.

= Querying for Information =

== Query a user's review queue ==
You may query a user's review queue by crafting an advanced differential search query. Take the following steps:
# Visit this example query page: https://phabricator.services.mozilla.com/differential/query/IeE2zgiqj9EX/
# Change "Responsible Users" to the user you're interested in.
#* You probably do ''not'' want "Exact User: <username>" as it excludes revisions for the user's projects.
# Click "Search".
# The user's review queue are items under the "Must Review" and "Ready to Review" headings.

== Query a user's activity ==
You may query a user's activity by visiting their profile page: https://phabricator.services.mozilla.com/p/<username>/. An example user's profile page is here: https://phabricator.services.mozilla.com/p/bzbarsky/. The "Recent Activity" box lists only recent activity, but you may click the "View All" button to be taken to an advanced query of the user's activity.

== Save a frequently used query ==
Most query advanced query pages have a "Save Query" button on the results page. Clicking this allows you to give the query a name and add it to your personal query list. After saving a query you can share it with others by copying the URL of the results page (Note, this URL does not include the saved query name and is quite opaque).

= Other Tasks =

== Upload a WIP patch ==
TODO: Not sure if this workflow should be integrated into the request feedback section.

== Watch a component ==
TODO: Herald for subscribing to file changes.

Phabricator/Bugzilla Equivalents

2019-02-04T05:31:36Z

Smacleod: Dump answers in a couple more TODO tasks, and add another task.

Some common tasks in Bugzilla do not have direct analogues in Phabricator and others may not be obvious to a new user. This page serves to document these common tasks and how similar situations should be handled when using Phabricator.

= Tasks =

== Querying for Information ==

=== Query a user's review queue ===
You may query a user's review queue by crafting an advanced differential search query. Take the following steps:
* Visit this example query page: https://phabricator.services.mozilla.com/differential/query/IeE2zgiqj9EX/
* Change "Responsible Users" to the user you're interested in.
** You probably do ''not'' want "Exact User: <username>" as it excludes revisions for the user's projects.
* Click "Search".
* The user's review queue are items under the "Must Review" and "Ready to Review" headings.

=== Query a user's activity ===
You may query a user's activity by visiting their profile page: https://phabricator.services.mozilla.com/p/<username>/. An example user's profile page is here: https://phabricator.services.mozilla.com/p/bzbarsky/. The "Recent Activity" box lists only recent activity, but you may click the "View All" button to be taken to an advanced query of the user's activity.

=== Save a frequently used query ===
Most query advanced query pages will have a "Save Query" button on the results page. Clicking this will allow you to give the query a name and add it to your personal query list. After saving a query you can share it with others by copying the URL of the results page (Note, this url does not include the saved query name and is quite opaque).

== Making requests to other users ==

=== Make a '''needinfo?''' request ===
Phabricator does not have a feature directly comparable to Bugzilla's '''needinfo?''' request. We suggest one of the following alternatives:
* Use an '''@''' mention. Including '''@<username>''' in a comment on Phabricator will notify the provided user of your message. This is a one-time notification which does not require acknowledgement, so it is best to make it clear with your text that you expect a response.
* Add the user as a '''blocking reviewer''' and indicate your intent by including a comment. This will prevent the Phabricator revision from becoming '''Accepted''' until the indicated user has either '''Accepted''' the revision, '''Resigned''' as a reviewer, or been removed as a reviewer. Since this is re-purposing the normal request for review it is best to include a comment making your intended use clear.

=== Request '''feedback?''' on a patch ===
Phabricator does not distinguish between asking for final review and requesting other forms of feedback. It is best to use an explicit comment explaining you would like feedback, along with one of:
* Requesting review from the user you'd like feedback from.
* Using an '''@''' mention. Including '''@<username>''' in a comment on Phabricator will notify the provided user of your message. This is a one-time notification which does not require acknowledgement, so it is best to make it clear with your text that you are expecting feedback.

=== Request '''review?''' on a patch ===
Patches may be [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#submitting-patches submitted to Phabricator] for review using [https://github.com/mozilla-conduit/review '''moz-phab''']. It is possible to ask for review as part of patch submission (See the [https://github.com/mozilla-conduit/review#execution '''moz-phab''' documentation for this]).

Note that Phabricator has two reviewer designations, normal and "blocking". Setting a user as a "blocking" reviewer is similar to the common use of a '''review?''' flag in that it requires review from that user or an explicit removal. Normal reviewers work differently in that an acceptance from any reviewer will remove the review from that user's queue (i.e. Only a single reviewer must accept). Using blocking reviewers will mimic the Bugzilla workflow most closely and there is a '''submit.always_blocking''' [https://github.com/mozilla-conduit/review#configuration configuration] option in '''moz-phab''' which will default to making all reviewers blocking.

=== Clear a '''review?''' flag from your own patch ===
There are two ways to remove a patch from the queue of your reviewers:
# Explicitly edit the reviewers and remove the reviewer using the "Change Reviewers" action.
# "Plan Changes" to your revision, which will remove the revision from their queue until you have posted a new version of the diff.
Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments) you must click the "Submit" button.

=== Clear a '''review?''' flag asked of you ===
If you'd like to remove yourself as a reviewer you can do so in one of two ways:
# Explicitly edit the reviewers and remove yourself using the "Change Reviewers" action.
# Add the "Resign as Reviewer" action, which will mark you as resigned. This has mostly the same effect as removing yourself from the reviewer list except for the case when a project you're a member of has been asked for review. Resigning in the project case will explicitly mark you as not a reviewer and is easier than removing the project and re-adding all other members.
Both of these actions are taken using the "Add Action..." dropdown at the bottom of the revision's page. After you have added the action (along with any comments) you must click the "Submit" button.

=== Request '''approval-mozilla-<repo>?''' uplift on a patch ===
At this time '''approval-mozilla-<repo>?''' requests should use the current [[Release Management/Uplift rules]]. '''approval-mozilla-<repo>?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move uplift approval to Phabricator fully and an announcement will be made when that is further along.

=== Request '''checkin-needed''' to land your changes ===
TODO: Move to phabricator tag.

=== Request '''review?''' of an image file ===
If you have a stand-alone image you'd like to ask for review on you may do so using the [https://phabricator.services.mozilla.com/pholio/ Pholio] Phabricator application. This is linked in the main menu as "Design Review" and a new image can be uploaded by clicking [https://phabricator.services.mozilla.com/pholio/create/ "Create Mock"] on the main Pholio page.

=== Request '''sec-approval?''' on a patch ===
At this time '''sec-approval?''' requests should use the current [[Security/Bug Approval Process]]. '''sec-approval?''' can be set on the Bugzilla attachment which corresponds to the revision in Phabricator. There is a plan to move '''sec-approval''' to Phabricator fully and an announcement will be made when that is further along.

== Other Tasks ==

=== Upload a WIP patch ===
TODO: Not sure if this workflow should be integrated into the request feedback section.

=== Watch a component ===
TODO: Herald for subscribing to file changes.

Phabricator/Bugzilla Equivalents

2019-02-01T16:52:19Z

Smacleod: Finish uplift approval flag item.

Phabricator/Bugzilla Equivalents

2019-02-01T16:45:49Z

Smacleod: Add sec-approval? item.

Phabricator/Bugzilla Equivalents

2019-01-31T15:34:44Z

Smacleod: Created page with "Some common tasks in Bugzilla do not have direct analogues in Phabricator and others may not be obvious to a new user. This page serves to document these common tasks and how..."

EngineeringProductivity/Projects/Conduit

2017-07-07T11:51:49Z

Smacleod: Fixup tech stack link

= Project Definition =

Project Conduit is a loosely coupled, extensible set of services that will provide automation and visualization of the main Firefox engineering processes, from submitting changesets for review to landing them. It is an evolution and course correction of [[EngineeringProductivity/Projects/MozReview|MozReview]].

The central concept of Conduit is the organization of our systems around commits. Commits are discrete units of work that exist from the initial submission of code changes from a developer for feedback, testing, and review, up to landing on integration branches and from there moving to mozilla-central and release branches. Since a commit is the final form of a code change, including metadata like date, author, summary, etc., it is easiest to work with them throughout the whole system, copying and transforming them as needed.

Conduit will include a code-review tool ([[Phabricator]]) with some custom extensions, and various services relating to submission, analysis, testing, and landing of commits.

See the Conduit [[/RoadMap|road map]].

See also our [[/DesignDocs|design docs]], which may be moved to https://readthedocs.org at some point.

= Tracking =

Conduit is being developed in fortnightly sprints. See our [https://trello.com/b/x0a7Ybfi/conduit Trello board].

mcote also posts updates and notes to [https://mrcote.info/blog/categories/conduit/ his blog].

= Code =

Code for Conduit services is on GitHub in the [https://github.com/mozilla-conduit mozilla-conduit] org. Our Phabricator [https://github.com/mozilla-services/phabricator-extensions extensions] are located in their own repo, as are our Phabricator [https://github.com/mozilla-services/mozphab configuration files]. There is also a [[BMO]] [https://github.com/mozilla-bteam/bmo/tree/master/extensions/PhabBugz extension] for integrating with Phabricator.

= Bugs and Communication =

Bugs should be filed in the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=General Conduit product] on BMO.

Announcements and discussion are in the mozilla.tools newsgroup/[https://lists.mozilla.org/listinfo/tools mailing list]/[https://groups.google.com/forum/#!forum/mozilla.tools Google group] and mozilla.dev.version-control newsgroup/[https://lists.mozilla.org/listinfo/dev-version-control mailing list]/[https://groups.google.com/forum/#!forum/mozilla.dev.version-control Google group].

Discussion also occurs in the #conduit channel on irc.mozilla.org and on Slack.

= The Commit-based Approach =

== Autoland ==

Authorized developers should have a way to land any commits, their own or others', with the press of a button. This system should
* support Mercurial
* preserve the original commits' author and message
* retry if the destination repository is closed or unavailable (e.g. trees are closed)
* have a permission model that allows authorized users to use autoland even if they can't push directly to the destination repo
** this allows us to restrict direct-landing permission, and hence keys, to a small subset of people
* allow different sources and destinations (staging to try, staging to mozilla-central, uplifts from mozilla-central to beta to release)

Note that this system is made much simpler by having a staging repository and transplanting commits rather than applying diffs for a number of reasons:
* history is preserved so commits can be sent to try for testing without rebasing first
* all metadata is already in the staged commits (author, commit message, etc.).
** this is particularly important in our workflow because some developers use different hg author names/emails from what they use in Bugzilla
* a stack of commits can be landed at once

Furthermore, an advanced Autoland service can provide tighter integration with GitHub-hosted repositories. This is particularly important for some of the Quantum work, which requires synchronization of Servo and Gecko code.

== Tracking and Visualization ==

In the Firefox development and release process, code changes traditionally follow this process:

# Developer pushes patch to Bugzilla
# Developer may push patch to Try for test results, which may or may not be posted to or linked from the bug
# After the patch gets an r+, developer commits and pushes to mozilla-inbound
# Sheriff merges changesets, in bulk, to the mozilla-central branch.
# A Nightly build is created which contains the changeset, amongst many others.
# The changeset is merged, along with other unrelated changesets, to the aurora branch.
# An Aurora build is created which contains the changeset, amongst many others.
# Repeat steps 5-6 for beta and release.

At any point, the changeset may also be backed out of a particular branch and later reapplied (in a modified form).

There is currently no straightforward way to track or see work "move" across the branches and builds. The combination of a central commit index plus an integrated Autoland service would provide this view and would be of use to developers and release managers.

== Static Analysis and Other Reports ==

With a microservice architecture and a commit index, adding a new analysis step, either manually or automatically initiated, becomes straightforward. Commits can be easily pulled down to a testing server straight from the staging repo and results either posted to the bug or code-review tool, or pulled into the commit index for visualization.

== Microcommits ==

Having a push-based approach (i.e. a staging/review repository) makes it simpler to break up a large piece of work into a series of small commits. Microcommits improve quality and reduce review time by shrinking the scope of each change. Furthermore, Mercurial's history-editing abilities mean that history is not lost when commits are edited or rebased (obsolete commits do not automatically get deleted) and that force-pushes are not required.

The flexibility of a push-based approach also allows other types of workflows, such as squashing multiple local changesets into a single changeset for review.

== Loose Coupling ==

By separating core process automation from the work to integrate such automation with code-review and other tools, not only should it be possible to replace a tool without major effort, but improvements and bug fixes to individual services should be much easier.

= High-Level Design =

Conduit is designed around multiple small services, with the exception of necessarily larger tools, for example issue trackers and code-review apps. Services will generally have their own UIs, moving away from our previous model in which automation interfaces have been integrated directly into the larger tools. Standing up separate UIs for individual services, such as autoland, allows them to be used independent of bug-tracking and code-review tools and also speeds up development, freed from the confines of an extension system.

Initial services will include autoland and a commit index. Both functions currently exist but are tightly coupled with Review Board, with much of the code living in the MozReview Review Board extension. These will be split off into small, independent applications.

== Alternatives ==

The other clear alternative is the path MozReview was previously on: continuing to develop automation services partially within Review Board, and continuing to improve core Review Board features at the same time. This has been unsatisfactory for the reasons expounded above.

Another alternative is to use a full tool suite that implements the same level of changeset-based automation that we have (push-to-review, autoland) and that we are working on or planning for (conflict detection, static analysis, etc.). Solutions in this area are few and far between and often designed with smaller applications in mind. GitHub can be seen as one such alternative, though it lacks critical features like support for confidential issues and patches and has clear integration path with our testing and CI systems. We are planning some support for GitHub-based workflows, but it cannot be a full replacement for our processes. Similarly, suites like Phabricator offer compelling issue-tracking and code-review tools that we can use in Conduit, but they lack an autoland feature that meets our requirements, as well as the flexibility offered by a repository-based system.

In general, Firefox is a sufficiently unique, complex, and highly scaled project that it is highly unlikely that there exists any off-the-shelf solution that can fully automate our engineering processes. However we are always exploring ways that we can avoid duplicating effort.

= See also =

* [https://mrcote.info/blog/2017/01/13/project-conduit/ Introductory blog post]
* [[/Tech_Stack|Our Tech Stack]]

EngineeringProductivity/Projects/Conduit/Tech Stack

2017-07-07T11:49:51Z

Smacleod: Initial tech stack draft.

= Our Technologies =

The following is a non-exhaustive lists of the technologies the team primarily uses. When developing a new system, especially under tight time constraints, it is a good idea to stick with these technologies.

== Programming Languages ==

=== Python (3.5+) ===

Python is our team's primary programming language. It is a versatile language which is both easy to learn and powerful. Much of our team's previously developed software is built with Python.

Python 3 is the preferred version as it is the future of Python development and most libraries are compatible.

Notes:

* Python has ''good enough'' performance for most tasks and is adequate until measurements show otherwise.
* There are many existing Python services interacting with Mozilla's various systems, which may serve as examples.

The following is a set of python libraries commonly used by our team (It's best to have a concrete reason when considering an alternative library that is not listed here):

* click
* connexion
* Django
* Flask
* Kombu
* pytest
* requests
* SQLalchemy

=== Python (2.7.x) ===

Python 2 is used where version 3 is inappropriate. This includes the following locations:

* Mercurial extensions (mercurial's python 3 support is incomplete 2017-06-16)
* Scripts packaged with the Firefox build environment
* Modifications to existing systems built with Python 2

=== Javascript ===

Javascript is used by our team for building client side web applications.

== Supporting Services ==

=== uWSGI ===

uWSGI is our preferred WSGI server/gateway.

=== PostgreSQL ===

PostgreSQL is our preferred database.

Notes:

* Traditional RDBMS' are well understood by our development team
* Our operations team is more experienced with SQL systems vs newer NOSQL databases
* PostgreSQL can fulfill a similar role to NOSQL databases using the built-in JSON data types.
* There are mature libraries and tools for working with PostgreSQL
* Performance characteristics are well understood and adequate

=== Redis ===

Redis is the preferred choice for in-memory storage of data. It performs comparably with memcached in traditional caching scenarios but also supports more powerful data types.

Redis is also suitable as a persistent data store when configured correctly. This is at the expense of some performance, but may be used as such where it makes sense.

=== Amazon SNS/SQS ===

Amazon's notification and messaging services are the preferred choice when a reliable internal message queue is required.

=== RabbitMQ (Mozilla's Pulse) ===

Messages which are relevant to a wider audience may be published to Mozilla's Pulse service. While it is possible to use Pulse for non-sensitive internal messages, Amazon SNS/SQS is preferred.

== Conceptual Choices ==

=== OpenAPI (Swagger) ===

=== RESTful ===

EngineeringProductivity/Projects/Conduit

2017-06-29T21:23:08Z

Smacleod: Add a page for our tech stack

DeveloperServices/TeamMeetings/2015-07-21

2015-07-21T17:30:09Z

Smacleod: /* Planned for this week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** hwine → fubar (all quiet)

== Stand-up ==
=== Last week ===
* fubar
** DXR
*** fixed CentOS images to build again, added build/*, rust testing {{bug|1175886}}, waiting on DXR fix {{bug|1183952}}
*** workaround for multi-tree searching {{bug|1164071}}
** BMO
*** apache segfaults, abrtd/coredumps {{bug|1184848}}
*** new cron job {{bug|1185851}}
*** AWS design review meeting
*** misc bug cleanup
** Treeherder
*** perfherder.m.o setup {{bug|1184957}}
*** new ENV handling in puppet {{bug|1183443}}, review {{bug|1175432}}
** AWS
*** Treeherder access tweak
*** remove bkero's access, reset root pw {{bug|1185994}}
** MozReview - fix broken puppet config {{bug|1186033}}
** Misc/sec
*** remove bkero's access, reset root pw {{bug|1185994}}
*** ES advisories (review only, no action yet) {{bug|1184692}} {{bug|1184723}}
* gps
* hwine
** TCW went smoothly
** scl3 sea micros ready for turn down
** cvs blog post
* lmandel
* smacleod
** Sick
** Decoupled r+ carryforward code from autoland review stuff to get it landed quicker {{bug|1175166}}
*** Just finishing up test writing
** Investigation of interdiff issue {{bug|1183664}}
*** Almost certain this is an RB core bug now

=== Planned for this week ===
* fubar
** DXR - set up second builder, test ansible changes; test rust and pypy builds
** BMO - memcache stats to :r2, review current design draft
** Treeherder - sort out perfherder site
* gps
* hwine
** more evac scl3
** start legacy → modern cutover
* lmandel
* smacleod
** Get review and land r+ carryforward {{bug|1175166}}
** Report interdiff issue to core / check if fixed in newer RB {{bug|1183664}}
** Upgrade RBTools
** More autoland work

== Other business ==

== PTOs, etc ==

== Links ==
[https://wiki.mozilla.org/DeveloperServices/Goals-2015Q3 Q3 Goals]

DeveloperServices/TeamMeetings/2015-07-21

2015-07-21T17:27:47Z

Smacleod: /* Last week */

DeveloperServices/TeamMeetings/2015-07-14

2015-07-14T17:58:59Z

Smacleod: /* Planned for this week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** bkero → hwine

== Stand-up ==
=== Last week ===
* bkero
** Bug handoff
** Finishing up sorting through backlog
* fubar
** new mana space
** Treeherder
*** dev access issue {{bug|1179860}}
*** ENV changes {{bug|1182163}}, {{bug|1182302, {{bug|1183443}}
** BMO
*** BMO spammer
*** fix bmoattachments.org redirect loop {{bug|1094835}}, {{bug|1183151}}
** DXR - steal m-c docker base, pypy testing (fail), builder image issues/testing {{bug|1175886}}
* gps
** bundleclone data analysis follow-ups. {{bug|1181783}} is interesting
** bundleclone S3 expiration fire drill ({{bug|1182739}}
** mach mercurial-setup prompting ({{bug|1182677}})
** Core Mercurial performance work (derived from issue noticed by hwine)
** CentOS 7 headaches related to hgweb1 and admin server
* hwine
** vcs-sync odds & ends - all in parallel, one item to fix before scl3 turn down
** various b2g repos needed mirroring
** TCW & other releng stuff
* lmandel
* smacleod
** Investigated switching MozReview request creation to single API call
** More r+ carryforward + autoland stuff

=== Planned for this week ===
* bkero
** Bug handoff
** Do most the things the sticky notes on my monitor say
** Offboarding stuff
* fubar
** DXR - prod cutover to SCL3?, merge build changes to master and document
** BMO - new jobs on ETL node, https for esfrontline, BMO RRA
* gps
** Mercurial performance work (trying to beat 3.5 patch deadline this week)
** Continue keeping an eye on bundleclone foo
** Land mach mercurial-setup prompting ({{bug|1182677}})
** CentOS 7 follow-ups/potential workarounds
* hwine
** vcs-sync - disable scl3!!!!
** clean up all the repo things
* lmandel
* smacleod
** Keep working on r+ carryforward / autoland
** Figure out if we want to switch to single API for request posting & if so, do it

== Other business ==

== PTOs, etc ==

== Links ==
[https://wiki.mozilla.org/DeveloperServices/Goals-2015Q2 Q2 Goals]

DeveloperServices/TeamMeetings/2015-07-14

2015-07-14T17:55:46Z

Smacleod: /* Last week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** bkero → hwine

== Stand-up ==
=== Last week ===
* bkero
** Bug handoff
** Finishing up sorting through backlog
* fubar
** new mana space
** Treeherder
*** dev access issue {{bug|1179860}}
*** ENV changes {{bug|1182163}}, {{bug|1182302, {{bug|1183443}}
** BMO
*** BMO spammer
*** fix bmoattachments.org redirect loop {{bug|1094835}}, {{bug|1183151}}
** DXR - steal m-c docker base, pypy testing (fail), builder image issues/testing {{bug|1175886}}
* gps
** bundleclone data analysis follow-ups. {{bug|1181783}} is interesting
** bundleclone S3 expiration fire drill ({{bug|1182739}}
** mach mercurial-setup prompting ({{bug|1182677}})
** Core Mercurial performance work (derived from issue noticed by hwine)
** CentOS 7 headaches related to hgweb1 and admin server
* hwine
** vcs-sync odds & ends - all in parallel, one item to fix before scl3 turn down
** various b2g repos needed mirroring
** TCW & other releng stuff
* lmandel
* smacleod
** Investigated switching MozReview request creation to single API call
** More r+ carryforward + autoland stuff

=== Planned for this week ===
* bkero
** Bug handoff
** Do most the things the sticky notes on my monitor say
** Offboarding stuff
* fubar
** DXR - prod cutover to SCL3?, merge build changes to master and document
** BMO - new jobs on ETL node, https for esfrontline, BMO RRA
* gps
** Mercurial performance work (trying to beat 3.5 patch deadline this week)
** Continue keeping an eye on bundleclone foo
** Land mach mercurial-setup prompting ({{bug|1182677}})
** CentOS 7 follow-ups/potential workarounds
* hwine
** vcs-sync - disable scl3!!!!
** clean up all the repo things
* lmandel
* smacleod

== Other business ==

== PTOs, etc ==

== Links ==
[https://wiki.mozilla.org/DeveloperServices/Goals-2015Q2 Q2 Goals]

DeveloperServices/TeamMeetings/2015-07-07

2015-07-07T17:48:51Z

Smacleod: /* Planned for this week */

DeveloperServices/TeamMeetings/2015-07-07

2015-07-07T17:47:23Z

Smacleod: /* Last week */

DeveloperServices/TeamMeetings/2015-06-16

2015-06-16T16:39:39Z

Smacleod: Created page with " « previous meeting — index – DeveloperSe..."

DeveloperServices/TeamMeetings/2015-06-02

2015-06-02T17:58:02Z

Smacleod: /* Planned for this week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** hwine → fubar (Wednesday)
** nothing active

== Stand-up ==
=== Last week ===
* bkero
** Code review + bugfixing for hg.m.o bundle generation
** Python 2.7 for hg.m.o/git.m.o installed. venv work landed, need to get scripts to use it
** Smaller issues: (SVN ACLs for T-bird, ldap perms for private hg.m.o repo)
* fubar
** PTO
* gps
** hg.mozilla.org is now generating and serving bundles from S3
*** http://gregoryszorc.com/blog/2015/05/29/faster-cloning-from-hg.mozilla.org-with-server-provided-bundles/
** Landed rewriting API and changeset id recording to MozReview
** Blogged about MozReview changes from last week: http://gregoryszorc.com/blog/2015/05/29/important-changes-to-mozreview/
** Progress on server for moz.build metadata ({{bug|1168607}})
* hwine
** vcs-sync
** cvs/bzr archiving to ftp
** spring release
* lmandel
** Reviewed SVN information from fubar.
* smacleod
** Productivity sapping Cold + Allergies
** Worked more on the MozReview LDAP querying

=== Planned for this week ===
* bkero
** Transition hgweb heads to using a python2.7-venv mod_wsgi
** Move some 'hg' module Puppet resources to ansible
* fubar
** catch up
** BMO deploy fixes
** DXR/ES, Rust index
* gps
** continue working on moz.build metadata server
*** unblocks auto bug filing and eventually auto reviewer selection
*** ... which is a soft blocker on GitHub integration
** Pulse publishing of GitHub webhooks?
** Mercurial 3.4.1 deployment?
** MozReview Review-URL/workflow enhancements?
* hwine
** vcs-sync
** blog post for cvs
** releng scl3 work planning
* lmandel
** Start following up with people about their SVN repos
* smacleod
** Review Queue
** Finish up MozReview LDAP
** Finish up RB core work

== Other business ==

== PTOs, etc ==
* Hal will be off the week after whistler

== Links ==
[https://wiki.mozilla.org/DeveloperServices/Goals-2015Q2 Q2 Goals]

DeveloperServices/TeamMeetings/2015-06-02

2015-06-02T17:56:00Z

Smacleod: /* Last week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** hwine → fubar (Wednesday)
** nothing active

== Stand-up ==
=== Last week ===
* bkero
** Code review + bugfixing for hg.m.o bundle generation
** Python 2.7 for hg.m.o/git.m.o installed. venv work landed, need to get scripts to use it
** Smaller issues: (SVN ACLs for T-bird, ldap perms for private hg.m.o repo)
* fubar
** PTO
* gps
** hg.mozilla.org is now generating and serving bundles from S3
*** http://gregoryszorc.com/blog/2015/05/29/faster-cloning-from-hg.mozilla.org-with-server-provided-bundles/
** Landed rewriting API and changeset id recording to MozReview
** Blogged about MozReview changes from last week: http://gregoryszorc.com/blog/2015/05/29/important-changes-to-mozreview/
** Progress on server for moz.build metadata ({{bug|1168607}})
* hwine
** vcs-sync
** cvs/bzr archiving to ftp
** spring release
* lmandel
** Reviewed SVN information from fubar.
* smacleod
** Productivity sapping Cold + Allergies
** Worked more on the MozReview LDAP querying

=== Planned for this week ===
* bkero
** Transition hgweb heads to using a python2.7-venv mod_wsgi
** Move some 'hg' module Puppet resources to ansible
* fubar
** catch up
** BMO deploy fixes
** DXR/ES, Rust index
* gps
** continue working on moz.build metadata server
*** unblocks auto bug filing and eventually auto reviewer selection
*** ... which is a soft blocker on GitHub integration
** Pulse publishing of GitHub webhooks?
** Mercurial 3.4.1 deployment?
** MozReview Review-URL/workflow enhancements?
* hwine
** vcs-sync
** blog post for cvs
** releng scl3 work planning
* lmandel
** Start following up with people about their SVN repos
* smacleod

== Other business ==

== PTOs, etc ==
* Hal will be off the week after whistler

== Links ==
[https://wiki.mozilla.org/DeveloperServices/Goals-2015Q2 Q2 Goals]

DeveloperServices/TeamMeetings/2015-05-26

2015-05-26T17:35:12Z

Smacleod: /* Planned for this week */

DeveloperServices/TeamMeetings/2015-05-26

2015-05-26T17:34:12Z

Smacleod: /* Last week */

DeveloperServices/Goals-2015Q2

2015-05-19T18:09:00Z

Smacleod: Update MozReview goals

== hg ==
* Advertise and use bundles - build speed improvement
** Create extension to take advantage of bundles (gps)
** Set up build tooling to use the bundles
** Set up infra (cronjob + server + s3 uploading) to produce bundles (bkero)
* Run hgweb out of v-c-t repository (bkero) - Increased portability, testability
* Python 2.7 upgrade (bkero) - general speed improvement and increased upstream testing usefulness

== git ==
* ?

== MozReview ==
* Fix diffs (smacleod)
** Properly show rename / copy / empty files
*** Make RB core properly handle git style diffs
*** Generate git style diffs from MozReview
** Allow display of a deleted files original contents [now unprioritized]
* Allow Review Board to check ldap groups
** Restrict try pushes from MozReview to level 1

DeveloperServices/TeamMeetings/2015-05-19

2015-05-19T18:00:29Z

Smacleod: /* Planned for this week */

DeveloperServices/TeamMeetings/2015-05-19

2015-05-19T17:59:40Z

Smacleod: /* Last week */

DeveloperServices/TeamMeetings/2015-05-12

2015-05-12T17:30:42Z

Smacleod: /* Planned for this week */

DeveloperServices/TeamMeetings/2015-05-12

2015-05-12T17:28:56Z

Smacleod: /* Last week */

DeveloperServices/TeamMeetings/2015-05-05

2015-05-05T17:32:30Z

Smacleod: /* Planned for this week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** hwine → bkero

* {{bug|1161609}} git.m.o operations needing some love
* fyi - scl3 power outage Wed/Thur 2000-2300 PT {{bug|1160608}}

== Stand-up ==
=== Last week ===
* bkero
** Wrote partial hgweb-from-vct host installation playbook
** scan-build + mozreview
* fubar
** started docs refresh
** BMO PHX→AWS planning started
** test VM for docker builds in SCL3; m-c wrangling
** bzr tarballs (hal?)
* gps
* hwine
** some progress on CVS
** lots of interrupts about FF 38.0 (l10n issues)
** power cycle planning
* lmandel
* smacleod
** Finished up git diff support in RB core
** Started on MozReview patches to switch us to new diff support
** Ran some basic usage statistics on MozReview

=== Planned for this week ===
* bkero
** Finish hgweb-from-vct playbook
** mozreview+pulse+bots interaction as prereq to implementing scan-build for gecko patches
* fubar
** docs refresh con't
** SVN data
** docker build testing
* gps
* hwine
** Intern ramp up - welcome Anhad (irc ffledgling)
** vcs-sync
** scl3 power work
* lmandel
* smacleod
** Convert MozReview to new diff support.
** Start giving RB commit author information.
** More RB core work around the diff viewer.
** Write some re-usable scripts for generating better MozReview usage stats.

== Other business ==
* (hwine) Gentle reminder - any maintenance work to any of our systems should be coordinated and pre-announced in #moc. Good habit and builds good will(sm).
* (lmandel) bz identified functionality (CVS attic blame) that we (as in Mozilla) have decommissioned without a replacement. From his comments, a Web based way to access blame would make him more productive. Hal has a thread on the mailing list about get {{bug|1155388}} into the dxr backlog.
* (lmandel) We talked about integrating static analysis in the review process. Sylvestre Ledru and I discussed prototyping scanbuild diff results in MozReview. Would be opt-in and look something like:
** dev requests review from scanbuild
** build with patch(es) created automatically, scanbuild run
** diff from scanbuild results with patches compared against latest m-c build or separate build that does not include patches
** diff posted to MozReview
* (lmandel) Do we have best practices docs for using our tools and, more generally, how to work as a Mozilla dev?
* (lmandel) Interested in giving a talk to our interns? Sign up: https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45125125
* (hwine) With additional task cluster changes, we're starting to see more load & alerts on git.m.o. Seems like a good time to make a tuning push on git.m.o? We have some bug already filed, and the TC team may have input on how their use is ramping.

== PTOs, etc ==

== Links ==
[https://wiki.mozilla.org/DeveloperServices/Goals-2015Q2 Q2 Goals]

DeveloperServices/TeamMeetings/2015-05-05

2015-05-05T17:28:38Z

Smacleod: /* Last week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** hwine → bkero

* {{bug|1161609}} git.m.o operations needing some love
* fyi - scl3 power outage Wed/Thur 2000-2300 PT {{bug|1160608}}

== Stand-up ==
=== Last week ===
* bkero
** Wrote partial hgweb-from-vct host installation playbook
** scan-build + mozreview
* fubar
** started docs refresh
** BMO PHX→AWS planning started
** test VM for docker builds in SCL3; m-c wrangling
** bzr tarballs (hal?)
* gps
* hwine
** some progress on CVS
** lots of interrupts about FF 38.0 (l10n issues)
** power cycle planning
* lmandel
* smacleod
** Finished up git diff support in RB core
** Started on MozReview patches to switch us to new diff support
** Ran some basic usage statistics on MozReview

=== Planned for this week ===
* bkero
** Finish hgweb-from-vct playbook
** mozreview+pulse+bots interaction as prereq to implementing scan-build for gecko patches
* fubar
** docs refresh con't
** SVN data
** docker build testing
* gps
* hwine
** Intern ramp up - welcome Anhad (irc ffledgling)
** vcs-sync
** scl3 power work
* lmandel
* smacleod

== Other business ==
* (hwine) Gentle reminder - any maintenance work to any of our systems should be coordinated and pre-announced in #moc. Good habit and builds good will(sm).
* (lmandel) bz identified functionality (CVS attic blame) that we (as in Mozilla) have decommissioned without a replacement. From his comments, a Web based way to access blame would make him more productive. Hal has a thread on the mailing list about get {{bug|1155388}} into the dxr backlog.
* (lmandel) We talked about integrating static analysis in the review process. Sylvestre Ledru and I discussed prototyping scanbuild diff results in MozReview. Would be opt-in and look something like:
** dev requests review from scanbuild
** build with patch(es) created automatically, scanbuild run
** diff from scanbuild results with patches compared against latest m-c build or separate build that does not include patches
** diff posted to MozReview
* (lmandel) Do we have best practices docs for using our tools and, more generally, how to work as a Mozilla dev?
* (lmandel) Interested in giving a talk to our interns? Sign up: https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=45125125
* (hwine) With additional task cluster changes, we're starting to see more load & alerts on git.m.o. Seems like a good time to make a tuning push on git.m.o? We have some bug already filed, and the TC team may have input on how their use is ramping.

== PTOs, etc ==

== Links ==
[https://wiki.mozilla.org/DeveloperServices/Goals-2015Q2 Q2 Goals]

DeveloperServices/TeamMeetings/2015-04-28

2015-04-28T18:01:17Z

Smacleod: /* Planned for this week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** fubar → hwine

== Stand-up ==
=== Last week ===
* bkero
** Run hgweb out of v-c-t repository
** At Linuxfest Northwest conference
* fubar
** DXR docker build container
* gps
** RelEng mini work week in PDX
** Ansible playbooks for hg.mo deployments
*** Deploying extensions and hooks
*** Re-cloning repos on hgweb nodes
*** Wrote an Ansible module for manipulating Stingray load balancer state
** Ansible playbook for deploying MozReview to production
** Churned through review backlog
** hg.mozilla.org now displays the revision of version-control-tools it was deployed from
** Review and deploy {{bug|1157547}} so bug number regexps are better
** Due diligence for Mercurial 3.4
*** Reported a few performance regressions
*** Sent a few small patches to upstream
** Starting re-cloning repositories on hgweb nodes so repository store is up to date
*** Discovered time bomb when syncing hgrc files referencing newer hooks.
*** Need to kill library_overrides ({{bug|1159099}})
** Patched `mach mercurial-setup` for compatibility with next release of MozillaBuild
** Aided RyanVM with Mercurial packaging for next MozillaBuild

* hwine
** releng work week
** sick
* lmandel
** catchup
** lots of random discussions about quality, Win64, vendors in Whistler, other Whistler planning, more deliverables stuff, ...
* smacleod
** Kept working on fixing diffs in RB
*** Spoke with core RB about diff changes, needed to restructure things a bit
*** Turned out RB git parser was slightly broken needed to fix to make hg git diff parsing work

=== Planned for this week ===
* bkero
** Finish hgweb out of v-c-t repository, start testing
* fubar
** DXR
*** docker tweaks, look at jenkins for scheduling builds
*** possibly spin up SCL3 env for builds, web?
* gps
* hwine
** vcs-sync
** cvs final bits
** releng 38.0 beta
* lmandel
** back to svn decom plan (hopefully)
** reviewing team wiki/docs
** goals cleanup
* smacleod
** Get RB diff stuff up for review ASAP (I'd appreciate if gps did a skim review of the RB core changes as well).
** Track down a few MozReview bugs
** Start on empty file toggle work

== Other business ==
* (lmandel) Decommissioning bzr
** Can someone volunteer to create a tarball of the Bugzilla repo (any other repos that need them) that we can upload to ftp?
** Who can help decommission the server when we're ready?
* (lmandel) Whistler planning
** What does our team want to accomplish? (What is our goal?)
** education
*** session for platform/all about how to develop more efficiently (build and hg best practices)
** Q3 planning with other teams (releng)?

== PTOs, etc ==
* bkero pto Friday

== Links ==
[https://wiki.mozilla.org/Platform/2015-Q1-Goals Goals]

DeveloperServices/TeamMeetings/2015-04-28

2015-04-28T17:58:18Z

Smacleod: /* Last week */

[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|« previous meeting]] —
[[DeveloperServices/TeamMeetings|index]] –
[[DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week »]]
[https://wiki.mozilla.org/index.php?title=DeveloperServices/TeamMeetings/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}&action=edit&redlink=1&preload=DeveloperServices/TeamMeetings/Template create?]


== Meeting Info ==
* 11 am Pacific Time
* Vidyo room: DeveloperServices
* Backchannel in #vcs

== Hot items ==
* On Call Handoff!!!
** fubar → hwine

== Stand-up ==
=== Last week ===
* bkero
** Run hgweb out of v-c-t repository
** At Linuxfest Northwest conference
* fubar
** DXR docker build container
* gps
** RelEng mini work week in PDX
** Ansible playbooks for hg.mo deployments
*** Deploying extensions and hooks
*** Re-cloning repos on hgweb nodes
*** Wrote an Ansible module for manipulating Stingray load balancer state
** Ansible playbook for deploying MozReview to production
** Churned through review backlog
** hg.mozilla.org now displays the revision of version-control-tools it was deployed from
** Review and deploy {{bug|1157547}} so bug number regexps are better
** Due diligence for Mercurial 3.4
*** Reported a few performance regressions
*** Sent a few small patches to upstream
** Starting re-cloning repositories on hgweb nodes so repository store is up to date
*** Discovered time bomb when syncing hgrc files referencing newer hooks.
*** Need to kill library_overrides ({{bug|1159099}})
** Patched `mach mercurial-setup` for compatibility with next release of MozillaBuild
** Aided RyanVM with Mercurial packaging for next MozillaBuild

* hwine
** releng work week
** sick
* lmandel
** catchup
** lots of random discussions about quality, Win64, vendors in Whistler, other Whistler planning, more deliverables stuff, ...
* smacleod
** Kept working on fixing diffs in RB
*** Spoke with core RB about diff changes, needed to restructure things a bit
*** Turned out RB git parser was slightly broken needed to fix to make hg git diff parsing work

=== Planned for this week ===
* bkero
** Finish hgweb out of v-c-t repository, start testing
* fubar
** DXR
*** docker tweaks, look at jenkins for scheduling builds
*** possibly spin up SCL3 env for builds, web?
* gps
* hwine
** vcs-sync
** cvs final bits
** releng 38.0 beta
* lmandel
* smacleod

== Other business ==
* (lmandel) Decommissioning bzr
** Can someone volunteer to create a tarball of the Bugzilla repo (any other repos that need them) that we can upload to ftp?
** Who can help decommission the server when we're ready?

== PTOs, etc ==
* bkero pto Friday

== Links ==
[https://wiki.mozilla.org/Platform/2015-Q1-Goals Goals]

DeveloperServices/TeamMeetings/2015-04-21

2015-04-21T18:00:05Z

Smacleod: /* Last week */

DeveloperServices/TeamMeetings/2015-04-21

2015-04-21T17:58:14Z

Smacleod: /* Planned for this week */

DeveloperServices/TeamMeetings/2015-04-21

2015-04-21T17:57:06Z

Smacleod: /* Last week */

DeveloperServices/Goals-2015Q2

2015-04-21T17:29:16Z

Smacleod: Add some MozReview Goals

DeveloperServices/TeamMeetings/2015-04-14

2015-04-14T18:11:30Z

Smacleod: add smacleod's next week

Firefox/Meeting/3-Dec-2013

2013-12-03T17:23:00Z

Smacleod: /* SessionStore */

== Details ==

* Tuesdays - 10:00am Pacific, 1:00pm Eastern, 17:00 UTC
* [http://arewemeetingyet.com/Los%20Angeles/2013-08-20/10:00/w/Firefox%20development%20meeting Handy local meeting time link]
{{conf|91337}}
* irc.mozilla.org #fx-team for backchannel
* "Firefox" Vidyo Room

== General Topics ==
== Friends of the Firefox team ==
''Give a shoutout/thanks to people for helping fix and test bugs.''
== Project Updates ==
===Australis===
===Thumbnailing===
===SessionStore===
* Cleanup old session store data ({{bug|943352}}, [https://groups.google.com/d/msg/mozilla.dev.platform/NTMU6_rqTes/bavoDxTiTsIJ Mailing List RFC])
* Scroll position regression ({{bug|921942}})
* Removal of write on startup waiting to land ({{bug|887780}})
* Introducing more Telemetry to Session store ({{bug|942063}})
* Don't save history for dynamically generated iframes ({{bug|936271}})
* E10s work for restore path ({{bug|942374}})
* Work on a number of intermittent tests ({{bug|942513}}, {{bug|942622}}, {{bug|919060}}, {{bug|942673}}, {{bug|942512}})
* Q4 Session Store Goals Meeting notes: [https://etherpad.mozilla.org/OmgSov5RZC Etherpad]

===Places API asyncification===
===Social API===
===e10s===
=== UX Updates ===
=== QA ===

==Stand ups==
Suggested format:
* What did you do last week?
* What are working on this week?
* Anything blocking you?
Please keep your update to under 1 minute!

===gavin===
(gavin's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/gavin%40gavinsharp.com Status Board])

===paolo===
(paolo's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/pamadini%40mozilla.com Status Board])

===mak===
(marco's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mak%40mozilla.com Status Board])

===enn===
(Neil's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/enndeakin%40gmail.com Status Board])

===felipe===
(felipe's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/felipc%40gmail.com Status Board])

===mano===
(Mano's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mano%40mozilla.com Status Board])

===ttaubert===
(Tim's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/ttaubert%40mozilla.com Status Board])

===adw===
(Drew's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/adw%40mozilla.com Status Board])

===markh===
(Mark's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mhammond%40mozilla.com Status Board])

===smacleod===
(Steven's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/smacleod%40mozilla.com Status Board])

===dolske===
(dolske's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/dolske%40mozilla.com Status Board])

===mconley===
(Mike's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mconley%40mozilla.com Status Board])

===dao===

===mikedeboer===
(Mike's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mdeboer%40mozilla.com Status Board])

===gijs===
(gijs' [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/gijs%40mozilla.com Status Board])

===Unfocused===
(Blair's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/bmcbride%40mozilla.com Status Board])

===MattN===
(MattN's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mozilla%40noorenberghe.ca Status Board])

===jaws===
(jaws's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/jaws%40mozilla.com Status Board])

===mixedpuppy===
(mixedpuppy's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/scaraveo%40mozilla.com Status Board])

Firefox/Meeting/19-Nov-2013

2013-11-19T17:05:36Z

Smacleod: /* SessionStore */

== Details ==

* Tuesdays - 10:00am Pacific, 1:00pm Eastern, 17:00 UTC
* [http://arewemeetingyet.com/Los%20Angeles/2013-08-20/10:00/w/Firefox%20development%20meeting Handy local meeting time link]
{{conf|91337}}
* irc.mozilla.org #fx-team for backchannel
* "Firefox" Vidyo Room

== General Topics ==
== Friends of the Firefox team ==
''Give a shoutout/thanks to people for helping fix and test bugs.''
== Project Updates ==
===Australis===
===Thumbnailing===
===SessionStore===
* Removal of Synchronous initialization path landing ({{bug|918024}})
* API for storing global session data landed ({{bug|899213}})
* Broadcasting of tab data as it changes instead of collecting it is close to landing ({{bug|930967}})
* billm landed a number of code cleanups ({{bug|930269}})
* Investigation into problematic websites greatly increasing the size of the session ({{bug|934934}}, {{bug|936271}})

===Places API asyncification===
===Social API===
===e10s===
=== UX Updates ===
=== QA ===

==Stand ups==
Suggested format:
* What did you do last week?
* What are working on this week?
* Anything blocking you?
Please keep your update to under 1 minute!

===gavin===
(gavin's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/gavin%40gavinsharp.com Status Board])

===paolo===
(paolo's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/pamadini%40mozilla.com Status Board])

===mak===
(marco's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mak%40mozilla.com Status Board])

===enn===
(Neil's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/enndeakin%40gmail.com Status Board])

===felipe===
(felipe's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/felipc%40gmail.com Status Board])

===mano===
(Mano's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mano%40mozilla.com Status Board])

===ttaubert===
(Tim's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/ttaubert%40mozilla.com Status Board])

===adw===
(Drew's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/adw%40mozilla.com Status Board])

===markh===
(Mark's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mhammond%40mozilla.com Status Board])

===smacleod===
(Steven's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/smacleod%40mozilla.com Status Board])

===dolske===
(dolske's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/dolske%40mozilla.com Status Board])

===mconley===
(Mike's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mconley%40mozilla.com Status Board])

===dao===

===mikedeboer===
(Mike's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mdeboer%40mozilla.com Status Board])

===gijs===
(gijs' [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/gijs%40mozilla.com Status Board])

===Unfocused===
(Blair's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/bmcbride%40mozilla.com Status Board])

===MattN===
(MattN's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mozilla%40noorenberghe.ca Status Board])

===jaws===
(jaws's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/jaws%40mozilla.com Status Board])

===mixedpuppy===
(mixedpuppy's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/scaraveo%40mozilla.com Status Board])

Firefox/Meeting/15-Oct-2013

2013-10-15T15:53:18Z

Smacleod: /* SessionStore */

== Details ==

* Tuesdays - 10:00am Pacific, 1:00pm Eastern, 17:00 UTC
* [http://arewemeetingyet.com/Los%20Angeles/2013-08-20/10:00/w/Firefox%20development%20meeting Handy local meeting time link]
{{conf|91337}}
* irc.mozilla.org #fx-team for backchannel
* "Firefox" Vidyo Room

== General Topics ==
== Friends of the Firefox team ==
''Give a shoutout/thanks to people for helping fix and test bugs.''
== Project Updates ==
===Australis===
===Downloads API===
===Thumbnailing===
===SessionStore===
* A few code cleanups ({{bug|923034}}, {{bug|923854}}).
* Fix a rather rare regression for windows quickly opened at startup ({{bug|900910}}).
* Fixing lost windows due to ID collisions ({{bug|925771}}).
* Ensure write instructions after shutdown will be prevented ({{bug|922785}}, {{bug|922814}})
* Remove synchronous startup code ({{bug|918024}}).
* Still working to get rid of saving state right after startup ({{bug|887780}}, {{bug|921581}}).
* Marionette tests for startup path are coming along
* Work to collect more data in content scripts to be e10s friendly ({{bug|909048}}, {{bug|910668}}, {{bug|919835}}).

===Places API asyncification===
===Social API===
===e10s===
=== UX Updates ===

==Stand ups==
Suggested format:
* What did you do last week?
* What are working on this week?
* Anything blocking you?
Please keep your update to under 1 minute!

===gavin===
(gavin's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/gavin%40gavinsharp.com Status Board])

===paolo===
(paolo's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/pamadini%40mozilla.com Status Board])

===mak===
(marco's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mak%40mozilla.com Status Board])

===enn===
(Neil's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/enndeakin%40gmail.com Status Board])

===felipe===
(felipe's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/felipc%40gmail.com Status Board])

===mano===
(Mano's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mano%40mozilla.com Status Board])

===ttaubert===
(Tim's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/ttaubert%40mozilla.com Status Board])

===adw===
(Drew's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/adw%40mozilla.com Status Board])

===markh===
(Mark's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mhammond%40mozilla.com Status Board])

===smacleod===
(Steven's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/smacleod%40mozilla.com Status Board])

===dolske===
(dolske's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/dolske%40mozilla.com Status Board])

===mconley===
(Mike's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mconley%40mozilla.com Status Board])

===dao===

===mikedeboer===
(Mike's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mdeboer%40mozilla.com Status Board])

===gijs===
(gijs' [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/gijs%40mozilla.com Status Board])

===Unfocused===
(Blair's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/bmcbride%40mozilla.com Status Board])

===MattN===
(MattN's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mozilla%40noorenberghe.ca Status Board])

===jaws===
(jaws's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/jaws%40mozilla.com Status Board])

===mixedpuppy===
(mixedpuppy's [http://benjamin.smedbergs.us/weekly-updates.fcgi/user/scaraveo%40mozilla.com Status Board])