Hi, Ernesto,
I have often used gerrit drafts to post work in the convenient remote storage offered by the Gerrit server, which aren’t yet ready for review. Drafts are nice because they don’t trigger builds, they can’t be merged, and most people can’t even see them. A draft can be published as a review once it is ready for that.
On 19 October, 2016 at 12:40:30, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
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.
Hi,
In general I feel that we
need to track the outstanding Gerrit changes in the same way as we
track outstanding Bugzillas. I myself have a query setup for Gerrit
to list all outstanding Gerrit changes for both Papyrus-RT repos.
In general, we have quite a few Gerrit changes that has gotten
stuck there...
So this about the
"psychological aspect", I think that it would be good in general if
we also tried to followup what is happening with Gerrit changes,
and not only Bugzillas. If we had such focus on Gerrit as well,
then I would not be bothered about loosing track if it is ready or
not. For me, Gerrit is an equally important tool for keeping track
of what is ready or not.
Regarding moving Bugzillas to
RESOLVED, my personal opinion is that this should not be done until
they have been merged to master anyway, so resolving Bugzillas that
ends up on some topic branch does not feel right either. Then I
feel it is better to track Gerrit changes.
Just my personal opinions
regarding this... :)
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|