Regarding moving Bugzillas to RESOLVED, it's a good point, but Bugzillas also have other states: VERIFIED and CLOSED, and I do think that the bug should be assigned one of these once it has been
merged onto master, but perhaps we could have some flexibility with RESOLVED. To me, and that's my personal interpretation, that state means that the solution to the bug has been implemented, it does not necessarily mean that it is integrated into the rest
(i.e. merged onto master). But if we are to have a particular policy about this, one way or the other, it should be explicitly stated, perhaps in Guidelines for the lifecycle of Papyrus-RT
bugs.
As for the status of Gerrits, I would take those with a grain of salt, as I have had to use (or perhaps abuse) Gerrit a bit to store temporary and experimental commits. The reason is that in the
past, I had to reinstall the developer environment from scratch many, many, many times over, including a complete wipe out of my local git repos (for many reasons, including tests of the Oomph dev setup model, and times where my environment got corrupted),
and the simplest way to save such experimental work was to push it to Gerrit. But several of my own outstanding gerrits may no longer be relevant. I'll have to clean them up, and abandon a few. Furthermore, there is also a number of gerrits, not only my own,
which are "false starts", for a lack of a better term. The point is that a simple Gerrit query might not give you an accurate impression of what is work that is intended to be merged.