Bruce, you’re right, there doesn’t seem to be consensus, and a PR was
premature. I was reminded this week that voting is a “last resort”, not the
way to build consensus. I have withdrawn the PR.
On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt
wrote:
> I'm a proponent of using squash-and-merge
I think Jinmei is also referring to the situation where you might *not* already
be connected but want to execute something like this:
gfsh>status locator --host=fooish --port=10334
In this case it would fail as well. Seems like we'd either need to remove
those options so you *always* need to 'co
Build Update for apache/geode-native
-
Build: #2275
Status: Passed
Duration: 1 hr, 17 mins, and 3 secs
Commit: 3199cae (rel/v1.11.0.RC4)
Author: Jacob Barrett
Message: GEODE-7426: Fixes segfault in log message. (#545)
(cherry picked from commit 55da853760c200
I like the approach Jens is suggesting, seems intuitive to me
On Thu, Dec 19, 2019 at 6:31 PM Jens Deppe wrote:
> So it seems that the situation is something like this where I'm able to
> make the initial connection but then retrieving status fails:
>
> gfsh>connect --security-properties-file=..
Given it is the holidays, perhaps more time is in order. I am bumping the
voting deadline to Friday, December 27th, 2019.
Thanks,
Mark
> On Dec 20, 2019, at 2:46 PM, Mark Hanson wrote:
>
> Subject: [VOTE] Apache Geode 1.11.0.RC4
> Hello Geode Dev Community,
>
> This is a release candidate f
Subject: [VOTE] Apache Geode 1.11.0.RC4
Hello Geode Dev Community,
This is a release candidate for Apache Geode version 1.11.0.RC4.
Thanks to all the community members for their contributions to this release!
Please do a review and give your feedback, including the checks you performed.
Voting d
Build Update for apache/geode-examples
-
Build: #395
Status: Errored
Duration: 1 min and 15 secs
Commit: 9e6f13e (rel/v1.11.0.RC4)
Author: Mark Hanson
Message: temporarily point to staging repo for CI purposes
View the changeset:
https://github.com/apache/geo
Just FWIW, the situation described of having multiple commits in a single
PR with separate associated JIRA tickets is still kind of problematic. It
could well be the case that the commits are interdependent, thus when
bisecting etc it's still not possible to revert the fix for a single
bug/feature
Hi Dan,
When we do squash merge all the commit messages are preserved and also the
co-authored tag works when we do squash merge.
So the authorship and history are preserved.
In my own personal experience and reverts and pinpointing regression
failures are tough when the commits are spread out. A
This was the part I was referring to, from the existing PR template:
> Update the PR template to change the text "Is your initial contribution
> a single, squashed commit” to “Is your initial contribution squashed for
> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> ‘fix’
I'll change to -0.
I think merge commits are a nice way to record history in some cases, and
can also be a way to avoid messy conflicts that come with rebase. Merge
commits also preserve authorship of commits (compared to squash-merge),
which I think is valuable as an open source community that is
We are not trying to force devs to squash prior to committing a PR. There was
old language in the PR template that stated this, which we are relaxing to
emphasize submitting your PR in a way that is most amenable to review. The
geode-native repo does not appear to have a .github/PULL_REQUEST_
Just to reiterate. Nothing changes in the workflow of a developer. It's
just in the end, when all the reviews are done and all the tests are
passing, then the button to click in the Github web UI is "Squash and
Merge". That's all.
Regards
Naba
On Fri, Dec 20, 2019 at 11:55 AM Blake Bender wrot
Very well, then, I'll abide by the group consensus but am on the record as:
* strongly opposed to multi-commit PRs, because I believe it clutters
history, and
* also not a big fan of forcing devs to rebase and squash prior to
submitting a PR. IMO this is busy work, and *may* in some small minority
Whether we are talking about the geode/ repository or the geode-native/
repository we are all one GEODE community.
The idea of a native client team may matter in some contexts but in this space
we are all GEODE contributors.
Adopting a common approach across our repos will make it easier for ne
Just to be clear, this proposal wouldn't require anyone to squash their commits
before merging a PR. All it’s saying is that if you do have multiple commits in
your PR, you would have to rebase those commits onto develop before merging to
ensure a linear commit history.
- Aaron
> On Dec 20, 20
Is this a policy the native client team must abide by, as well? It varies
slightly with what we've been doing, and all other things being equal I see
no reason for us to change that. If I am to have any measure of control
over the nc repository, I will definitely enforce a 1:1 correspondence
betw
Merge commit is the new contributor's default setting. When we are merging
new contributor's PR, since we are so used to THINKING "squash-and-merge"
is the default, we forgot to check what the button really says when we are
merging other people's PR.
On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghar
The objections in the discuss thread all seemed to hinge on item 2) of the
original proposal. With this item removed, perhaps many or all of those people
would no longer vote -1.
Please feel free to “request changes” on the PR if you still want something
different -or- to indicate you believe
I'm a proponent of using squash-and-merge, and once a person has chosen
this option once it comes up by default afterwards...
Owen, I don't think you have consensus to put forth this PR, there are -1s
above... (early voting)
maybe we'll be better off socializing the norm of squash-and-merge and
well, I always use squash-and-merge so I'm not against the primary
motivation for this thread.
On 12/20/19 10:07 AM, Owen Nichols wrote:
The proposed action manifests as a commit to the Geode git repository, so a PR
is an acceptable vehicle for voting in this case.
On Dec 20, 2019, at 9:38 A
The proposed action manifests as a commit to the Geode git repository, so a PR
is an acceptable vehicle for voting in this case.
> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt wrote:
>
> I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread and a
> request to "vote" using a
I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread
and a request to "vote" using a PR. This all seems out of order to me.
Our votes are supposed to be on the email list, aren't they? and I
haven't seen a VOTE request.
On 12/20/19 9:33 AM, Nabarun Nag wrote:
+1
On Fri,
+1
On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols wrote:
> Based on the feedback so far, I will amend the proposal to drop item 2).
> Therefore, the current ability to create merge commits using command-line
> git will remain available.
>
> The proposal as amended is now:
> > Change GitHub setting
Based on the feedback so far, I will amend the proposal to drop item 2).
Therefore, the current ability to create merge commits using command-line git
will remain available.
The proposal as amended is now:
> Change GitHub settings to make "Squash and merge" the default
> (by removing “Create a
+1 to (1) and (3)
I’m on board with (1). I’m hesitant about agreeing to (2) because it seems
harder to “accidentally” do a merge commit via the command line, and I don’t
want to add unnecessary restrictions. (3) has needed to be done for some time
now, so I’m happy to see a proposal to change t
+1
On Fri 20 Dec 2019 at 16:18, Owen Nichols wrote:
> Hi Bruce, this proposal will not waste a single second of your time. It
> just prevents people from accidentally pressing a button that we have
> already agreed should never be pressed, but because we never configured our
> GitHub to match o
Hi Bruce, this proposal will not waste a single second of your time. It just
prevents people from accidentally pressing a button that we have already agreed
should never be pressed, but because we never configured our GitHub to match
our stated policy, is currently the default.
However, it wil
Yes, I got freaked out somehow this morning by thinking I had accidentally
clicked the wrong button to include all the individual commits in my PR to
the develop branch, (luckily it's just a wrong view). I would think disable
that button would be a good idea.
On Thu, Dec 19, 2019 at 5:04 PM Nabaru
I agree with Jake. I would go further by saying that I see very little
merit in this proposal. I think we're getting more and more
bureaucratic in our process and that it stifles productivity. I was
recently forced to spend three days fixing tests in which I had changed
an import statement b
Hi Blake,
Are you sure that the TransactionId is always set to -1?
We have used the C++ native client transactions and they apparently worked.
/Alberto G.
From: Blake Bender
Sent: Friday, December 13, 2019 6:17 PM
To: dev@geode.apache.org
Subject: Re: Issues w
31 matches
Mail list logo
