Please use meaningful PR titles. When browsing the PRs or reading the
notifications, one shouldn’t have to decode your cryptic title. Consider the
title as the first line of you commit message.
-Jake
+1
It’s easy to fix too!
On Mon, Mar 2, 2020 at 8:34 AM Jacob Barrett wrote:
> Please use meaningful PR titles. When browsing the PRs or reading the
> notifications, one shouldn’t have to decode your cryptic title. Consider
> the title as the first line of you commit message.
>
> -Jake
>
>
Don't we have a published checklist or guideline or something for this
already? Including stuff like 'always prefix the PR title with a JIRA
ticket #,' etc?
On Mon, Mar 2, 2020 at 8:47 AM Owen Nichols wrote:
> +1
>
> It’s easy to fix too!
>
> On Mon, Mar 2, 2020 at 8:34 AM Jacob Barrett wrote:
>
> Don't we have a published checklist or guideline or something for this
> already? Including stuff like 'always prefix the PR title with a JIRA
> ticket #,' etc?
Yes, we do. However, it only request the addition of the JIRA ticket #. It
does not call out having a descriptive title.
I like th
If I may add one caveat. If a pull request is in a ready to review state …
. If it is prefaced with Do Not Review: then .
Thanks,
Mark
> On Mar 2, 2020, at 9:30 AM, Alexander Murmann wrote:
>
>>
>> Don't we have a published checklist or guideline or something for this
>> already? Including s
> On Mar 2, 2020, at 10:10 AM, Mark Hanson wrote:
>
> If I may add one caveat. If a pull request is in a ready to review state …
> . If it is prefaced with Do Not Review: then apply>.
-1
Use the “Draft” state of the PR and use good titles from the beginning. Using
“DO NO REVIEW” in the tit
I thought PR titles are generated from the git comment.
So, I'm expecting it to have the following format: "GEODE-XXX: "
Glancing at the current PR list, I do see that there is at least 1 PR
that does not follow that guideline.
We also don't want to be overly prescriptive, so maybe if
Should we deprecate cluster ssl as well? Cluster ssl without udp encryption
means that not all P2P traffic will be encrypted. If we don't want to
support P2P encryption, it seems like we should deprecate both?
-Dan
On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer wrote:
> Yes, the proposal was dep
I think that if TCP connections are secured and UDP connections are not,
then we've regressed in our security.
Is there a way that we could use DTLS?
--Udo
On 3/2/20 10:21 AM, Dan Smith wrote:
Should we deprecate cluster ssl as well? Cluster ssl without udp encryption
means that not all P2P t
I agree with Jake and do appreciate everyone using the "DRAFT" feature, one
downfall of that is this is not visible unless on Github; i.e. if you see
an email for a PR you won't know its in "DRAFT" mode until you go look at
it...
a related part of this, to me, seems to be that the PR checklist is
I don’t think regressed is the right word. There was an effort to harden our
udp p2p traffic using encryption based on a DH key exchange. I’m not clear on
how much that approach actually improved the security of data in motion. And I
don’t believe it saw much if any use in practice.
Anthony
The reason I prefer the rules not apply in draft is quite simple, people
sometimes use the PR pipeline to test stuff. Its easy enough to just put in
GEODE- but sometimes it just “Test” because there is no GEODE associated.
Either way I don’t care enough to debate. I will abide by what the devs
I'm coming to this conversation late and probably am missing a lot of context.
Is the point of this to be to direct senders to some common gateway that all of
the gateway receivers are configured to advertise? I've been working on a PR
to support redirection of connections for client/server an
I'm back tracking on my suggestion... Got stuck on the "removal" part.
+1 -> for deprecation for said feature in 1.12
-1 -> for removal until alternative/equivalent replacement has been
added (or major version release -- which ever comes first)
@Dan, are you thinking that secured intra-cluste
I am not sure I am following the argument for removal in a minor version.
Let's expand the argument and make sure we are all basing this on the same
assumptions:
Java has removed insecure encryption algorithms in patch releases. This was
presumably done because it's really fixing a vulnerability,
+1 to the proposal as it’s written.
I’m not sure about setting regular intervals for patch releases vs sticking
with our current “on-demand” process. I don’t think this has to be spelled out
in this proposal. I’d be fine with sticking to “on-demand” patch releases as
we’ve been doing for now an
By sticking to the "on-demand" patch release process, then there is no
difference to the current release process, and this proposal adds nothing
of value.
On Tue, Mar 3, 2020 at 12:44 AM Aaron Lindsey
wrote:
> +1 to the proposal as it’s written.
>
> I’m not sure about setting regular intervals f
+1 to deprecating this feature in 1.12
As to whether we should remove this feature in a minor release, I think that,
as Alexander pointed out, it hinges on the question of whether we perceive
there to be some security issue in the feature’s implementation.
This statement from the proposal shoul
+1 to the proposal as written.
The proposal does talk about support branches, but doesn't describe when
they are created. Is the idea that we create a support/1.X branch as soon
as we release geode 1.X, and then create release branches off of that as
needed?
-Dan
My interpretation is that we would cut support/1.13 from develop on the next
scheduled cut date (May 4), and make 1.13.0 and all following 1.13.x patch
releases directly from this branch. Otherwise it becomes a two-step process if
all patches have to be cherry-picked from develop -> support/x.y
20 matches
Mail list logo
