[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [papyrus-rt-dev] Branch for post 0.8 commits
|
Yep. A "drafts" segment instead of "for". So thoroughly gittish. 😉
cW
On October 19, 2016 at 13:59:37, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
And to use gerrit drafts you just push to
refs/drafts/<branch>?
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... :)