# Merge Team Call - ... - 2020-07-06

Where: Mumble

- Newer meetings:
- 2020-07-13 to 2021-03-08: https://hackmd.io/-KERABhGQLOgHi1LPeq5Ng
- 2021-03-15 - ...: https://hackmd.io/r9WOQntNR7iyVwn97q-QYw

## 2020-07-06

- Assign a new merge master for the week - Arvid
- Assign MRs to reviewers after this call or tomorrow
- Assign MRs to reviewers as they come in
- Add controversial MRs to be discussed to next Monday's agenda throughout the week
- GitLab MR templates
- https://docs.gitlab.com/ee/user/project/description_templates.html
- Reproducible benchmarks
- Tarides has worked on this
- Maybe we can pick this back up
- Arvid: discuss testing guidelines for merge requests
- Should we respond to this?
- https://forum.tezosagora.org/t/smart-contract-vulnerabilities-due-to-tezos-message-passing-architecture/2045
- Maybe out of scope of this call, but I was approached by a community member about it
- Reply on Agora, also update the documentation
- Long discussion around the historic context for the design
- Add more examples to the docs that show contract interaction
- Operation receipts
- https://gitlab.com/metastatedev/tezos/-/merge_requests/225

## 2020-06-29 - Party Time
- Should we set this up?
- In rotation: Adrian, Arvid, Klakplok, Mehdi, Raphaël C., Raphaël P., Seb, Sylvain, Tomáš, Vbot, Pirbo, Romain
- I don't mind volunteering for next week
- MRs
- https://gitlab.com/tezos/tezos/-/merge_requests/1936
- Reviewers
- Adrian
- Arvid
- https://gitlab.com/tezos/tezos/-/merge_requests/1905
- https://gitlab.com/tezos/tezos/-/merge_requests/1929
- https://gitlab.com/tezos/tezos/-/merge_requests/1907
- wait for license, then merge and respond to complaints if out-of-sync
- https://gitlab.com/tezos/tezos/-/merge_requests/1512
- needs migration documentation for existing nodes
- ignore the MR description
- https://gitlab.com/tezos/tezos/-/merge_requests/1848 (merged)
- Arvid to close his thread and then merge it
- https://gitlab.com/tezos/tezos/-/merge_requests/1881
- to be merged next

## 2002-06-22 - No party
- 81 open MRs at the start (below are supporde to be merged)
- https://gitlab.com/tezos/tezos/-/merge_requests/1925 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1917 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1916 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1835 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1904 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1790 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1894 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1821 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1909 - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1821 - merged
- Needs approval
- https://gitlab.com/tezos/tezos/-/merge_requests/1881
- Needs to be rebased manually (only thing blocking merge)
- https://gitlab.com/tezos/tezos/-/merge_requests/1913
- https://gitlab.com/tezos/tezos/-/merge_requests/1642
- https://gitlab.com/tezos/tezos/-/merge_requests/1770

- notes about changes we made to the CI to make the release process faster
- disable CI (test and docs) unless needed
- discussion around Lwt and Option
- any question about Tezt?
- simpler test framework than flextesa
- users can listen for events instead of polling
- https://gitlab.com/tezos/tezos/-/merge_requests/1881
- how to make it so that we don't discover MRs during merge team calls?
- need to propose MRs before the meeting
- discuss problematic MRs in the meeting
- can't avoid assigning MRs and having someone triaging MRs
- randomly assign MRs
- Action Items
- Put problematic MR on agenda by Friday to be discussed on Monday

## 2002-06-15 - Merge party
- Started with 82 open MRs -> finished with 72
- Approved
- https://gitlab.com/tezos/tezos/-/merge_requests/1876 (lint.sh) - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1869 (client, multisig) - merged
- Raphael reviewed and tested and Seb tested it partially
- https://gitlab.com/tezos/tezos/-/merge_requests/1848 (pre-commit hook) - postponed
- Needs to make sure that git runs in porcelane mode
- https://gitlab.com/tezos/tezos/-/merge_requests/1862 (PATH for Rust) - merged
- https://gitlab.com/tezos/tezos/-/merge_requests/1488 (`--rpc`) - closed
- Go through the MRs and close ones that can be closed
- https://gitlab.com/tezos/tezos/-/merge_requests/1450
- Arvid to ping Paul
- This is useful and we would like it :-)
- https://gitlab.com/tezos/tezos/-/merge_requests/1621
- Raphael C. to assign it to Victor
- Spend the rest of the time reviewing MRs as a group
- Ready to be reviewed
- https://gitlab.com/tezos/tezos/-/merge_requests/1512
- Needs a rebase first
- Group review
- https://gitlab.com/tezos/tezos/-/merge_requests/1245 - needs more tests
- https://gitlab.com/tezos/tezos/-/merge_requests/1888 - after 1883
- https://gitlab.com/tezos/tezos/-/merge_requests/1883 - merged next
- https://gitlab.com/tezos/tezos/-/merge_requests/1835 - to be looked at next time
- https://gitlab.com/tezos/tezos/-/merge_requests/1849
- To Review At Home with nice water
- https://gitlab.com/tezos/tezos/-/merge_requests/1880 - Lwt exit
- https://gitlab.com/tezos/tezos/-/merge_requests/1770 - Recursive errors
- https://gitlab.com/tezos/tezos/-/merge_requests/1872

### Tooling MRs
- https://gitlab.com/tezos/tezos/-/merge_requests/1390

### List of MRs for tech writers
- https://gitlab.com/tezos/tezos/-/merge_requests/1621

## 2002-06-08 - No party

* Testing
- https://gitlab.com/tezos/tezos/-/merge_requests/1404 : test coverage in CI -> Ok to merge.
* Benchmark
- https://gitlab.com/nomadic-labs/tezos/-/issues/169 : should we merge benchmark tools into master? (in the issue replace proto-proposal by master)
- We should merge
* Shell
- https://gitlab.com/tezos/tezos/-/merge_requests/1705 : Shell: Purge legacy logging in node -> fix pp_first_error_message, then merge.
- https://gitlab.com/tezos/tezos/-/merge_requests/1430 : communicate with external validator over socket
- mergeable and we are fine with it
- Seb reviewed the flextesa part
* Nomadic-side test of the new version of the Ledger Wallet App?
https://github.com/obsidiansystems/ledger-app-tezos/releases/tag/v2.2.7
* https://gitlab.com/tezos/tezos/-/merge_requests/1820 - merged
* is optional, but let's advertise the option for this one
* https://gitlab.com/tezos/tezos/-/merge_requests/1853/ - merge in order
* https://gitlab.com/tezos/tezos/-/merge_requests/1854 - needs rebasing and then merging
* https://gitlab.com/tezos/tezos/-/merge_requests/1770
* discussion on MR and in call

## 2020-05-25 - Merge party

* https://gitlab.com/tezos/tezos/-/merge_requests/1715 : remove legacy logging in shell
* https://gitlab.com/tezos/tezos/-/merge_requests/1430 : communicate with external validator over socket

## 2020-05-25 - No Party
* https://gitlab.com/tezos/tezos/-/merge_requests/1804 : some improvements for `Error_monad`, prelude to https://gitlab.com/cryptiumlabs/tezos/-/merge_requests/165 and https://gitlab.com/tezos/tezos/-/merge_requests/1837. This is in preparation for work that affects the protocol environment.
* Mehdi's LWT war: https://gitlab.com/cryptiumlabs/tezos/-/issues/155
* Once EnvironmentV1 gets accepted we can strip V0 to only contain the used functions, because some functions may have not been used at all`
* upcoming changes soon: shadowing `List`, `Map`, `St` with error-aware versions. These changes are relatively simple (shallow) but cover a lot of code (wide) which makes rebasing annoying. How to make this painless for the merge-team and the coders? (Raphaël and Mehdi)
* To be done during a merge party so that we don't need to rebase: Once the preliminary work is done (perliminary MRs merged), Raphaël will prepare the MR that does the swap and then we can get the whole of the merge team to parallel review chunks of the MR and we can do the merge there and then
* https://gitlab.com/tezos/tezos/-/merge_requests/1835#note_346315494
* new circular dependency: protocol-demo
* is the whole thing worth having? or at least tests in opam?
* master docker images are not working

## 2020-05-18 — Merge Party
* approved and not yet merged
* https://gitlab.com/tezos/tezos/-/merge_requests?label_name%5B%5D=approved
* merge from top to bottom:
* https://gitlab.com/tezos/tezos/-/merge_requests/1819 (needed for 7.1) (merged)
* https://gitlab.com/tezos/tezos/-/merge_requests/1482 (merged)
* https://gitlab.com/tezos/tezos/-/merge_requests/1746 (merged)
* mergeable after rebase:
* https://gitlab.com/tezos/tezos/-/merge_requests/1818 (merged)
* https://gitlab.com/tezos/tezos/-/merge_requests/1759 (merged)
* https://gitlab.com/tezos/tezos/-/merge_requests/1373
* Pierre does it
* Add a quick note to the changelog about this
* ready for review:
* https://gitlab.com/tezos/tezos/-/merge_requests/1820
* Comments: https://gitlab.com/tezos/tezos/-/merge_requests/1820#note_344457567
* https://gitlab.com/tezos/tezos/-/merge_requests/1770
* also test `rpc get /errors`
* review next week:
* https://gitlab.com/tezos/tezos/-/merge_requests/1620
* RPC discussion
* two layers of RPC, dangerous (can cause a fork, lose funds, gets slashed) and unsafe (can be DoSed)
* provide an ngix file that makes the unsafe RPC safe to be exposed publicly

## 2020-05-11
* New store:
* worked on FreeBSD (lmbd mutex doesn't)
* worked with `9p` filesystem (minikube, no `mmap`)
* Upgrade of Lwt (to use `pread` and `pwrite`): should be ready to go through.
* upcoming changes soon: shadowing `List`, `Map`, `St` with error-aware versions. These changes are relatively simple (shallow) but cover a lot of code (wide) which makes rebasing annoying. How to make this painless for the merge-team and the coders? (Raphaël and Mehdi)
* Wait for Raphael P's input
* OCaml 2020: Talk [proposal](https://discuss.ocaml.org/t/ocaml-users-and-developers-meeting-2020/) submission deadline: May 29th, 2020, AoE → Anyone?
* Bindings to hacl post mortem + new version
* **Client-error messages:** we need a fake node that answers wrong garbage on the RPC to check the client's error messages
* https://gitlab.com/tezos/tezos/-/merge_requests/1456#note_336661091
* To merge in this order:
* https://gitlab.com/tezos/tezos/-/merge_requests/1800 - merged
* https://gitlab.com/tezos/tezos/-/merge_requests/1456 - merged
* https://gitlab.com/tezos/tezos/-/merge_requests/1806 - merged
* https://gitlab.com/tezos/tezos/-/merge_requests/1785 - merged
* https://gitlab.com/tezos/tezos/-/merge_requests/1795 - merged
* https://gitlab.com/tezos/tezos/-/merge_requests/1248 - merged

## 2020-05-04 - Merge Party
* https://gitlab.com/tezos/tezos/-/merge_requests/1108
* Add a new port for a public RPC port - 7732

From #devteam:
* https://gitlab.com/tezos/tezos/-/merge_requests/1659 (python tests, need by storage devs) => **to merge**
* https://gitlab.com/tezos/tezos/-/merge_requests/1685 => **assigned**
* https://gitlab.com/tezos/tezos/-/merge_requests/1551 (P2P, simple renaming) => **fix doc**
* Mockup client:
* https://gitlab.com/tezos/tezos/-/merge_requests/1720 -> Raphael to do the final review and merge
* https://gitlab.com/tezos/tezos/-/merge_requests/1760 -> Adrian to do the final review and merge, depends on 1720
* https://gitlab.com/tezos/tezos/-/merge_requests/1746
* https://gitlab.com/tezos/tezos/-/merge_requests/1714
* https://gitlab.com/tezos/tezos/-/merge_requests/1736 -> CLOSED
* https://gitlab.com/tezos/tezos/-/merge_requests/1336 -> Merged after pipeline
* https://gitlab.com/tezos/tezos/-/merge_requests/1761 -> Merge and rebase after 1336m
* https://gitlab.com/tezos/tezos/-/merge_requests/1248

## 2020-04-27
* RFCs
* https://gitlab.com/tezos/tezos/-/merge_requests/1721
* Host it under tezos.gitlab.io
* Sources to be put under tezos/tezos
* https://gitlab.com/nomadic-labs/michelson-reference/-/issues/29
* https://gitlab.com/tezos/tezos/-/merge_requests/1702
* wait for approvals to check for stupid stuff
* then merge, if anything breaks in the next months remember to check this MR
* possibly add shellcheck into the ci as an optional step (https://gitlab.com/tezos/tezos/-/issues/781)
* https://gitlab.com/tezos/tezos/-/merge_requests/1472
* Python Test Framework
* accept it or close it, opinion of PhilippeB ?
* https://gitlab.com/tezos/tezos/-/merge_requests/1711
* 🕰 wait for response to Mehdi's comments
* Do we want to release the framework as a standalone library that users could use?
* Discussion on Slack: https://tezos-dev.slack.com/archives/C85U11HGD/p1587121267165000
* https://gitlab.com/tezos/tezos/-/merge_requests/1472
* Change it in 2 months after 007 is out
* Still unclear whether we want to even move it into vendors
* What do we gain from moving it from tests_python to vendors?
* Moving it doesn't help with packaging it on opam
* Adrian
* Maybe it makes sense to release the python framework as a standalone framework so that the rust shell people can use it
* I think it's low priority though, they haven't indicated any interest
* The integration tests should not move into vendors/ since they aren't an external library
* https://gitlab.com/tezos/tezos/-/merge_requests/992
* only releases get shipped to opam
* master does not get released to opam
* if you want latest master, vendor it

## 2020-04-20
* Merge Party
* Mergeable
* https://gitlab.com/tezos/tezos/-/merge_requests/1767 ✓
* https://gitlab.com/tezos/tezos/-/merge_requests/1763 ✓
* https://gitlab.com/tezos/tezos/-/merge_requests/1755 🕰
* looks decent, but we need to make sure that forking the repo still works without problems
* I'm not sure how gitlab ci is supposed to handle forks given different tags
* Pierre to write his concerns in the MR
* https://gitlab.com/tezos/tezos/-/merge_requests/1713 ✓
* https://gitlab.com/tezos/tezos/-/merge_requests/1753 ✓
* Almost mergeable (Needs reviews/opinions, fast)
* https://gitlab.com/tezos/tezos/-/merge_requests/1762
* Needs split proto/non-proto
* https://gitlab.com/tezos/tezos/-/merge_requests/1758 🕰
* rafoo: as noted by Mehdi, this adds a strange dependency from lib_test_services to proto_alpha/lib_client
* https://gitlab.com/tezos/tezos/-/merge_requests/1752 ✓
* Oldies but goodies
* https://gitlab.com/tezos/tezos/-/merge_requests/1519
* good to go, but needs a thorough review from someone on the merge team
* https://gitlab.com/tezos/tezos/-/merge_requests/1373
* Mempool/P2p team is working on it
* Currently blocked:
* specification for current behaviour to understand whether this is an improvement or breaking something
* https://gitlab.com/tezos/tezos/-/merge_requests/1404
* https://gitlab.com/tezos/tezos/-/merge_requests/1248
* good to go, but needs a thorough review from someone on the merge team
* Vincent & Romain to review it
* Caboose = lowest known block in rolling mode
* Let's call the head the locomotive
* In full and archive mode the caboose is equivalent to genesisi
* https://gitlab.com/tezos/tezos/-/merge_requests/1489
* wasn't this relevant for the release?
* no, not relevant to the release
* we want the commit hash
* Versioning
* Need the ability to know the versions for
* P2P
* Commit hash
* Node version
* Code coverage reports
* We want coverage reports for our internal use
* Doubtful whether it is useful to have a public website with the latest code coverage
* Use something like coverals in order to get a badge in the readme.md
* https://github.com/aantron/bisect_ppx#Coveralls
* CI questions
* all tests are run in portable ci steps
* things like publishing docs, building docker images, ... are done in independent jobs and aren't run on forks
* Python Test Framework
* accept it or close it, opinion of PhilippeB ?
* https://gitlab.com/tezos/tezos/-/merge_requests/1711
* 🕰 wait for response to Mehdi's comments
* Do we want to release the framework as a standalone library that users could use?
* Discussion on Slack: https://tezos-dev.slack.com/archives/C85U11HGD/p1587121267165000
* https://gitlab.com/tezos/tezos/-/merge_requests/1472
* Change it in 2 months after 007 is out
* Still unclear whether we want to even move it into vendors
* What do we gain from moving it from tests_python to vendors?
* Moving it doesn't help with packaging it on opam
* Adrian
* Maybe it makes sense to release the python framework as a standalone framework so that the rust shell people can use it
* I think it's low priority though, they haven't indicated any interest
* The integration tests should not move into vendors/ since they aren't an external library
* Release to opam
* it works
* shall we release a release candidate
* How long are we keeping the release candidate before calling it an official release?
* 2 weeks without finding a bug and with the ability to sync it
* Are we testing the release candidate
* update the carthagenet nodes to the latest RC
* Romain and Adrian will upgrade their Carthagenet nodes
* everyone should test it at home
* Benjamin and Pierre run it on their baker

## 2020-04-14
* missing for release (https://gitlab.com/tezos/tezos/-/issues/741):
* bootstrap heuristic (still WIP)
* https://gitlab.com/tezos/tezos/-/merge_requests/1373
* What is needed in order to make this mergeable?
* Current problem
* sometimes you're considering yourself bootstrapped when you are not
* the new problem could be that you are bootstrapped but you aren't considering yourself
* do we really need this for the release?
* it seems that we don't
* opam install with ledger support
* not blocking the release
* we are fully ready, it's an optional dependency
* `--network` flag is only a check (https://gitlab.com/tezos/tezos/-/merge_requests/1731)
* please proof read and then merge
* let's release now!
* create an MR against opam with a release candidate to check that the ci works
* then create a final release
* rust toolchain
* Not sure what to do here yet, since we are adding rust for the first time
* Currently both libraries (BLS, Sapling) require two separate versions of Rust
* have an MR to install the rust toolchain in `make build-deps`
* go through MRs?
* please don't resolve converations yourself, but rather ping the asker to resolve it - make public announcement on #devteam
* puts the MRs into a weird state where it's not clear what should happen next
* https://gitlab.com/tezos/tezos/-/merge_requests/1747/ - mergeable
* Logging - https://gitlab.com/tezos/tezos/-/issues/721
* https://gitlab.com/tezos/tezos/-/merge_requests/1740
* https://gitlab.com/tezos/tezos/-/merge_requests/1508 - mergeable
* 0x05 Ledger signing is in the works by Obsidian
* TQ is dealing with it

## 2020-04-06 - Merges & Beers
* discuss the next release of the node
* Release-related merge requests are listed here: https://gitlab.com/tezos/tezos/-/issues/741
* https://gitlab.com/tezos/tezos/-/merge_requests/1709
* requires release of bip39
* https://gitlab.com/tezos/tezos/-/merge_requests/1719
* https://gitlab.com/tezos/tezos/-/merge_requests/1718
* https://gitlab.com/tezos/tezos/-/merge_requests/1723
* needs bootstrap heuristic fix
* release not this week
* testchain needs to be more separated from the mainchain
* bakers need to enable testchain with the cli flag
* other MRs
* https://gitlab.com/tezos/tezos/-/merge_requests/1691
* https://gitlab.com/tezos/tezos/-/merge_requests/1694
* the issue is meta: `make all` will become more costly
* https://gitlab.com/tezos/tezos/-/merge_requests/1699
* the legacy loggings - https://gitlab.com/tezos/tezos/-/issues/721
* comment on the MRs in the issue
* multipass prerequirements:
* https://gitlab.com/tezos/tezos/-/merge_requests/1655
* https://gitlab.com/tezos/tezos/-/merge_requests/1683
* https://gitlab.com/tezos/tezos/-/merge_requests/1701
* Rename P2P network name in future testnet releases
* tezos_alphanet_dunquerke -> tezos_testnet_dunquerke
* merge these in order
1. https://gitlab.com/tezos/tezos/-/merge_requests/1709
2. https://gitlab.com/tezos/tezos/-/merge_requests/1719
3. https://gitlab.com/tezos/tezos/-/merge_requests/1718
4. https://gitlab.com/tezos/tezos/-/merge_requests/1691
5. https://gitlab.com/tezos/tezos/-/merge_requests/1694
6. https://gitlab.com/tezos/tezos/-/merge_requests/1699

## 2020-03-30
* merge party next week and all weeks from 3 to 5 PM CEST
* status of the release
* Docker
* adapt alphanet.sh to the multinetwork node by adding --network $name-of-the-script
* Teztool
* not for this release, should be announced first
* opam install tezos-client
* (small discussion around !1689 : opam dependencies cleanup (or the minimized !1695)
* merge the tiny vendored libraries (bip39, ...) into lib_crypto or lib_client_base
* coq-of-caml changes

## 2020-03-23
* Cf. Romain's [Release](https://hackmd.io/kp6aWzk2SG6Zmr7t8gsmpw) document.

## 2020-03-16
* soft freeze (no extra dependencies!) until we release a multi-network version ?
* missing pieces for that are
* externalizing resto
* sorting out stuff aroung genesis of the different protocols
* keep all the environment updates in proto-proposal
* mostly the rust stuff
* how are we dealing with adding rust dependencies in future releases?
* Release of binaries / Debian packaging
* may require 4.08.1 since it's currently the supported version by Debian/Ubuntu
* build a static image with all dependencies
* piping a shell script into bash will only happen over Benjamin's dead body
* have a version that builds without the ledger library
* ocaml 4.09.0 points
* how are we dealing with old functionality for v0
* naming around v0 and v1
* proto_alpha: delete or merge Carthage?
* https://gitlab.com/tezos/tezos/-/issues/732
* https://gitlab.com/tezos/tezos/-/issues/729
* next merge party on the 23/03/2020 at 17:00 - 19:00?

## 2020-03-09
* it's merge party time
* we merged 15 MRs

## 2020-03-02
* Update on environment V2
* Upgrade to ocaml.4.10.0 (or ocaml.4.09.0) (or ocaml.4.08.0)
* Can't use Lwt.5 because of a long story that Pierre will tell you over a drink
* Someone needs to work on updating Lwt to Lwt.5.0.0
* Maybe update libraries
* We should try to put the ledger behind a remote signer that does the queuing properly (?).
* check the nonce revelation throughput of the ledger
* Merge party next week
* Paris Blockchain Week?
* Carthage in 3 days? better estimate?
* do enough nodes have the protocol to serve the sources over the network
* all nodes already have the protocol due to the testchain
* try migrating carthage on a testnet
* should activate Thursday morning Paris time

## 2020-02-24
* [Seb's notes](https://gist.github.com/smondet/5ec3051aa0a473c0fbe482dca4cfa4dd)
* We had a merge party instead and merged 20+ MRs that day
* forgot to take notes though

## 2020-02-17
* [#694](https://gitlab.com/tezos/tezos/issues/694) → what do people think?
* If the goal is to select the genesis protocol, do we need `--genesis`?
* the idea is sound and should be implemented
* Are we switching to Dune ≥ 2.x? is it planned? (heard there are already some upgrading problems)
* currently on 1.11.4
* combine with the migration to ocaml.4.08.1
* switch to the last OCaml version that is supported by all our dependencies
* Upgrade to last version of ocamlformat.0.14.0
* or fix `make build-dev-deps`
* Update on environment V2
* merge a v2 (without changes) into master
* then rebase proto-proposal on top of master and use v2
* make sure that tezos-rust is informed and know about v1 and v2 and v3
* Merbocop: current status → [all tezos/tezos](https://smondet.gitlab.io/-/merbocop/-/jobs/438333614/artifacts/testweb/full-tezos-tezos.html) (∀ MR, see **“Message to OP”**)
* Suggestion for next week
* doesn't require more discussion, but more merging

## 2020-02-11
* Backporting 006 baker to old context
* doing the backport this week and Cryptium reviewing it thoroughly
* after 006 activation announce that 007 will be an environment upgrade and won't support lmdb
* bakers that don't want to upgrade should but they can still use mainnet-lmdb for the old context
* how to grow the merge team
* Mehdi
* not necessarily merge access when joining
* possibly in the next 3-4 weeks from CL
* TQ: Seb will ask, some people on documentation/michelson
* maybe ask Francois Maurel
* Jun has no capacity right now
* Merbocop report simplification (yes or no? if yes, who implements them? I (Romain) can, but Sébastien seems to want to refactor stuff first)
* team is in favour of yes
* Seb working on it
* Unignore dune-project files [!1453](https://gitlab.com/tezos/tezos/-/merge_requests/1453) => any reason not to?
* MR patch is good, but MR itself needs to be fixed (title, description, resolve threads)
* Remove nginx conf file [!1509](https://gitlab.com/tezos/tezos/-/merge_requests/1508) => any reason not to?
* We discussed at some point to have an easy load-balancer/protection layer for the default RPCs using nginx
* Environment V2
* https://gitlab.com/cryptiumlabs/tezos/-/merge_requests/39
* needs review
* give it names instead of v1 and v2
* shell implementors have to implement a all environments
* split the commits into what goes into tezos/tezos and proto-proposal
* then merge v2 into proto-proposal and use v2 as a base for all env changes
* then add "committing to receipts" as the first v2 upgrade in order to test it

## 2020-02-03
* Flextesa update: https://gitlab.com/tezos/tezos/-/merge_requests/1476 : need this update + another patch because some tests became unstable with the faster-loading client, especially with https://gitlab.com/tezos/tezos/-/merge_requests/1542
* Environment V2 - postpone to next week
* Add V2 protocol to the flextesa test
* Discuss next week how to deal with stale issues
* One possibility is to assign 2 NL, 1 CL, 0.5 TQ to deal with them and rotate them frequently

## 2020-01-27
* 006 baker will require new context format
* anything else that we need to communicate to operators?
* higher CPU/RAM requirements?
* what are our recommended specs for the node?
* 8gb ram, 2vcpus, 80gb ssd for fullnodes
* baking slack, twitter, reddit, agora - I'll loop Awa and Pierre/Marco
* release communication about having to upgrade to irmin2 next Monday
* with a backport for lmdb
* environment upgrade
* have a working version where the shell can contain two different environments and select it correctly based on the protocol declaration
* all upgrades are merged into V1 for now and then we snapshot it into V2 and revert V1 to the old state
* Sylvain to connect with Benjamin for extra info
* operations receipt are on a branch and need review (not yet in env V2)
* updates on the endorsement missing problem
* simple logs (https://gitlab.com/tezos/tezos/merge_requests/1529, started by Romain and then Pietro experimented on it): interesting direction or not?
* have simple logs that are less overhead to use
* should we include a changelog in the repository tree (https://gitlab.com/tezos/tezos/merge_requests/1321)?
* plebia updates
* trying different caching strategies
* building tooling for the better testing
* slightly smaller disk footprint than irmin2

## 2020-01-20
- status of proto-proposal + Environment.V2 development?
- https://gitlab.com/cryptiumlabs/tezos/tree/proto-proposal
- Next steps
- Merge https://gitlab.com/tezos/tezos/merge_requests/1496 into master (merged soon)
- Merge master into proto-proposal
- Open up all MRs again that touch the protocol
- Environment V2: https://gitlab.com/cryptiumlabs/tezos/issues/37
- backport 006 into mainnet-lmdb
- no, please upgrade to irmin2
- Adding Sylvain to the mergecall/team
- Missing endorsements: more logs from the endorser to find out what went wrong? (endorsement slot not seen? not sent to node? not in mempool? not in frontend mempool?)
- Will merge: !1511, !1510, !1485, !1458, !1447, !1446, !1171

## 2020-01-13
* tezos-protocol-compiler: Seb → TODO 1st MR with just the code
* how to handle security bugs and how to discuss, fix and release them
* have proper channel and simple process
* Hashtrees
* vbot has a new store that is much faster
* saves disk space / ram by a factor of 4
* client can typecheck Michelson without node

## 2020-01-06
* 83 open MRs
* mulit-network node

## 2019-12-17
* Multinetwork-node
* Pierre is okay from his side
* Romain can decide what to do next
* Seb is merging it and 006 is added into it
* Could someone merge the RPC docs
* https://gitlab.com/tezos/tezos/merge_requests/1451
* Please add issues for next version of the bot: https://gitlab.com/smondet/merbocop/issues
* Anything that we need to push before the end of 2019
* Mainnet released
* Carthage released
* Emmy+ blog post
* We are good
* Call next week and until the end of 2019
* 30th of December is the last call of the year
* Features to be merged in early 2020
* Mempool
* still needs a bit of troubleshooting
* memory leak that resets at 22:00
* some problems with some operations
* New store

## 2019-12-09
* small off-topic plug
* Did anyone come up with any other concerns with the current 006 proposal?
* https://gitlab.com/nomadic-labs/tezos/merge_requests/134
* https://gitlab.com/nomadic-labs/tezos/merge_requests/135
* invite Tom Jack to the merge team
* mainnet-staging → mainnet status
* We broke gitlab with `@` in the branch names: try <https://gitlab.com/nomadic-labs/tezos/tree/abate@ban_rpc>
* We could go through the MRs ☺ https://smondet.gitlab.io/merbocop/full-tezos-tezos.html

## 2019-12-03
* mainnet-staging → mainnet status
* `mainnet-staging` release today (from `romain@mainnet-staging-opam`), then to `mainnet` in one week
* `romain@mainnet-lmdb` → `mainnet-legacy(-lmdb)`
* → release-page + blog post with changelog (with blob from Tarides?) → @VBot
* escape-the-functor issue + voting in testnets
* white-list of protocols
* improve protocol compiler to avoid escape-the-functor
* mempool status
* related to multi-network-node: stuff from mainnet to backport, incl. “mempool-filters”
* Ben: 10% of review
* multi-network node: next release
* switch to release versions (& betas, alphas, etc.)
* Merbocop running since Friday, with `--only-updated-in-the-past 2.5:days` for the MR comments.
* Now also more details in the "report page" <https://smondet.gitlab.io/merbocop/full-tezos-tezos.html>

## 2019-11-25
* status of the next 006 release
* Assert Fix - [needs review](https://gitlab.com/nomadic-labs/tezos/merge_requests/112) (vbot is the approver klakplok is the merger (or the reverse))
* Emmy+ optimisations - [status update]() (moving forward! let's see at the end of the week where we are)
* mainnet-staging becomes mainnet status
* Merge last irmin-pack (with "incremental merges") in master (pirbo is the merger)
* Start a branch `release@mainnet-staging` with "alpine 10", last irmin-pack and "storage upgrade to 0.0.4". Add storage reconstruct and storage recovery once they are merge into master. (romain is the scheduler)
* "storage reconstruct" review done (vbot and pirbo are the tester on mainnet) klakplok is the merger
* "storage recovery" (klakplok is the approver, pirbo is the merger)
* How do we organize with respect to externalising libraries?
* externalized library should only concern stuff we have reasonnable assumption that
1/ we won't have to refactor them in the near futur
2/ someone outside tezos ecosystem will use it
* General issues:
* What about hotfixes as upgrades of our opam infra are heavy: OK because in last resort we would vendor back.
* Who reviews? Not clear is the merge team will also take the lead there but for sure having both code released and still in the repo is the worse and has to be avoid asap(by actually merging stuff in the external repos and by using that in tezos)
* Specific issues:
* we need an informal communication channel to ocplib-json-typed which is central. We'll try one last option but if it is not working we'll fork.
* tezos-crypto is depending on external but vendered crypto libraries which aren't really in a releasable state but that must be released to release... (HaCL release should be the definitive answer, there is no ETA for HaCL release :-))
* tezos/ Vs nomadic-lab/ organization? (not tackled)
* merbocop update

## 2019-11-18
* discussion around contract storage assert
* go through asserts and check them
* discussion around Emmy
* patches will come from Benjamin
* discussion around how to deal with the reset of carthagenet
* go back to 005 and vote on it again
* fix mempool behaviour that when it dies the mempool restarts
* storage2 works on every cloud except AWS
* more investigation needed
* remove legacy events from shell
* merge new mempool
* https://gitlab.com/tezos/tezos/merge_requests/968
* Waiting for results / regression tests

## 2019-11-13
* Services, errors, log-events in separate libraries? for example `_formats`?
* -> move into services
* Making proto_alpha able to switch from babylon (with !1359)
* /assume multinode
* step 1 snapshot 6 into 7 in master
* add a patch to unplug migration (5 -> 6) and plug a basic one (6 -> 7)
* start proto-proposal
* all patches on 006 must be replicated in 7 in MRs to master
* proto-proposal can be rebased EZly
* Where are we about the hunt of inefficiency in the bootstrap pipeline?
* not the priority anymore. Priorities are:
* reconstruct the context from a snapshot.
* a patch to recover from context hash not found which would try to restart from the predecessor of the "head"
* Logging mustn't allocate if it wont emit the message in the end (because it is debug message and we are not printing at level debug)
* A patch to make smaller steps in bootstrap pipeline
* Are we testing the last development in irmin (-index and -pack)?
* We'll sort that out around a beer dans 1h30
* Anybody at NL responsible for trying ocaml-memprof and ppx-bisect?

## 2019-11-04
* Shell release in mid November
* potentially include the new storage backend as a mandatory upgrade
* Problems left:
* Behaviour of merging
* OOM issue - seems fixed
* `Merbocop` startegy? Merge everything + tezos MR? or somebody wants to look in there first?
* Outcome: Add it directly to tezos/tezos
* Multi-network node:
* Seb: I've started [using](https://gitlab.com/tezos/flextesa/merge_requests/4/diffs?commit_id=a1dd70a46f775c4abc4edb7e42d17b3a1b5ac7c0) it in the flextesa docker image.
* What is left to do?
* "assign" button policy
* MRs for 006
* Baking rewards
* Comparable pairs
* Baking RPC