Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 8D60E200C83 for ; Sun, 14 May 2017 05:06:51 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 8BD81160BC6; Sun, 14 May 2017 03:06:51 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A9D35160BBB for ; Sun, 14 May 2017 05:06:50 +0200 (CEST) Received: (qmail 96509 invoked by uid 500); 14 May 2017 03:06:49 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 96498 invoked by uid 99); 14 May 2017 03:06:49 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 May 2017 03:06:49 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id C330DCA8C2 for ; Sun, 14 May 2017 03:06:48 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id hYRYk-vVmyYT for ; Sun, 14 May 2017 03:06:45 +0000 (UTC) Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 2A5DB5F520 for ; Sun, 14 May 2017 03:06:44 +0000 (UTC) Received: by mail-qt0-f171.google.com with SMTP id c13so10976783qtc.1 for ; Sat, 13 May 2017 20:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5tqDkKl/BX/WZj0ltOdIoCDfD5X3r5VuEISwlq9/BO4=; b=aJ0KIAGQSEHtvCayFGAxHjzJbKbv+NXIxh5/wFSWRsBUtuvGOzxCa9sW6ixPrdidyH +rJrm9IXHA2w/3VpsFbr7iAz12fyYV8BSTgWsEXV3egCitvo8YzEmFAjcetef6SVUEyL Kli2dxW2viZdTFt8p+u3bX4KyHNZNm4yEf4JIKSbgYSOQ5m1yOAVVg5uaTbDUwmB5OsA bkbRjXttVghhN/DgZjFPFamWrGtb9y9AMVw6vweoN6m0PTdRuF3brBjgxKV1w9XbiNRc rTMa4gvyHs/5dfDdPfjHfMA19gBEypDawASTzktd/4goFGqijvHVVA3m1kLMo3ki2Hwh mvqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5tqDkKl/BX/WZj0ltOdIoCDfD5X3r5VuEISwlq9/BO4=; b=J4OIXdx/2yiOkOKNylO9LmZDwqczfluSb/qplf/IylNrp4FFheeuaeboaYK9bf3R5P dwqQjkaD2tilCG/jhi9YFOE4O5uzn5VZNM3WsTd4uIz1lxbdijKWXlqF6FmwI5MYZzHo oo8SHesV5i0IGH++iZ8hMX9nnG0RRR7MtPIyf5wnrizjxAK9xBfKJiNJqtYlEul5jYWS +PZujKDVQ89J2SfBcjDfzS5bKsuf2KJR8mB/r1XT0yxubzwRS74BpF1PtU+MHzweCu77 2+WTuzGvEdsCHLKuL02yPwC5xQFG7mNrQu2tOGaXj1UyoH/ARYY3VNWaePkTnh+iMNLy oWZw== X-Gm-Message-State: AODbwcBktbGCbrYEvNl2L/37bE4Mp7kxs8zZmC3SZ1nZnXgJcl5hPzEd wUU6Q/ObsHk3VVJOLDfEW7SxjIj6QWzJ X-Received: by 10.200.9.76 with SMTP id z12mr2296496qth.102.1494731202870; Sat, 13 May 2017 20:06:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Smiley Date: Sun, 14 May 2017 03:06:32 +0000 Message-ID: Subject: Re: JIRA Status - Finding Patch Submissions To: dev@lucene.apache.org Content-Type: multipart/alternative; boundary="001a1145759861c0ae054f733a9e" archived-at: Sun, 14 May 2017 03:06:51 -0000 --001a1145759861c0ae054f733a9e Content-Type: text/plain; charset="UTF-8" Thanks for researching the state of our JIRA issues and summarizing the situation for us. > Patch Available JIRA state +1 > We should also consider running unit tests as part of the process. +1 That'd be cool! Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic. > Apache Yetus I'm not sure what to make of it... perhaps you can make a specific proposal. ~ David On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre wrote: > >>For current patches, I think we could really benefit from a Patch > Available JIRA state. It would be a bright big flag for committers, instead > of making contributors have to hound us periodically to look. Additionally, > we could use that to start running precommit checks on Jenkins whenever a > new patch is put up. See Apache Yetus for how this might work. > > +1. We should also consider running unit tests as part of the process. > > > On Thu, May 11, 2017 at 1:54 PM, Mike Drob wrote: > >> Wanted to follow up on this, since I've been steadily working away at old >> JIRA issues when I have some time for them. I think read through 100s of >> issues and closed about 20 as either duplicates or already committed, which >> is a tiny drop in the ocean of what we have open. In an attempt to cut the >> task to a more manageable size, I only looked at Solr issues. >> >> I'd like to adjust my earlier statement that most of the attachments are >> patches. Most of the really old attachments are patches, the mid-age ones >> are bug reports (indices, screen captures, logs) and the recent ones being >> actively worked are patches again. So, the situation isn't as bad as I >> imagined it at first. For a lot of these old issues, there's not much to be >> done going forward. I don't expect to have much traction asking >> contributors to rebase their patches from 1.x, 3.x or even 4.x onto the >> current code line, and without that many of them are just unworkable. >> >> For current patches, I think we could really benefit from a Patch >> Available JIRA state. It would be a bright big flag for committers, instead >> of making contributors have to hound us periodically to look. Additionally, >> we could use that to start running precommit checks on Jenkins whenever a >> new patch is put up. See Apache Yetus for how this might work. >> >> Is there interest in the community for this path? I'm personally a big >> fan of enabling static analysis and always like to explore ways to improve >> in that area. >> >> Mike >> >> On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey >> wrote: >> >>> On 4/28/2017 9:42 AM, Mike Drob wrote: >>> > Thanks for this hint, Alex. >>> > >>> > I ran the following JQL to get some idea of our current status: >>> > project in (lucene, solr) and "Attachment count" > 0 and status = >>> Open >>> > >>> > There were 1500 results. >>> > >>> > 1500. I couldn't believe it. This is a huge number of patches that are >>> > out there. >>> > >>> > I did a spot check, thinking that a lot of these might be bug reports >>> > with error logs or screen shots attached, but nope. These are mostly >>> > patches. I'm going to try starting with the oldest ones to see if they >>> > can be rebase, have already been committed, or generally try to triage >>> > them. Would appreciate any volunteers that want to help. >>> >>> This doesn't surprise me at all. Many users submit patches for issues >>> they encounter, but for one reason or another, no committer action ever >>> happens. There are many possible reasons. >>> >>> 1) The patch has bugs or some other problem that makes it unacceptable. >>> 2) When the issue/patch is reviewed, one of these situations exists: >>> a) Committers don't think it's worth pursuing. >>> b) The code is behaving as designed. >>> c) The committer cannot reproduce the problem. >>> d) The committer doesn't understand the problem. >>> e) The committer doesn't think it's actually a problem. >>> f) A workaround exists that is just as effective as the patch. >>> 3) Nobody has had time to review the issue/patch. >>> >>> In some of these situations, the reviewing committer should probably >>> close the issue with an appropriate reason ... but issue triage is a >>> difficult and unrewarding job. Sometimes it just doesn't happen. >>> >>> Thanks, >>> Shawn >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org >>> For additional commands, e-mail: dev-help@lucene.apache.org >>> >>> >> > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com --001a1145759861c0ae054f733a9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for researching the state of our JIRA issues a= nd summarizing the situation for us.

>=C2=A0Patch Av= ailable JIRA state

+1

>= =C2=A0We should also conside= r running unit tests as part of the process.

+1 That'd be cool!=C2=A0 Hopefully without generating comments that t= rigger email/watcher notifications and thus no more dev list traffic.

> Apache Yetus

I'm = not sure what to make of it... perhaps you can make a specific proposal.

~ David

On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre <gadre.solr@gmail.com> wrote:
>>For current patches, I think we could really benefit from= a Patch Available JIRA state. It would be a bright big flag for committers= , instead of making contributors have to hound us periodically to look. Add= itionally, we could use that to start running precommit checks on Jenkins w= henever a new patch is put up. See Apache Yetus for how this might work.

+1. We should also consider = running unit tests as part of the process.


On Thu, May 11, 2017 at 1:54 PM, Mike Drob <mdrob@a= pache.org> wrote:
Wanted to follow up on this, since I've been steadily working = away at old JIRA issues when I have some time for them. I think read throug= h 100s of issues and closed about 20 as either duplicates or already commit= ted, which is a tiny drop in the ocean of what we have open. In an attempt = to cut the task to a more manageable size, I only looked at Solr issues.
I'd like to adjust my earlier statement that most of t= he attachments are patches. Most of the really old attachments are patches,= the mid-age ones are bug reports (indices, screen captures, logs) and the = recent ones being actively worked are patches again. So, the situation isn&= #39;t as bad as I imagined it at first. For a lot of these old issues, ther= e's not much to be done going forward. I don't expect to have much = traction asking contributors to rebase their patches from 1.x, 3.x or even = 4.x onto the current code line, and without that many of them are just unwo= rkable.

For current patches, I think we could real= ly benefit from a Patch Available JIRA state. It would be a bright big flag= for committers, instead of making contributors have to hound us periodical= ly to look. Additionally, we could use that to start running precommit chec= ks on Jenkins whenever a new patch is put up. See Apache Yetus for how this= might work.

Is there interest in the community fo= r this path? I'm personally a big fan of enabling static analysis and a= lways like to explore ways to improve in that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <apache@elyograg.org&= gt; wrote:
On 4/28/2017 9:42= AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>=C2=A0 =C2=A0 =C2=A0project in (lucene, solr) and "Attachment coun= t" > 0 and status =3D Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that= are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports<= br> > with error logs or screen shots attached, but nope. These are mostly > patches. I'm going to try starting with the oldest ones to see if = they
> can be rebase, have already been committed, or generally try to triage=
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.=C2=A0 Many users submit patches= for issues
they encounter, but for one reason or another, no committer action ever
happens.=C2=A0 There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
=C2=A0a) Committers don't think it's worth pursuing.
=C2=A0b) The code is behaving as designed.
=C2=A0c) The committer cannot reproduce the problem.
=C2=A0d) The committer doesn't understand the problem.
=C2=A0e) The committer doesn't think it's actually a problem.
=C2=A0f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.=C2=A0 Sometimes it just doesn't happen.<= br>
Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org



--
Lucene/Solr Search Committer, Consultan= t, Developer, Author, Speaker
--001a1145759861c0ae054f733a9e--