Re: Request to review feature-freeze proposed tickets

[Vinay Chella <vi...@gmail.com>]

Thanks for the responses, I think the summary so far is: committers and
reviewers are positive on reviewing the community tickets mentioned in this
email except for a couple of them that Joshua mentioned, with the caution of
not disrupting the current testing efforts.

Thank you, Ariel, for understanding the concerns and helping with reviews.

Thank you, Jon, for picking up CASSANDRA-14303.

@Joshua, if you can comment on the tickets that concern you that would be
helpful, and I will take them off from my list to track for 4.0.

I would like to help drive these tickets to their completion in 4.0 (either
deferred or committed) unless someone has concerns.

Thanks,
Vinay


On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli <ko...@gmail.com>
wrote:

> We already should be taking correctness and perf changes and I am +1 on
> taking operational tickets. Agree with Josh that the only exception will be
> if it causes disruption in testing.
>
> I think as a project we should be more open to operational issues as
> having a fork is not ideal.
>
> Regarding time it is taking to review things, I think we should not start
> doing big features post 4.0 but instead review all possible JIRAs first.
> Once we are out of this debt, we should define a  process so that we don’t
> end up in this state. I think this item deserves a separate thread which we
> can start closer to 4.0 being cut.
>
> > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie <jm...@apache.org>
> wrote:
> >
> > Strong +1 on prioritizing community engagement 1st and caution second,
> > though still prioritizing it. I think the right metric for us to
> calibrate
> > around is that "disrupt in-flight testing cycles", i.e. if changes cause
> > significant rework for people that have already begun testing 4.0,
> probably
> > ok to review and get it in but target 4.0.x.
> >
> > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
> benedict@apache.org>
> > wrote:
> >
> >>> I assume it's obvious to everyone that this should be taken on a
> >>> case-by-case basis. There's at least 2 that were in that list (one of
> >> which
> >>> Marcus bumped off PA) that are potentially big and hairy changes that
> >> would
> >>> disrupt in-flight testing cycles.
> >>
> >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

Re: Request to review feature-freeze proposed tickets

[Sumanth Pasupuleti <su...@gmail.com>]

Another note about 14557 - this also lets us fix 3.0 regression where we
cannot bootstrap new nodes until system_auth keyspace (that comes up with
RF=1) is "altered" to a higher RF. Instead, with 14557, one can set yaml
property minimum_keyspace_rf to, say, 3 and system keyspaces would honor it
(more in the JIRA).

Thanks,
Sumanth

On Tue, Jan 15, 2019 at 8:46 AM Sumanth Pasupuleti <
sumanth.pasupuleti.is@gmail.com> wrote:

> With 14303 in (thanks to Jon), wanted to see if I can get help on 14557 -
> it makes it further easy to create keyspaces (without having to always
> mention RF) and provides a way to ensure keyspaces are created with a
> minimum required RF.
>
> Thanks,
> Sumanth
>
> On Wed, Dec 5, 2018 at 5:35 PM Vinay Chella <vi...@gmail.com>
> wrote:
>
>> Thanks for the responses, I think the summary so far is: committers and
>> reviewers are positive on reviewing the community tickets mentioned in
>> this
>> email except for a couple of them that Joshua mentioned, with the caution
>> of
>> not disrupting the current testing efforts.
>>
>> Thank you, Ariel, for understanding the concerns and helping with reviews.
>>
>> Thank you, Jon, for picking up CASSANDRA-14303.
>>
>> @Joshua, if you can comment on the tickets that concern you that would be
>> helpful, and I will take them off from my list to track for 4.0.
>>
>> I would like to help drive these tickets to their completion in 4.0
>> (either
>> deferred or committed) unless someone has concerns.
>>
>> Thanks,
>> Vinay
>>
>>
>> On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli <ko...@gmail.com>
>> wrote:
>>
>> > We already should be taking correctness and perf changes and I am +1 on
>> > taking operational tickets. Agree with Josh that the only exception
>> will be
>> > if it causes disruption in testing.
>> >
>> > I think as a project we should be more open to operational issues as
>> > having a fork is not ideal.
>> >
>> > Regarding time it is taking to review things, I think we should not
>> start
>> > doing big features post 4.0 but instead review all possible JIRAs first.
>> > Once we are out of this debt, we should define a  process so that we
>> don’t
>> > end up in this state. I think this item deserves a separate thread
>> which we
>> > can start closer to 4.0 being cut.
>> >
>> > > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie <jm...@apache.org>
>> > wrote:
>> > >
>> > > Strong +1 on prioritizing community engagement 1st and caution second,
>> > > though still prioritizing it. I think the right metric for us to
>> > calibrate
>> > > around is that "disrupt in-flight testing cycles", i.e. if changes
>> cause
>> > > significant rework for people that have already begun testing 4.0,
>> > probably
>> > > ok to review and get it in but target 4.0.x.
>> > >
>> > > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
>> > benedict@apache.org>
>> > > wrote:
>> > >
>> > >>> I assume it's obvious to everyone that this should be taken on a
>> > >>> case-by-case basis. There's at least 2 that were in that list (one
>> of
>> > >> which
>> > >>> Marcus bumped off PA) that are potentially big and hairy changes
>> that
>> > >> would
>> > >>> disrupt in-flight testing cycles.
>> > >>
>> > >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
>> > >>
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> > >> For additional commands, e-mail: dev-help@cassandra.apache.org
>> > >>
>> > >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> > For additional commands, e-mail: dev-help@cassandra.apache.org
>> >
>> >
>>
>

Re: Request to review feature-freeze proposed tickets

[Sumanth Pasupuleti <su...@gmail.com>]

With 14303 in (thanks to Jon), wanted to see if I can get help on 14557 -
it makes it further easy to create keyspaces (without having to always
mention RF) and provides a way to ensure keyspaces are created with a
minimum required RF.

Thanks,
Sumanth

On Wed, Dec 5, 2018 at 5:35 PM Vinay Chella <vi...@gmail.com> wrote:

> Thanks for the responses, I think the summary so far is: committers and
> reviewers are positive on reviewing the community tickets mentioned in this
> email except for a couple of them that Joshua mentioned, with the caution
> of
> not disrupting the current testing efforts.
>
> Thank you, Ariel, for understanding the concerns and helping with reviews.
>
> Thank you, Jon, for picking up CASSANDRA-14303.
>
> @Joshua, if you can comment on the tickets that concern you that would be
> helpful, and I will take them off from my list to track for 4.0.
>
> I would like to help drive these tickets to their completion in 4.0 (either
> deferred or committed) unless someone has concerns.
>
> Thanks,
> Vinay
>
>
> On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli <ko...@gmail.com>
> wrote:
>
> > We already should be taking correctness and perf changes and I am +1 on
> > taking operational tickets. Agree with Josh that the only exception will
> be
> > if it causes disruption in testing.
> >
> > I think as a project we should be more open to operational issues as
> > having a fork is not ideal.
> >
> > Regarding time it is taking to review things, I think we should not start
> > doing big features post 4.0 but instead review all possible JIRAs first.
> > Once we are out of this debt, we should define a  process so that we
> don’t
> > end up in this state. I think this item deserves a separate thread which
> we
> > can start closer to 4.0 being cut.
> >
> > > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie <jm...@apache.org>
> > wrote:
> > >
> > > Strong +1 on prioritizing community engagement 1st and caution second,
> > > though still prioritizing it. I think the right metric for us to
> > calibrate
> > > around is that "disrupt in-flight testing cycles", i.e. if changes
> cause
> > > significant rework for people that have already begun testing 4.0,
> > probably
> > > ok to review and get it in but target 4.0.x.
> > >
> > > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
> > benedict@apache.org>
> > > wrote:
> > >
> > >>> I assume it's obvious to everyone that this should be taken on a
> > >>> case-by-case basis. There's at least 2 that were in that list (one of
> > >> which
> > >>> Marcus bumped off PA) that are potentially big and hairy changes that
> > >> would
> > >>> disrupt in-flight testing cycles.
> > >>
> > >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>