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.
To change your delivery options, retrieve your password, or unsubscribe from this list, visit