From dev-return-359179-archive-asf-public=cust-asf.ponee.io@lucene.apache.org Fri Jun 14 21:30:03 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4C30F18062F for ; Fri, 14 Jun 2019 23:30:03 +0200 (CEST) Received: (qmail 29290 invoked by uid 500); 14 Jun 2019 21:30:01 -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 29226 invoked by uid 99); 14 Jun 2019 21:30:00 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Jun 2019 21:30:00 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 8DA4B1A4746 for ; Fri, 14 Jun 2019 21:29:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.811 X-Spam-Level: * X-Spam-Status: No, score=1.811 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_FROM_NAME_FREEMAIL=0.01, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id YRAg9NFsS43b for ; Fri, 14 Jun 2019 21:29:58 +0000 (UTC) Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com [209.85.160.195]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id C3A715F524 for ; Fri, 14 Jun 2019 21:29:57 +0000 (UTC) Received: by mail-qt1-f195.google.com with SMTP id s15so4158639qtk.9 for ; Fri, 14 Jun 2019 14:29:57 -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=QdHW2+OYu3K8LGB0EkwUZaVRNlGjJ71iQiZZ7Ux5Uxs=; b=MVi3C8DC/W9cUgvXXevlzxJIrM1+Ft/S6paOTD1QoGHtqqfUhiTBA9FBuZmCuSY10y mumwo88tjnmSjXMn8KIJNucddxj6qEYOb11RVOu+VGBwVBSJwuSDHrBRl8GBTIeBIVGM y/3PYAaxWgqns9/MQNVdCbJnrpkwJ+MAr1bITi6PHHEeWSSAHZsxUMgmOFud1A6KvDh2 be03/zzfHJgGT93YwNoTNFvAsI1Qnctl3XH+jE+DDGqX6SXUkPp5uj3FNziRAYagy/7b +zJstdanJLGEqOqTLe9XZS16rFvfeQdbzMiNDh8Vzdu6g93RJzouiaYU06Z1/14i+pas SrWA== 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=QdHW2+OYu3K8LGB0EkwUZaVRNlGjJ71iQiZZ7Ux5Uxs=; b=WGBNHjaS1RnNqYdeJGYkRxYOBqBfdCcV78GMaR/KMeQvMnvFAywHJ6RJS2r68VhVBj 0l4T5V8BnP9vZ6H2cDim3ob0kJBAdUseWksW2xc9MzRm3m3TmaKjYup3j4YT/5it1CeG dml1SQZfvUNnRbXNDOXAtUvk+hbNgLSJbAbOlvVQuW4pE8h6fKp72NNikBZYu1S5R17X jooULQ9KsTu2bnoK+PvU9QmCLzSjC0+0H+cbvuP/4EkkwzcglUdCCWIAlxqnspO70b51 2wkYDM57rTx3XuanQdcE85vqXc8BcDIUWaWhcfBKEU7ku8fozOQPG2boe/oMtmVqZ9aS NYww== X-Gm-Message-State: APjAAAVWZZxemK3kuDKdxi+gDGFWTujzWYI5xhhqK19bDW7ire/LOkrP gSijm+P56ONhZmP7B0WAi5Rwtz5mPb343HqsV2V58I+n X-Google-Smtp-Source: APXvYqzveBUNvPhDVc6dcyoLJ1drerNOqh3u9AvBQ4xM1R7aDrfKKDDQVvkQVSmtC1N1Upg3jrMUWltsp5rW+EjYqAo= X-Received: by 2002:a0c:9305:: with SMTP id d5mr10455003qvd.83.1560547797107; Fri, 14 Jun 2019 14:29:57 -0700 (PDT) MIME-Version: 1.0 References: <81C4D75F-5F4C-4284-A2FD-65C79854B82B@cominvent.com> <5BF40764-81F4-443E-8216-954A83572EA2@gmail.com> <1833B6BC-B1F0-46C7-B80B-29B576DA2F6D@gmail.com> <312A5169-ADF1-46FA-8D8F-E291D17D2CCE@cominvent.com> In-Reply-To: From: Gus Heck Date: Fri, 14 Jun 2019 17:29:45 -0400 Message-ID: Subject: Re: Use of JIRA fixVersion To: dev Content-Type: multipart/alternative; boundary="0000000000001a07bd058b4f59fc" --0000000000001a07bd058b4f59fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW I tend to agree with Erick here on both his points, but the second one more strongly than the first. The first I can live with either way really so long as it's clearly documented somewhere (besides this thread). If we don't update the changes in master for bug fixes when we're committing, who's going to go collect and add them later? I'm not sure I'm that big a fan of generating changes... I haven't looked at Yetus specifically but I suspect that this will just leave us with the title from the Jira, and often some additional detail for changes is worthwhile beyond what the title says. So if we create a field in Jira that is the Changes text, and make it required in the resolution screen fine to generate from that, but I think there's real value in the current system because you wind up writing a final short 1-4 line summary focused on "what the user needs to know" Also line 3, the feature only in 8x (but not master) is a very odd case in that table, I'm not sure when that would happen? could happen for a bug that is fixed by other changes in master, but for a feature? Also if we aren't marking branches explicitly maybe the 9.0 (master) tag should say 9.0 (unreleased)? Sure most developers know master is typically unreleased, but why add that mental leap. It's possible that someone less technical, or who is a student will stumble in from a link on SO... -Gus On Thu, Jun 13, 2019 at 3:23 PM David Smiley wrote: > +1 to your plan Jan. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Thu, Jun 13, 2019 at 8:40 AM Jan H=C3=B8ydahl = wrote: > >> Trying to reach a conclusion (or perhaps a vote) on this. >> >> Here is a table that sums up my proposal. Basically it means in most >> cases stop adding master as fixVersion. >> >> Type Committed to fixVersion CHANGES.txt section >> Feature master master (9.0) 9.0 >> Feature master, branch_8x 8.2 8.2 >> Feature branch_8x 8.2 8.2 >> Bugfix master master (9.0) none (unreleased bug) >> Bugfix master, branch_8x 8.2 8.2 >> Bugfix master, branch_8x, branch_8_1 8.1.2, 8.2 8.1.2, 8.2 >> Bugfix branch_8x 8.2 8.2 >> Bugfix branch_8_1 8.1.2 8.1.2 >> Bugfix branch_8x, branch_7_7 7.7.3, 8.2 7.7.3, 8.2 >> >> In addition to this, we should all wait until commit time with setting >> fixVersion. >> >> To find branches for a JIRA, you just translate fixVersion to branch, >> e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x. >> For features, if it is unclear whether master has the commit, check >> gitbot log or git log >> For bugfixes, there are cases where the bug does not exist in master at >> all, and that can be reflected in affectsVersion field. >> >> -- >> Jan H=C3=B8ydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> 3. jun. 2019 kl. 19:56 skrev David Smiley : >> >> Right.... JIRA fixVersion has its use, and that would satisfy this >> use-case? It's what Jan proposes to do this very thing as part of >> generating release notes in a semi-automated way. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson >> wrote: >> >>> >>> >>> > On Jun 3, 2019, at 6:41 AM, David Smiley >>> wrote: >>> > >>> > If someone wants to know what branches an issue was committed to, the= n >>> review the bot comments to find out. >>> >>> What if I want to form a query that shows me all JIRAs fixed in version >>> X.Y.Z? >>> >>> A bot comments with =E2=80=9Cbranch_5x=E2=80=9D doesn=E2=80=99t tell me= which minor version it=E2=80=99s >>> in, 5.1? 5.5? >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org >>> For additional commands, e-mail: dev-help@lucene.apache.org >>> >>> >> --=20 http://www.needhamsoftware.com (work) http://www.the111shift.com (play) --0000000000001a07bd058b4f59fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW I tend to agree with Erick here on both his points, b= ut the second one more strongly than the first. The first I can live with e= ither way really so long as it's clearly documented somewhere (besides = this thread).=C2=A0

If we don't update the changes i= n master for bug fixes when we're committing, who's going to go col= lect and add them later? I'm not sure I'm that big a fan of generat= ing changes... I haven't looked at Yetus specifically but I suspect tha= t this will just leave us with the title from the Jira, and often some addi= tional detail for changes is worthwhile beyond what the title says. So if w= e create a field in Jira that is the Changes text, and make it required in = the resolution screen fine to generate from that, but I think there's r= eal value in the current system because you wind up writing a final short 1= -4 line summary focused on "what the user needs to know"=C2=A0
Also line 3, the feature only in 8x (but not master) is a = very odd case in that table, I'm not sure when that would happen? could= happen for a bug that is fixed by other changes in master, but for a featu= re?=C2=A0

Also if we aren't marking branches e= xplicitly maybe the 9.0 (master) tag should say 9.0 (unreleased)? Sure most= developers know master is typically unreleased, but why add that mental le= ap. It's possible that someone less technical, or who is a student will= stumble in from a link on SO...

-Gus
<= /div>
O= n Thu, Jun 13, 2019 at 3:23 PM David Smiley <david.w.smiley@gmail.com> wrote:
+1 to your plan J= an.

~ David S= miley
Apache Lucene/Solr Search Developer


=
On Thu, Ju= n 13, 2019 at 8:40 AM Jan H=C3=B8ydahl <jan.asf@cominvent.com> wrote:
Trying to reach a conclusion (or perhaps a vote) on this.
Here is a table that sums up my proposal. Basically it mea= ns in most cases stop adding master as fixVersion.

= =
TypeCommitted to= fixVersionCHANGES.txt section
Featuremastermaster (9.0)9.0
Featuremaster, branch_8x8.28.2
Featurebranch_8x8.28.2
Bugfixmasternone (unreleased bug)
Bugfixmaster, branch_8x8.28.2
Bugfixmaster, branch_8x, = branch_8_18.1.2, 8.28.1.2, 8.2
Bugfixbranch_8x8.28.2
Bugfix= branch_8_18.1.28.1.2
Bug= fixbranch_8x, branch_7_77.7.3, 8.27.7.3, 8.2

In addition to this, we should al= l wait until commit time with setting fixVersion.

= To find branches for a JIRA, you just translate fixVersion to branch, e.g. = 8.1.2, 8.2 -> branch_8_1, branch_8x.=C2=A0
For features, if it= is unclear whether master has the commit, check gitbot log or git log
For bugfixes, there are cases where the bug does not exist in master = at all, and that can be reflected in affectsVersion field.

--
Jan H=C3=B8ydahl, search solution architect
Cominven= t AS - www.cominvent= .com

3. jun. 2019 kl. 19:56 skrev David = Smiley <da= vid.w.smiley@gmail.com>:

Right.... JIRA fixVersion has its use, and that would satisfy this use-= case?=C2=A0 It's what Jan proposes to do this very thing as part of gen= erating release notes in a semi-automated way.

<= div dir=3D"ltr" class=3D"gmail-m_-3807406631453929349gmail-m_31168895835210= 51054gmail_signature">
~ David Smiley=
Apache Lucene/Solr Search Developer


On Mon, Jun 3, = 2019 at 11:38 AM Erick Erickson <erickerickson@gmail.com> wrote:


> On Jun 3, 2019, at 6:41 AM, David Smiley <david.w.smiley@gmail.com> wrote= :
>
> If someone wants to know what branches an issue was committed to, then= review the bot comments to find out.

What if I want to form a query that shows me all JIRAs fixed in version X.Y= .Z?

A bot comments with =E2=80=9Cbranch_5x=E2=80=9D doesn=E2=80=99t tell me whi= ch minor version it=E2=80=99s in, 5.1? 5.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org




--
--0000000000001a07bd058b4f59fc--