I see. Thanks for clarifying; I was confused by beginning with “RE 5" but discussing Environment.
Bear in mind we’re not only replacing Environment with the Platform field, but also a number of labels that were searchable and indicated environment/platform information. Labels such as ‘Windows' (and ‘windows’), Java11, Debian, EC2,… Clearly some people want to capture this information in a way that is more usable, though admittedly this is not super common. Still, it seems preferable to both support this natively in the schema, and try to curate a more accurate and consistent representation. That is, again, if possible. If somebody else would like to back this dissent, though, I can separate out Platform in the next poll. > On 7 Dec 2018, at 18:39, Ariel Weisberg <ar...@weisberg.ws> wrote: > > Hi, > > I think I managed to not get confused. I evaluatec the two separately. I > don't like or use environment both in terms of populating the field and > searching on it. That information could go in the description and be just as > useful to me personally. > > I have no problem with an optional platform field that is an improvement on > environment in that it is more structured and searchable. My bar for optional > fields is low. I guess I'm not convinced I want either though? If other > people find it useful then because they search on it then yes we should do a > better more structured version. > > 5 groups feature impact and platform. It's platform I think is less useful? I > am +1 on feature impacts as we have impact on things like CCM and drivers > that we need to keep track of and I do forget them at times. > > Ariel > > On Fri, Dec 7, 2018, at 1:17 PM, Benedict Elliott Smith wrote: >> >> >>> On 7 Dec 2018, at 17:52, Ariel Weisberg <ar...@weisberg.ws> wrote: >>> >>> Hi, >>> >>> Late but. >> >> No harm in them continuing to roll in, I’m just cognisant of needing to >> annoy everyone with a second poll, so no point perpetuating it past a >> likely unassailable consensus. >> >>> >>> 1. A >>> 2. +1 >>> 3. +1 >>> 4. -1 >>> 5. -0 >>> 6. +1 >>> >>> RE 4, I think blocker is an important priority. High and urgent mean the >>> same thing to me. Wish is fine, but that is too similar to low if you ask >>> me. My ideal would be low, medium, high, blocker. Medium feels weird, but >>> it's a real thing, it's not high priority and we really want it done, but >>> it's not low enough that we might skip it/not get to it anytime soon. >> >> It seems like people have really strong (and divergent) opinions about >> Priority! >> >> So, to begin: I don’t think Medium is any different to Normal, in the >> proposal? Except Normal is, well, more accurate I think? It is the >> default priority, and should be used unless strong reasons otherwise. >> >> As for Blocker vs Urgent, I obviously disagree (but not super strongly): >> Urgent conveys more information IMO. Blocker only says we cannot >> release without this. Urgent also says we must release with this, and >> ASAP. The meaning of a priority is anyway distinct from its name, and >> the meaning of Urgent is described in the proposal to make this clear. >> But, it’s easy to add a quick poll item for the top priority name. Any >> other suggestions, besides Urgent and Blocker? >> >> Of course, if we remove Priority from the Bug type, I agree with others >> that the top level priority ceases to mean anything, and there probably >> shouldn’t be one. >> >> Wish will already be included in the next poll. >> >>> RE 5. I don't think I have ever used the environment field or used the >>> contents populated in it. Doesn't mean someone else hasn't, but in terms of >>> making the easy things easy it seems like making it required isn't so high >>> value? I don't populate it myself usually I put it in the description or >>> the subject without thinking. >>> It seems like the purpose of a field is to make it indexable and possibly >>> structured. How often do we search or require structure on this field? >> >> Are you conflating this with Q6? The environment field was not >> discussed, only the potential Platform field, which we _hope_ to make a >> multi-select list. This would make the information quite useful for >> reporting and searching. >> >> Environment is being removed because it is unstructured and poorly used, >> and it looks like you have voted in favour of this? >> >> If Platform cannot be made into an editable multi-select list, we will >> probably not make it mandatory. Here we’re trying to gauge an ideal end >> state - some things may need revisiting if JIRA does not play ball, >> though that should not affect many items. >> >>> >>> Ariel >>> >>> On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith wrote: >>>> Ok, so after an initial flurry everyone has lost interest :) >>>> >>>> I think we should take a quick poll (not a vote), on people’s positions >>>> on the questions raised so far. If people could try to take the time to >>>> stake a +1/-1, or A/B, for each item, that would be really great. This >>>> poll will not be the end of discussions, but will (hopefully) at least >>>> draw a line under the current open questions. >>>> >>>> I will start with some verbiage, then summarise with options for >>>> everyone to respond to. You can scroll to the summary immediately if >>>> you like. >>>> >>>> - 1. Component: Multi-select or Cascading-select (i.e. only one >>>> component possible per ticket, but neater UX) >>>> - 2. Labels: rather than litigate people’s positions, I propose we do >>>> the least controversial thing, which is to simply leave labels intact, >>>> and only supplement them with the new schema information. We can later >>>> revisit if we decide it’s getting messy. >>>> - 3. "First review completed; second review ongoing": I don’t think we >>>> need to complicate the process; if there are two reviews in flight, the >>>> first reviewer can simply comment that they are done when ready, and the >>>> second reviewer can move the status once they are done. If the first >>>> reviewer wants substantive changes, they can move the status to "Change >>>> Request” before the other reviewer completes, if they like. Everyone >>>> involved can probably negotiate this fairly well, but we can introduce >>>> some specific guidance on how to conduct yourself here in a follow-up. >>>> - 4. Priorities: Option A: Wish, Low, Normal, High, Urgent; Option B: >>>> Wish, Low, Normal, Urgent >>>> - 5. Mandatory Platform and Feature. Make mandatory by introducing new >>>> “All” and “None” (respectively) options, so always possible to select an >>>> option. >>>> - 6. Environment field: Remove? >>>> >>>> I think this captures everything that has been brought up so far, except >>>> for the suggestion to make "Since Version” a “Version” - but that needs >>>> more discussion, as I don’t think there’s a clear alternative proposal >>>> yet. >>>> >>>> Summary: >>>> >>>> 1: Component. (A) Multi-select; (B) Cascading-select >>>> 2: Labels: leave alone +1/-1 >>>> 3: No workflow changes for first/second review: +1/-1 >>>> 4: Priorities: Including High +1/-1 >>>> 5: Mandatory Platform and Feature: +1/-1 >>>> 6: Remove Environment field: +1/-1 >>>> >>>> I will begin. >>>> >>>> 1: A >>>> 2: +1 >>>> 3: +1 >>>> 4: +1 >>>> 5: Don’t mind >>>> 6: +1 >>>> >>>> >>>> >>>> >>>>> On 29 Nov 2018, at 22:04, Scott Andreas <sc...@paradoxica.net> wrote: >>>>> >>>>> If I read Josh’s reply right, I think the suggestion is to periodically >>>>> review active labels and promote those that are demonstrably useful to >>>>> components (cf. folksonomy -> >>>>> taxonomy<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). >>>>> I hadn’t read the reply as indicating that labels should be zero’d out >>>>> periodically. In any case, I agree that reviewing active labels and >>>>> re-evaluating our taxonomy from time to time sounds great; I don’t think >>>>> I’d zero them, though. >>>>> >>>>> Responding to a few comments: >>>>> >>>>> ––– >>>>> >>>>> – To Joey’s question about issues languishing in Triage: I like the idea >>>>> of an SLO for the “triage” state. I am happy to commit time and resources >>>>> to triaging newly-reported issues, and to JIRA pruning/gardening in >>>>> general. I spent part of the weekend before last adding components to a >>>>> few hundred open issues and preparing the Confluence reports mentioned in >>>>> the other thread. It was calming. We can also figure out how to rotate / >>>>> share this responsibility. >>>>> >>>>> – Labels discussion: If we adopt a more structured component hierarchy to >>>>> treat as our primary method of organization, keep labels around for >>>>> people to use as they’d like (e.g., for custom JQL queries useful to >>>>> their workflows), and periodically promote those that are widely useful, >>>>> I think that sounds like a fine outcome. >>>>> >>>>> – On Sankalp’s question of issue reporter / new contributor burden: I >>>>> actually think the pruning of fields on the “new issue form” makes >>>>> reporting issues easier and ensures that information we need is captured. >>>>> Having the triage step will also provide a nice task queue for screening >>>>> bugs, and ensures a contributor’s taken a look + screened appropriately >>>>> (rather than support requests immediately being marked “Critical/Blocker” >>>>> and assigned a fix version by the reporter). >>>>> >>>>> – On Sankalp’s question of the non-committer’s workflow during first pass >>>>> of review, I think that’s covered here: >>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow >>>>> >>>>> ––– >>>>> >>>>> I also want to step back and thank Benedict and Kurt for all of their >>>>> analysis and information architecture work behind this proposal. >>>>> "Workflow and bug tracker hygiene” can be a thankless endeavor; I want to >>>>> make sure this one’s not. Thank you both! >>>>> >>>>> If we’re nearing consensus on “keeping labels, and considering them for >>>>> promotion to components periodically,” are there other items we need to >>>>> resolve before we generally feel good about the changes? >>>>> >>>>> – Scott >>>>> >>>>> >>>>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith >>>>> (bened...@apache.org<mailto:bened...@apache.org>) wrote: >>>>> >>>>> Hmm. On re-reading your earlier email, I realise I may have anyway gotten >>>>> confused about your suggestion. >>>>> >>>>> Are you suggesting we periodically clear any new labels, once we have >>>>> replacements, and only leave the old ones that exist today and haven’t >>>>> been categorised? >>>>> >>>>> >>>>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith <bened...@apache.org> >>>>>> wrote: >>>>>> >>>>>> Do we maintain a list of prior rejects? Revisit any that have increased >>>>>> in usage since last? >>>>>> >>>>>> Probably we’re bike shedding this one thing too closely. I would be >>>>>> happy with removing it, periodically cleaning it, or leaving it intact. >>>>>> Mining it for schema changes, or telling people to ask. >>>>>> >>>>>> But I fear it will all begin to go to pot again after this effort wanes, >>>>>> and my life has only one JIRA cleanup effort to call upon. >>>>>> >>>>>> >>>>>>> On 26 Nov 2018, at 18:24, Joshua McKenzie <jmcken...@apache.org> wrote: >>>>>>> >>>>>>> I'm thinking something like "Every 6 months, we query on labels with >>>>>>> count >>>>>>>> = 4 and consider promoting those. Anything < that only shows if people >>>>>>>> are >>>>>>> specifically looking for it." >>>>>>> >>>>>>> Taking count of occurrence of a label as a proxy for the potential >>>>>>> value in >>>>>>> promoting it to something hardened isn't without flaws, but it's also >>>>>>> not >>>>>>> awful IMO. >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith >>>>>>> <bened...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>>> Is there harm in leaving them in, aside from psychologically to all >>>>>>>>> of us >>>>>>>>> knowing they're there? =/ >>>>>>>> >>>>>>>> It would at least make it easier to triage the ‘new' ones and promote >>>>>>>> them. The pain of actually categorising the labels was high, and doing >>>>>>>> that every time would mean it never happens (though maybe there are >>>>>>>> ways to >>>>>>>> work around this). I also think there’s value in shedding noisy data, >>>>>>>> in >>>>>>>> an active process to promote good hygiene. >>>>>>>> >>>>>>>> But who said our state of mind isn’t also important :) >>>>>>>> >>>>>>>> This isn’t something I’ll fight hard for, though, I can see it’s at >>>>>>>> least >>>>>>>> partially a preference for cleanliness. Interested to see what others >>>>>>>> think. >>>>>>>> >>>>>>>>> On 26 Nov 2018, at 17:28, Joshua McKenzie <jmcken...@apache.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> An alternative route might be to support labels, and (e.g.) >>>>>>>>>> bi-annually >>>>>>>>>> promote any useful ones to the schema, and clear the rest? >>>>>>>>> >>>>>>>>> +1 to promoting, probably should case-by-case the clearing (but mostly >>>>>>>> just >>>>>>>>> clear) >>>>>>>>> >>>>>>>>> The present labels are much too painful to clean up. I categorised the >>>>>>>> top >>>>>>>>>> 100 or so, and will migrate them (there’s a CSV embedded in the >>>>>>>>>> proposal >>>>>>>>>> you can look at). The rest have < 5 occurrences, so I cannot see what >>>>>>>>>> value they really provide us. >>>>>>>>> >>>>>>>>> Is there harm in leaving them in, aside from psychologically to all >>>>>>>>> of us >>>>>>>>> knowing they're there? =/ >>>>>>>>> >>>>>>>>> I _think_ several of your concerns are addressed by the new Triage >>>>>>>>> state. >>>>>>>>>> The idea is for users to create a ticket without any field >>>>>>>>>> requirements. >>>>>>>>>> Contributors should liaise with the user to understand the problem, >>>>>>>>>> and >>>>>>>>>> transition it to Open. >>>>>>>>> >>>>>>>>> Shit, my bad, totally missed / didn't grok that. That makes a lot more >>>>>>>>> sense. >>>>>>>>> >>>>>>>>> On Mon, Nov 26, 2018 at 11:58 AM Benedict Elliott Smith < >>>>>>>> bened...@apache.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry, I failed to respond to point (2) in the aggregate email. >>>>>>>>>> >>>>>>>>>> I’m not sure it’s worth complicating the flow for this scenario, as >>>>>>>>>> the >>>>>>>>>> ticket can simply return to ‘Patch Available’. But, I’m really unsure >>>>>>>> of >>>>>>>>>> the best option here. Does anyone else have any strong opinions / >>>>>>>> thoughts? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 26 Nov 2018, at 14:33, Sankalp Kohli <kohlisank...@gmail.com> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I have following initial comments on the proposal. >>>>>>>>>>> 1. Creating a JIRA should have few fields mandatory like platform, >>>>>>>>>> version, etc. We want to put less burden on someone creating a ticket >>>>>>>> but I >>>>>>>>>> feel these are required for opening bugs. >>>>>>>>>>> >>>>>>>>>>> 2. What is the flow when a non committer does the first pass of >>>>>>>>>>> review? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie <jmcken...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 1) Removal of labels: one of the strengths of the current model is >>>>>>>>>>>> flexibility for groupings of concepts to arise from a >>>>>>>>>>>> user-perspective >>>>>>>>>>>> (lhf, etc). Calcifying the label concepts into components, >>>>>>>>>>>> categories, >>>>>>>>>> etc. >>>>>>>>>>>> is a strict loss of functionality for users to express and >>>>>>>>>>>> categorize >>>>>>>>>> their >>>>>>>>>>>> concerns with the project. This feels like an over-correction to >>>>>>>>>>>> our >>>>>>>>>>>> current lack of discipline cleaning up one-off labels. >>>>>>>> Counter-proposal: >>>>>>>>>>>> >>>>>>>>>>>> 1. We beef up the categories and components as proposed and migrate >>>>>>>>>>>> labels to those >>>>>>>>>>>> 2. We remove the one-off labels that aren't adding value, >>>>>>>>>>>> considering >>>>>>>>>>>> aggregating similar labels >>>>>>>>>>>> 3. We leave the "labels" field intact, perhaps with a bit of >>>>>>>>>>>> guidance >>>>>>>>>> on >>>>>>>>>>>> how to effectively use it >>>>>>>>>>>> >>>>>>>>>>>> 2) Required fields on transition: assuming these are required upon >>>>>>>>>> *issue >>>>>>>>>>>> creation*, that's placing a significant burden on a user that's >>>>>>>>>>>> seen >>>>>>>>>>>> something and wants to open a ticket about it, but isn't sure if >>>>>>>>>>>> it's >>>>>>>> a >>>>>>>>>>>> "Semantic Failure" or a "Consistency Failure", for instance. If >>>>>>>>>>>> this >>>>>>>> is, >>>>>>>>>>>> instead, a field required for transition to other ticket states by >>>>>>>>>>>> the >>>>>>>>>>>> developer working on it, I think that makes sense. >>>>>>>>>>>> >>>>>>>>>>>> 3) Priority Changes: to be blunt, this looks like shuffling chairs >>>>>>>>>>>> on >>>>>>>>>> the >>>>>>>>>>>> deck of the titanic on this one - in my experience, most users >>>>>>>>>>>> aren't >>>>>>>>>> going >>>>>>>>>>>> to set the priority on tickets when they open them (hence default >>>>>>>>>>>> == >>>>>>>>>> major >>>>>>>>>>>> and most tickets are opened as major), so this is something that >>>>>>>>>>>> will >>>>>>>> be >>>>>>>>>>>> either a) left alone so as not to offend those for whom the >>>>>>>>>>>> priority >>>>>>>> is >>>>>>>>>>>> *actually* major or consistent with the default, or b) changed by >>>>>>>>>>>> the >>>>>>>>>> dev >>>>>>>>>>>> anyway and the added signal from a new "High vs. Urgent" >>>>>>>>>>>> distinction >>>>>>>> and >>>>>>>>>>>> communication of developer intent to engage with a ticket is >>>>>>>>>>>> something >>>>>>>>>>>> that'll be lost on most users that are just reporting something. I >>>>>>>> don't >>>>>>>>>>>> have a meaningful counter-proposal at this point as the current >>>>>>>> problem >>>>>>>>>> is >>>>>>>>>>>> more about UX on this field than the signal / noise on the field >>>>>>>> itself >>>>>>>>>> IMO. >>>>>>>>>>>> >>>>>>>>>>>> A meta question about the "What and Why" of what we're trying to >>>>>>>>>> accomplish >>>>>>>>>>>> here: it sounds like what you're looking at is: >>>>>>>>>>>> >>>>>>>>>>>> 1. to capture more information >>>>>>>>>>>> 2. simplify the data entry >>>>>>>>>>>> 3. nudge people towards more complete and accurate data entry >>>>>>>>>>>> 4. our ability as a project to measure release quality over time >>>>>>>>>>>> and >>>>>>>>>>>> identify when Cassandra is ready for (or due a) release. >>>>>>>>>>>> >>>>>>>>>>>> The proposal in its current form makes certain strong inroads in >>>>>>>>>>>> all >>>>>>>> of >>>>>>>>>>>> those 4 metrics, but I think the major thing missing is the UX of >>>>>>>>>>>> what >>>>>>>>>>>> we're thinking about changing: >>>>>>>>>>>> >>>>>>>>>>>> 1. Making it easy for / reduce friction for users to report bugs >>>>>>>>>>>> and >>>>>>>>>>>> requests into the project JIRA (easy to do things right, hard to do >>>>>>>>>> things >>>>>>>>>>>> wrong) (current proposal is a +1 on "do things right", though I'd >>>>>>>> argue >>>>>>>>>>>> against it being *easy*) >>>>>>>>>>>> 2. Asking from the users what they can provide about their >>>>>>>>>>>> experience >>>>>>>>>>>> and issues and no more >>>>>>>>>>>> >>>>>>>>>>>> Philosophically, are we trying to make it easier for people that >>>>>>>>>>>> are >>>>>>>>>> paid >>>>>>>>>>>> FT to work on C*, are we trying to make things easier for *users* >>>>>>>>>>>> of >>>>>>>> C*, >>>>>>>>>>>> both, neither? Who are we targeting here w/these project changes >>>>>>>>>>>> and >>>>>>>>>> what >>>>>>>>>>>> of their issues / problems are we trying to improve? >>>>>>>>>>>> >>>>>>>>>>>> And lastly: the TLC and management of the JIRA aspects of this >>>>>>>>>>>> project >>>>>>>>>> have >>>>>>>>>>>> *definitely* languished (not pointing any fingers here, I'm *at >>>>>>>>>>>> least* >>>>>>>>>> as >>>>>>>>>>>> guilty as anyone on this :) ) - so a big thanks to you and whomever >>>>>>>>>> you've >>>>>>>>>>>> collaborate with in getting this conversation started! >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith < >>>>>>>>>> bened...@apache.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> We’ve concluded our efforts to produce a proposal for changes to >>>>>>>>>>>>> the >>>>>>>>>> JIRA >>>>>>>>>>>>> workflow, and they can be found here: >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals >>>>>>>>>>>>> < >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I hope there will be broad consensus, but I’m sure it won’t be >>>>>>>>>>>>> plain >>>>>>>>>>>>> sailing. It would be great to get a discussion going around the >>>>>>>>>> proposal, >>>>>>>>>>>>> so please take some time to read and respond if you think you’ll >>>>>>>> have a >>>>>>>>>>>>> strong opinion on this topic. >>>>>>>>>>>>> >>>>>>>>>>>>> There remains an undecided question in our initial proposal, that >>>>>>>>>>>>> is >>>>>>>>>>>>> highlighted in the wiki. Specifically, there was no seemingly >>>>>>>>>> objective >>>>>>>>>>>>> winner for the suggested changes to Component (though I have a >>>>>>>>>> preference, >>>>>>>>>>>>> that I will express in the ensuing discussion). >>>>>>>>>>>>> >>>>>>>>>>>>> Other contentious issues may be: >>>>>>>>>>>>> - The removal of ‘labels’ - which is very noisy, the vast >>>>>>>>>>>>> majority of >>>>>>>>>>>>> which provide no value, and we expect can be superseded by other >>>>>>>>>> suggestions >>>>>>>>>>>>> - The introduction of required fields for certain transitions, >>>>>>>>>>>>> some >>>>>>>> of >>>>>>>>>>>>> which are new (complexity, severity, bug/feature category) >>>>>>>>>>>>> - The introduction of some new transitions (Triage, Review in >>>>>>>> Progress, >>>>>>>>>>>>> Change Requested) >>>>>>>>>>>>> >>>>>>>>>>>>> Look forward to hearing your thoughts! >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>> >>> >>> --------------------------------------------------------------------- >>> 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 >
