Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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.

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

> 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

Re: JIRA Workflow Proposals

> > 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

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

Thanks Jo for the feedback too! I’ll keep my responses brief as there are already a lot of discussions in flight. > On 26 Nov 2018, at 16:24, Joseph Lynch wrote: > > Benedict, > > Thank you for putting this document together, I think something like this > will really improve the quality and

Re: JIRA Workflow Proposals

Thanks everyone for the quick initial feedback! I’m going to aggregate my responses here, to try and avoid too much fragmentation of discussion; we’ll see how sensible this is. ===Labels=== I’m not irreconcilably against keeping labels, I just think on balance it’s better to remove them. I

Re: JIRA Workflow Proposals

Benedict, Thank you for putting this document together, I think something like this will really improve the quality and usefulness of the Jira tickets! A few pieces of overall feedback on the proposal: * I agree with Jeremy and Joshua on keeping labels. Labels are the only way that contributors

Re: JIRA Workflow Proposals

Regarding labels, I am personally a fan of both - the mapping of commonly used labels to things like components, features, tools, etc. as well as keeping labels for newer and more arbitrary groupings. I’ve tried to maintain certain labels like virtual-tables, lcs, lwt, fqltool, etc because

Re: JIRA Workflow Proposals

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

Re: JIRA Workflow Proposals

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

JIRA Workflow Proposals

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 I hope there will be

Re: Inter-node messaging latency

Inter-node messaging is rewritten using Netty in 4.0. It will be better to test it using that as potential changes will mostly land on top of that. On Mon, Nov 26, 2018 at 7:39 AM Yuji Ito wrote: > Hi, > > I'm investigating LWT performance with C* 3.11.3. > It looks that the performance is