Sergio,
thank you for clarifying the Hive version story.
Do we have any explicit policy about compatibility with other components and
Hive specifically? Do we need to support older versions of Hive or supporting
the current released Hive 1.x version is sufficient?
At least it seems that we nee
I agree with Sergio but I'm not sure if current plan is to release HA
functionality.
If we plan to make it a release, we need to make sure sentry HA works with
one of the versions of Hive where
1. Notification log implementation has the functionality that sentry
needs.
2. Supports author
I agree with Sergio but I'm not sure if current plan is to release HA
functionality.
If we plan to make it a release, we need to make sure sentry HA works with
one of the versions of Hive where
1. Notification log implementation has the functionality that sentry
needs.
2. Supports author
Pointing the branch to master sounds good.
I just have one concern regarding the Hive dependency that Sentry HA needs.
This new feature requires that the Hive version running with Sentry master
has HMS notification logs enabled. Hive 1.1.0 (currently officially
supported by Sentry 1.7) started thi
OK thanks, sounds good to me then. Let's try and do development work on
master from now on though...
Colm.
On Tue, Apr 18, 2017 at 2:14 AM, Alexander Kolbasov
wrote:
> FYI, I contacted Colin Ma who was working on the refactoring and he was Ok
> with skipping this change for 1.8. That said, the
FYI, I contacted Colin Ma who was working on the refactoring and he was Ok
with skipping this change for 1.8. That said, the refactoring was done for
a reason it we should get back to it post 1.8,
- Alex
On Mon, Apr 17, 2017 at 5:51 PM Hao Hao wrote:
> The proposal is good to me as well. Should
The proposal is good to me as well. Should we start a vote on this? Or we
can just start to do it if no one is objecting?
Best,
Hao
On Mon, Apr 17, 2017 at 4:42 PM, Vamsee Yarlagadda
wrote:
> >
> > Cherry-pick any commits that happened since sentry-ha-redesign was
> forked,
> > except a few des
>
> Cherry-pick any commits that happened since sentry-ha-redesign was forked,
> except a few described below
> Exclude big refactoring commit (SENTRY-1205) and related commits
> (SENTRY-1436, SENTRY-1438, SENTRY-1406)
> Rename master to a dev branch
> Rename sentry-ha-redesign to master
This sou
Have you tried to contact the author of the patch for SENTRY-1205 to get
their opinion? If there are major conflicts between the two branches then I
think your proposal is ok for 1.8, as the new feature should take
precedence over a refactoring effort.
However, in future, I think it is not a good
I would like to make a more concrete proposal and I am interested in opinion
from Sentry PMC members on this.
I would propose the following approach for merging Sentry HA into Sentry master:
Cherry-pick any commits that happened since sentry-ha-redesign was forked,
except a few described below
> On Mar 22, 2017, at 2:39 PM, Sergio Pena wrote:
>
> The usual way we do this in other projects is the 1st option. We can create a
> new JIRA for the merge, then submit the patch with the conflicts resolved,
> wait for tests, then commit it.
The real question here is whether we allow merge c
The usual way we do this in other projects is the 1st option. We can create
a new JIRA for the merge, then submit the patch with the conflicts
resolved, wait for tests, then commit it.
Although the 2nd option looks easier if we only missing one commit, but I
think we should avoid it just in case w
Hello,
I would like to start the discussion on merging sentry-ha-redesign branch
with master.
As of now most of the changes from master are merged into
sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor the
code for sentry-provider-db and create sentry-service module) and
associa
13 matches
Mail list logo
