Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process
All too often, a work-invalidating insight hits late in a cycle while people are talking about something and significant work has been done on the invalidated proposal. A CEP up front with engagement from a bunch of parties may very well help surface those design implications sooner, but we also have a pretty old code-base with a lot of interesting edge-cases in it (both in code and in state/domain) that we won't realize until we're in the thick of it. So +1 to bes' general sentiments here. On Tue, Sep 17, 2019 at 1:53 PM Benedict Elliott Smith wrote: > We have to be very careful here in my opinion. While the process may > provide some moral authority, particularly on matters of taste or opinion, > we cannot mandate participation, else accept the decisions that arise. > People are legitimately busy, and have to steal their spare time to > participate - which can be draining. Particularly for large undertakings, > where context and headspace can be costly, even more so when you have your > own projects to deliver. > > I only personally endorse giving the _benefit of the doubt_ to > participants in a CEP/CIP. It cannot be carte blanche, or even a > presumption of a decision being made in its favour. A CEP/CIP should still > aim to bring the _most likely_ to be accepted proposal to the whole project > for its endorsement, or for further revision. > > Our goal here should be to mitigate risk for all parties, without > disrupting the governance of the project. Everyone should be > _incentivised_ to behave in desirable way, but we should not penalise too > heavily any individual (or the project, by ignoring them) for failing to do > so. > > It seems to follow that a full PMC vote could be held to accept or reject > the result of any CEP/CIP, rather than the normal +1/-1 of a single > committer/PMC member. I would favour this meaning there no veto is > possible at this stage, which would provide a further incentive to > authors. In this case we only need to agree guidance for how a completed > CEP/CIP should be received for such a vote, since we cannot bind a future > PMC anyway. > > > On 17/09/2019, 18:19, "sankalp kohli" wrote: > > Another thing which it should solve is someone proposing an alternate > very > late into development which could be provided sooner. If someone has a > good > feedback which could not have been given at the time of CEP then that > is > good. We don't want situations where contributors have done the CEP and > then worked on implementation of it and then someone who has not read > the > CEP comes in and starts giving feedback. This feedback should come at > the > time of CEP if CEP has covered that area. > To be clear, I am not saying people should not give feedback later just > that they dont ignore the whole thing and wake up later in the process. > This causes huge productivity and morale loss to code contributors who > are > in minority right now in the community. > > On Tue, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > Can we modify the document to make this really explicit then? Right > now, > > the language suggests the process is mandated, rather than > encouraged and > > beneficial. > > > > It would be nice to frame it as a positive and incentivised > undertaking by > > authors, and to list the intended advantages, as well as the > potential > > disadvantages of not undertaking it, while making it clear it is left > > entirely to their own judgement whether or not to do so. > > > > To be really clear, I do not refer to the flexible definition of the > > process, but to whether participation in even a modest > interpretation of > > the process is necessary at all. This is a form of pre-registration > for > > work, to achieve community buy-in. If you want to go ahead and do > > something on your own, you only risk difficulty and delays when > obtaining > > community buy-in after the fact. Let's not dissuade hobbyists, > part-timers > > or scratching an itch by suggesting their work will be discounted > because > > it wasn't pre-registered. > > > > > > On 17/09/2019, 06:46, "Mick Semb Wever" wrote: > > > > > > > > > I think we need to have a meta discussion about the goal for > > > introducing a new process. > > > > > > Indeed, and these were only two brief examples that came to me. > > Another, using the sidecar proposal as an example, is simply to > ensure a > > little patience is taken during the initial brainstorming and > navigation > > phase, to give more open collaboration a better chance. What's in the > > landscape, where's the value, who might be interested in getting > involved > > in this, etc etc. I think the C* community has typically been pretty > > amazing at this, but it would be nice to see it formalised
Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process
We have to be very careful here in my opinion. While the process may provide some moral authority, particularly on matters of taste or opinion, we cannot mandate participation, else accept the decisions that arise. People are legitimately busy, and have to steal their spare time to participate - which can be draining. Particularly for large undertakings, where context and headspace can be costly, even more so when you have your own projects to deliver. I only personally endorse giving the _benefit of the doubt_ to participants in a CEP/CIP. It cannot be carte blanche, or even a presumption of a decision being made in its favour. A CEP/CIP should still aim to bring the _most likely_ to be accepted proposal to the whole project for its endorsement, or for further revision. Our goal here should be to mitigate risk for all parties, without disrupting the governance of the project. Everyone should be _incentivised_ to behave in desirable way, but we should not penalise too heavily any individual (or the project, by ignoring them) for failing to do so. It seems to follow that a full PMC vote could be held to accept or reject the result of any CEP/CIP, rather than the normal +1/-1 of a single committer/PMC member. I would favour this meaning there no veto is possible at this stage, which would provide a further incentive to authors. In this case we only need to agree guidance for how a completed CEP/CIP should be received for such a vote, since we cannot bind a future PMC anyway. On 17/09/2019, 18:19, "sankalp kohli" wrote: Another thing which it should solve is someone proposing an alternate very late into development which could be provided sooner. If someone has a good feedback which could not have been given at the time of CEP then that is good. We don't want situations where contributors have done the CEP and then worked on implementation of it and then someone who has not read the CEP comes in and starts giving feedback. This feedback should come at the time of CEP if CEP has covered that area. To be clear, I am not saying people should not give feedback later just that they dont ignore the whole thing and wake up later in the process. This causes huge productivity and morale loss to code contributors who are in minority right now in the community. On Tue, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith wrote: > Can we modify the document to make this really explicit then? Right now, > the language suggests the process is mandated, rather than encouraged and > beneficial. > > It would be nice to frame it as a positive and incentivised undertaking by > authors, and to list the intended advantages, as well as the potential > disadvantages of not undertaking it, while making it clear it is left > entirely to their own judgement whether or not to do so. > > To be really clear, I do not refer to the flexible definition of the > process, but to whether participation in even a modest interpretation of > the process is necessary at all. This is a form of pre-registration for > work, to achieve community buy-in. If you want to go ahead and do > something on your own, you only risk difficulty and delays when obtaining > community buy-in after the fact. Let's not dissuade hobbyists, part-timers > or scratching an itch by suggesting their work will be discounted because > it wasn't pre-registered. > > > On 17/09/2019, 06:46, "Mick Semb Wever" wrote: > > > > > I think we need to have a meta discussion about the goal for > > introducing a new process. > > > Indeed, and these were only two brief examples that came to me. > Another, using the sidecar proposal as an example, is simply to ensure a > little patience is taken during the initial brainstorming and navigation > phase, to give more open collaboration a better chance. What's in the > landscape, where's the value, who might be interested in getting involved > in this, etc etc. I think the C* community has typically been pretty > amazing at this, but it would be nice to see it formalised a bit better. > > > > By not mandating it, we do not need to define where it is necessary; > > the larger and more impactful the change, the greater the incentive > to > > the author. > > > This is what Scott highlighted well. > Sure, a CEP could be opened with nothing but a title to begin with. > And where it goes from there is up to the working group that materialises. > Just to have a landing space for new features that's not Jira, I believe > would be of value. > > And in no way should the CEP be a return to waterfall. As you say, > late discoveries and feedback (as annoying as it can be) is all part of the > agile game. > > >
Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process
Another thing which it should solve is someone proposing an alternate very late into development which could be provided sooner. If someone has a good feedback which could not have been given at the time of CEP then that is good. We don't want situations where contributors have done the CEP and then worked on implementation of it and then someone who has not read the CEP comes in and starts giving feedback. This feedback should come at the time of CEP if CEP has covered that area. To be clear, I am not saying people should not give feedback later just that they dont ignore the whole thing and wake up later in the process. This causes huge productivity and morale loss to code contributors who are in minority right now in the community. On Tue, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith wrote: > Can we modify the document to make this really explicit then? Right now, > the language suggests the process is mandated, rather than encouraged and > beneficial. > > It would be nice to frame it as a positive and incentivised undertaking by > authors, and to list the intended advantages, as well as the potential > disadvantages of not undertaking it, while making it clear it is left > entirely to their own judgement whether or not to do so. > > To be really clear, I do not refer to the flexible definition of the > process, but to whether participation in even a modest interpretation of > the process is necessary at all. This is a form of pre-registration for > work, to achieve community buy-in. If you want to go ahead and do > something on your own, you only risk difficulty and delays when obtaining > community buy-in after the fact. Let's not dissuade hobbyists, part-timers > or scratching an itch by suggesting their work will be discounted because > it wasn't pre-registered. > > > On 17/09/2019, 06:46, "Mick Semb Wever" wrote: > > > > > I think we need to have a meta discussion about the goal for > > introducing a new process. > > > Indeed, and these were only two brief examples that came to me. > Another, using the sidecar proposal as an example, is simply to ensure a > little patience is taken during the initial brainstorming and navigation > phase, to give more open collaboration a better chance. What's in the > landscape, where's the value, who might be interested in getting involved > in this, etc etc. I think the C* community has typically been pretty > amazing at this, but it would be nice to see it formalised a bit better. > > > > By not mandating it, we do not need to define where it is necessary; > > the larger and more impactful the change, the greater the incentive > to > > the author. > > > This is what Scott highlighted well. > Sure, a CEP could be opened with nothing but a title to begin with. > And where it goes from there is up to the working group that materialises. > Just to have a landing space for new features that's not Jira, I believe > would be of value. > > And in no way should the CEP be a return to waterfall. As you say, > late discoveries and feedback (as annoying as it can be) is all part of the > agile game. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: 4.0 Max TTL
I personally think we should move this forward for the reasons mentioned beforehand. Widening to a long value seems to be the most pragmatic approach if we want to get this in for 4.0. Alternatively, we can let operators choose the precision int vs long in case TTLs are not used. I'd be happy to assist with a secondary/tertiary review if anyone is willing to take CASSANDRA-14227. Em ter, 17 de set de 2019 às 11:50, Sumanth Pasupuleti < sumanth.pasupuleti...@gmail.com> escreveu: > We will have to deal with fixing this TTL issue eventually as more users > start to deal with the boundaries of currently allowed TTL (which keeps > declining). It will be neat if we can get this into 4.0 before it is > released - be it in beta or future 4.0 alpha(s) - the sooner the better, as > everyone in the community gets busy validating 4.0 bits. > > Thanks, > Sumanth > > On Tue, Sep 17, 2019 at 7:33 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > 1.During ApacheCon, Laxmikant approached me to discuss > > CASSANDRA-14227. It was also raised on the list back in January. > > > > > > > > Taking a closer look, it probably is not very difficult for us to fix > this > > – either by treating the int as unsigned, or by widening it to a long > > value. Since this can only easily be done once per major version, and > the > > number of representable dates is steadily declining, there’s a strong > case > > to be made for delivering this for 4.0-beta. > > > > > > > > The least invasive change is probably to simply permit negative values, > > and to treat them as unsigned. However, this or using long would both be > > modest changes. > > > > > > > > Does anyone have any strong thoughts or opinions on this? > > > > >
Re: 4.0 Max TTL
We will have to deal with fixing this TTL issue eventually as more users start to deal with the boundaries of currently allowed TTL (which keeps declining). It will be neat if we can get this into 4.0 before it is released - be it in beta or future 4.0 alpha(s) - the sooner the better, as everyone in the community gets busy validating 4.0 bits. Thanks, Sumanth On Tue, Sep 17, 2019 at 7:33 AM Benedict Elliott Smith wrote: > 1.During ApacheCon, Laxmikant approached me to discuss > CASSANDRA-14227. It was also raised on the list back in January. > > > > Taking a closer look, it probably is not very difficult for us to fix this > – either by treating the int as unsigned, or by widening it to a long > value. Since this can only easily be done once per major version, and the > number of representable dates is steadily declining, there’s a strong case > to be made for delivering this for 4.0-beta. > > > > The least invasive change is probably to simply permit negative values, > and to treat them as unsigned. However, this or using long would both be > modest changes. > > > > Does anyone have any strong thoughts or opinions on this? > >
4.0 Max TTL
1.During ApacheCon, Laxmikant approached me to discuss CASSANDRA-14227. It was also raised on the list back in January. Taking a closer look, it probably is not very difficult for us to fix this – either by treating the int as unsigned, or by widening it to a long value. Since this can only easily be done once per major version, and the number of representable dates is steadily declining, there’s a strong case to be made for delivering this for 4.0-beta. The least invasive change is probably to simply permit negative values, and to treat them as unsigned. However, this or using long would both be modest changes. Does anyone have any strong thoughts or opinions on this?
Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process
Can we modify the document to make this really explicit then? Right now, the language suggests the process is mandated, rather than encouraged and beneficial. It would be nice to frame it as a positive and incentivised undertaking by authors, and to list the intended advantages, as well as the potential disadvantages of not undertaking it, while making it clear it is left entirely to their own judgement whether or not to do so. To be really clear, I do not refer to the flexible definition of the process, but to whether participation in even a modest interpretation of the process is necessary at all. This is a form of pre-registration for work, to achieve community buy-in. If you want to go ahead and do something on your own, you only risk difficulty and delays when obtaining community buy-in after the fact. Let's not dissuade hobbyists, part-timers or scratching an itch by suggesting their work will be discounted because it wasn't pre-registered. On 17/09/2019, 06:46, "Mick Semb Wever" wrote: > I think we need to have a meta discussion about the goal for > introducing a new process. Indeed, and these were only two brief examples that came to me. Another, using the sidecar proposal as an example, is simply to ensure a little patience is taken during the initial brainstorming and navigation phase, to give more open collaboration a better chance. What's in the landscape, where's the value, who might be interested in getting involved in this, etc etc. I think the C* community has typically been pretty amazing at this, but it would be nice to see it formalised a bit better. > By not mandating it, we do not need to define where it is necessary; > the larger and more impactful the change, the greater the incentive to > the author. This is what Scott highlighted well. Sure, a CEP could be opened with nothing but a title to begin with. And where it goes from there is up to the working group that materialises. Just to have a landing space for new features that's not Jira, I believe would be of value. And in no way should the CEP be a return to waterfall. As you say, late discoveries and feedback (as annoying as it can be) is all part of the agile game. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
