1: A 2: +1 3: +1 4: +1 5: Meh. +0 6: +1 On Wed, Dec 5, 2018 at 2:57 PM Jonathan Haddad <j...@jonhaddad.com> wrote:
> My personal preference is to remove labels, but I don't see it as a huge > issue if they stay. > > 1. A > 2. prefer to remove (I suppose I'm a -.1?) > 3. +1 > 4. +1 > 5. No preference > 6. +1 > > > > On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID > <jay.zhu...@yahoo.com.invalid> wrote: > > > 1: Component. (A) Multi-select > > 2: Labels: leave alone +1 > > 3: No workflow changes for first/second review: +1 > > 4: Priorities Including High: -1 > > 5: Mandatory Platform and Feature: +1 > > 6: Remove Environment field: +1 > > > > On Wednesday, December 5, 2018, 2:58:21 AM PST, Benedict Elliott > Smith > > <bened...@apache.org> wrote: > > > > Thanks for the feedback and further questions. I’m sure there will be > > more, particularly around permissions and roles, so it’s good to get some > > of these other discussions moving. > > > > No doubt we’ll do a second poll once the first one concludes. Please, > > everyone, keep your first poll answers coming! > > > > > On 5 Dec 2018, at 09:50, Sylvain Lebresne <lebre...@gmail.com> wrote: > > > > > > Thanks for all those that contributed to the proposal, and specifically > > to > > > Benedict for leading the discussion. > > > > > > On the general proposal, I suspect there is a few details we may have > to > > > tweak going forward, but hard to be sure before trying and as I do > think > > > it's progress, I'm personally happy to move forward with this. But for > > the > > > sake of discussions, a minor remarks that I don't think have been > > mentioned > > > above: > > > - at least the platform and feature fields will be moving targets (the > > > features hopefully more so than the platform, but new java version gets > > > release regularly for instance). Do we know technically if we can get > > those > > > easily updated without requiring an infra JIRA ticket? > > > > This is actually a really good question. I had assumed this would be > > treated much like Component, Version, etc > > > > However, I was wrong: > > > > > https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311 > > < > > > https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311 > > > > > > > There are some possible workarounds, but none of them seem great. > There’s > > a plugin, but not sure if Infra would be OK with this: > > > https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview > > < > > > https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview > > > > > > > This is potentially a real blocker for these two fields. > > > > So, for feature an alternative is to merge Feature/[Feature] into > > Component. This would implicitly make it non-mandatory, however. This > > could potentially be fixed with a custom field validator, but this might > > need a plugin. > > > > For Platform, I don’t have a good alternative idea right now. This is > > something that is best curated, but definitely needs to be easily > updated. > > > > > > > - I'd personally probably remove the condition of being "jira > > contributor" > > > to move tickets out of triage. Being a "jira contributor" is a pretty > > > arbitrary in practice. Anyone that ever asked has been added, no > question > > > asked, but it can actually be annoying to get added if no-one that > knows > > > how to do it is around. So if, as I assume, the goal is to ensure that > > > fields are properly fielded, I don't think it will help much, and so I > > > suspect it would just be an annoyance to new, not-yet-"jira > contributor" > > > users that are willing to fill all the required fields seriously (but > > will > > > see their ticket stuck in triage until they either get added, or some > > other > > > random user flip the switch). And why assume people will mis-field > > stuffs? > > > So I'd vote for just letting anyone transition out of triage as long as > > all > > > required field are there. Side-note: fwiw, I'd very much be in favor of > > > removing the "jira contributor" concept for the reasons exposed above: > I > > > never felt it was anything else than an hindrance. > > > > I realise we have no real barrier to becoming a contributor, and that > many > > of these permissions are going to have limited impact. But I think a > > really easy to jump gate can still be helpful, and I don’t recall > > contributors overstepping their role. But this isn’t a critical point, > and > > it would be great to hear other’s opinions. > > > > > - Once we have 'complexity' and 'severity', I'm not entirely sure what > > > 'priority' really means in a voluntary-based project? Is it the > > gut-feeling > > > for how useful the ticket is of whomever triage the ticket? If that, > > > outside of not being convinced of the value, I'd argue that 1) it > doesn't > > > make sense for bugs and 2) it's sufficiently imprecise that it's imo > > worth > > > keeping it simple, something like low/normal/high ought to be enough. > If > > > it's not that, then what is it, cause it's genuinely not immediately > > > obvious to me? > > > > Well, if nothing else Priority is the thing I sort my outstanding work > by, > > and for this reason I have a preference for it being present for all > ticket > > types. But I do see your point. > > > > In particular, Urgent probably is something we’re only likely to use for > > critical bugs. It’s possible we could even automatically populate this > for > > a Bug type, and potentially not show this option for non-bugs. But I > > suspect we would need something like the ScriptRunner plugin for this. > > > > In my view Priority is essentially Low or Normal (or Urgent if critical > > bug) on initial filing. But a High priority can be set by a contributor > > who particularly values the ticket, for their own work prioritisation. > > Wish is a priority to make room for the Wish ticket type we are removing, > > and for those occasional requests that come in that have no realistic > > timeline for being addressed. > > > > > > > > > > And with that, my poll results: > > > 1:A > > > 2:+1 > > > 3:+1 > > > 4:Don't mind > > > 5:Don't mind > > > -- > > > Sylvain > > > > > > > > > On Tue, Dec 4, 2018 at 8:12 PM Benedict Elliott Smith < > > bened...@apache.org> > > > 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 > > >> > > >> > > > > > > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade >
