From dev-return-60540-archive-asf-public=cust-asf.ponee.io@storm.apache.org Mon Aug 19 18:03:32 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 16EDF180665 for ; Mon, 19 Aug 2019 20:03:31 +0200 (CEST) Received: (qmail 18262 invoked by uid 500); 19 Aug 2019 18:03:31 -0000 Mailing-List: contact dev-help@storm.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@storm.apache.org Delivered-To: mailing list dev@storm.apache.org Received: (qmail 18239 invoked by uid 99); 19 Aug 2019 18:03:31 -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; Mon, 19 Aug 2019 18:03:31 +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 1384A1A422B for ; Mon, 19 Aug 2019 18:03:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.151 X-Spam-Level: ** X-Spam-Status: No, score=2.151 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, HTML_MESSAGE=2, HTML_TAG_BALANCE_BODY=0.1, KAM_LOTSOFHASH=0.25, 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-he-de.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id LT5G-u1gEvou for ; Mon, 19 Aug 2019 18:03:24 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::d2b; helo=mail-io1-xd2b.google.com; envelope-from=ethanopensource@gmail.com; receiver= Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 3B2197D3FA for ; Mon, 19 Aug 2019 18:03:23 +0000 (UTC) Received: by mail-io1-xd2b.google.com with SMTP id s21so6303303ioa.1 for ; Mon, 19 Aug 2019 11:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=h3sfuoIL8NEN0x4QDSeEvL543O40yXu/q39J/OqLSHo=; b=gBlNzVUOe1r/61HnhT1avpBHf4m/T/0plXctiL1HUabZ2krh3naBCgd3AY1OM229MN zkZfRHocX7c0phvfBxzOOwowmPBbqi5OKATXVWoQVyhHcGn9Vb1/v4NbecZ2g+H8y57k /rjs14iHOqDOsw9t0ZnpwVoQUjhqXX3pZe1oydhZMJeHe7zai/LKnvPuTKU/1/g6JB6m E7jOEvfijIzPAu1TjtyN9XPHxjRNvu2FML582hQpwQki9aUXI8JygnllLsLbIDRq6E39 gpX2uj5p41qE1nq1yjFmubmSIja4xBXoYNq0Rn48Wu5D2jVueYj3cM6jca49ncJGNEKd /gig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=h3sfuoIL8NEN0x4QDSeEvL543O40yXu/q39J/OqLSHo=; b=oydxspKKkpF+jEyJXt+xuu+UASr9CncQnqthV6EAWT5NgmVMXIDU4rmliynL59rYbe kqEcGFzd2pVz1ONSI/KPw2zCi1kXSo7BsfdnSOOinDeyTm8E5izaQWxxdWi6E36dkBPk xooRQFjNtBQp5AzUklEVxb9+7RkZNLg2DAHuaGB111biXch92qDZ/2CzhBR6/GLA0woA hI8kO7gyI/fKNUt/BOxbFQb0uSWjXNdT9xgyU4wPWzzOlltPsfL6x35uSKKEBs4yMM5s MQa+zOIzKNRMfyrglpwENJSD2x3Jtp0Rrg9JyLxUeTVoem1TPbOBgEilXFf5KLCsQIl0 DMsA== X-Gm-Message-State: APjAAAUsiA6q15hP8Bj7QSuRPEsFvS9ynaVJMZuASj+ATQj5yRDeP+dQ AP6iRGOHvhK1uKcAk+kK50T7aGp8XFU= X-Google-Smtp-Source: APXvYqztEKTBnKv5ZdakI/b+F3S9utC94uMKGVYsAJ7PXvFXoz/tkqL8wJogORAwwjdme+O+Y4dc1Q== X-Received: by 2002:a6b:610d:: with SMTP id v13mr29036545iob.226.1566237801046; Mon, 19 Aug 2019 11:03:21 -0700 (PDT) Received: from ?IPv6:2001:4998:efe9:102:e5ef:58dc:f153:f786? ([2001:4998:efe9:102:e5ef:58dc:f153:f786]) by smtp.gmail.com with ESMTPSA id e12sm33884851iob.66.2019.08.19.11.03.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Aug 2019 11:03:19 -0700 (PDT) From: Ethan Li Content-Type: multipart/alternative; boundary="Apple-Mail=_A3472241-B31C-463F-82D6-DFA0CB74276C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [DISCUSS] Next 2.x release Date: Mon, 19 Aug 2019 13:03:17 -0500 References: <2tzY1nYzSo3UgEI0_byRUZ42bpbNKRNYmFTWTvLbbM8mcIIjv1Wv4T4ZAS0acF0Isp6uUdXG19o9G1iMrez8BQ==@protonmail.internalid> <86643B96-B8B7-4354-98AD-AF0260C45A3F@gmail.com> <20190808221518.GC26391@dagit.name> <20190809135332.GA30551@dagit.name> <20190809195353.GA31067@dagit.name> <26C0598C-C737-4AC5-9194-0CE8F63B6126@gmail.com> <9C6A4375-BAF2-4801-93C1-49C80B6F6146@gmail.com> <95E0E4A1-BD29-433A-873D-EC44C237F1C7@gmail.com> <7249561A-F225-4C3E-A5CD-3F0F6D14F1F7@gmail.com> <69BB2732-D9C8-463F-9C35-7558D0F8CE8A@gmail.com> <4BA37104-3E51-4AE6-BD6C-B510988C689C@gmail.com> <12816261-1B8D-4196-9C3E-337ECFE6EB24@gmail.com> <2055B111-7BFF-47E8-A92E-F5C6781DDBB6@gmail.com> <1274C115-8A2B-40E3-8548-5944CA065D6F@gmail.com> <0C7C1ED5-0044-408B-945E-EDA9688242A8@gmail.com> <89FDD8CE-2211-4997-84D3-2D08992A11E9@gmail.com> To: dev@storm.apache.org In-Reply-To: Message-Id: <2E4F6278-9E4A-401F-BCB6-8774BD793B3F@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) --Apple-Mail=_A3472241-B31C-463F-82D6-DFA0CB74276C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We don=E2=80=99t create 2.1.0 branch.=20 I was thinking (and have been doing) about creating a 2.1.x-branch = before doing any thing release related. Then we use 2.1.x-branch to = release 2.1.0, and 2.1.1, etc. =20 When we create a 2.1.x-branch, we move master to 2.2.x-branch. It=E2=80=99= s a little different than what we did in the past. But it makes more = sense as it follows semantic versioning more strictly. > On Aug 19, 2019, at 12:53 PM, Stig Rohde D=C3=B8ssing = wrote: >=20 > I would be fine with just freezing (non-critical) merges during the > release process. These mails are public, so it's easy for anyone to = see > whether a release is in progress. >=20 > If we want to do merges while releases are going on, I think your = proposal > of using a release branch is fine. I'm not sure I understand why we = need > the 2.1-SNAPSHOT version though? >=20 > Let's say we create release branch 2.1.0-branch from master. We roll = the > master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch = is > created. We then get a bug fix that should go in 2.1.0. In this case = we > should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In = Jira > we mark it as going in 2.1.0. >=20 > We then get a PR that shouldn't be included in 2.1.0. We just merge it = to > master, and mark it as 2.1.1 in Jira. >=20 > Finally once 2.1.0 is released, we merge 2.1.0-branch into master and > delete 2.1.0-branch. >=20 > Why is there a need to 2.1-SNAPSHOT? >=20 > Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li = >: >=20 >> Many issues came up while I was preparing for 2.1.0 release. Freezing >> merge until the release is done is not practical. So I am proposing: >>=20 >> 1. Once we decide to make a release, we create a new branch based on >> master and start release process. >> 2. During the new process, master is still open for backwards >> compatibility commits, including new features, bu g fixes, etc. >> 3. Only bug fixes will be merged to the new branch and we need to = restart >> the release process to include the bug fixes. >> 4. To avoid too much confusion on pom versions when we merge new = commits >> during the release process, we should use less concrete version. For >> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, = instead >> of 2.1.0-SNAPSHOT. >>=20 >> For example, >>=20 >> Let=E2=80=99s say we have a new branch 2.1.x-branch, the pom version = is >> 2.1.0-SNAPSHOT. We start the release process and after running the = mvn >> release:prepare -Pxxx command, the pom version changes to = 2.1.1-SNAPSHOT, >> and before that a git tag v2.1.0 is created. Now if there is a bug = fix we >> have to merge in, so we merge in and it=E2=80=99s actually merged in = to >> 2.1.1-SNAPSHOT at this point if we don=E2=80=99t manually revert the = pom version, >> which can be confusing. We can avoid this problem by just using >> 2.1-SNAPSHOT as the pom version. So it doesn=E2=80=99t have to = change. >>=20 >> Please let me know if there is any potential risk for doing this. >>=20 >> Thanks >> Ethan >>=20 >>> On Aug 19, 2019, at 10:25 AM, Ethan Li >> wrote: >>>=20 >>> The pull request for the fix is >> https://github.com/apache/storm/pull/3106 < >> https://github.com/apache/storm/pull/3106 = > >>>=20 >>>> On Aug 19, 2019, at 10:15 AM, Ethan Li >> >> wrote: >>>>=20 >>>> So I was preparing for a new release candidate i.e. rc3. I can = build it >> from source without any problem. Then I set up a standalone cluster = and >> submitted a WordCountTopology. The workers kept restarting because of >>>>=20 >>>>=20 >>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting >> process: ShellBolt died. Command: [python, splitsentence.py], = ProcessInfo >> pid:3756, name:split exitCode:-1, errorString: >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] = Error >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting >> process: ShellBolt died. Command: [python, splitsentence.py], = ProcessInfo >> pid:3755, name:split exitCode:-1, errorString: >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] = Error >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>>=20 >>>>=20 >>>>=20 >>>>=20 >> = https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apach= e/storm/task/ShellBolt.java#L365-L367 = >> < >> = https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apach= e/storm/task/ShellBolt.java#L365-L367 = > >> I believe we shouldn=E2=80=99t throw exceptions here. >>>>=20 >>>> Will make a pull request to fix it. >>>>=20 >>>>=20 >>>>=20 >>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li >> >> wrote: >>>>>=20 >>>>> Hi Taylor, >>>>>=20 >>>>> Mostly I was able to follow the doc >> = https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote= = >> < >> = https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote= = >, >> except: >>>>>=20 >>>>> For Step 1, I used the following command as suggested. >>>>> mvn release:prepare -P dist,rat,externals,examples >>>>> mvn release:perform -P dist,rat,externals,examples >>>>>=20 >>>>>=20 >>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0=E2=80=9D= so that >> I can run =E2=80=9Cmvn package=E2=80=9D for storm-dist/binary and = storm-dist/source based >> on v2.1.0. Otherwise if I run =E2=80=9Cmvn package=E2=80=9D on = 2.1.x-branch, it will fail >> because the pom version is =E2=80=9C2.1.x-SNAPSHOT=E2=80=9D. >>>>>=20 >>>>> Then I find packages in storm-dist/binary/final-package/target and >> storm-dist/source/target, sign them, generate checksum and copy them = to svn. >>>>>=20 >>>>> I think there are something I should do. But please let me know if = I >> was doing something wrong. I will also update the doc after the = release >> is complete. Thank you very much! >>>>>=20 >>>>> Ethan >>>>>=20 >>>>>=20 >>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li >> >> wrote: >>>>>>=20 >>>>>> I am continuing for another release candidate since the pr is = merged. >>>>>>=20 >>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde D=C3=B8ssing < >> stigdoessing@gmail.com = >> wrote: >>>>>>>=20 >>>>>>> Updated https://github.com/apache/storm/pull/3053 = < >> https://github.com/apache/storm/pull/3053 = > so we don't have >>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's >> ready for >>>>>>> review if someone wants to look at it. >>>>>>>=20 >>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li < >> ethanopensource@gmail.com = >>: >>>>>>>=20 >>>>>>>> Thank you, Taylor. Will delete them. >>>>>>>>=20 >>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz = >> >> wrote: >>>>>>>>>=20 >>>>>>>>> Those can be safely deleted. >>>>>>>>>=20 >>>>>>>>> -Taylor >>>>>>>>>=20 >>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li = >> >> >>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Do we need/want to clean up the release candidate from >>>>>>>> https://dist.apache.org/repos/dist/dev/storm = < >> https://dist.apache.org/repos/dist/dev/storm = > < >>>>>>>> https://dist.apache.org/repos/dist/dev/storm = < >> https://dist.apache.org/repos/dist/dev/storm = >> ? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >> = https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-th= e-vote-fails = >> < >> = https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-th= e-vote-fails = >>>=20 >>>>>>>> < >>>>>>>>=20 >> = https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-th= e-vote-fails = >> < >> = https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-th= e-vote-fails = >>>>=20 >>>>>>>> says we do. But we have a lot of rc in >>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ = < >> https://dist.apache.org/repos/dist/dev/storm/ = > < >>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ = < >> https://dist.apache.org/repos/dist/dev/storm/ = >> >>>>>>>>>>=20 >>>>>>>>>> Just want to be absolutely sure about this. Thanks. >>>>>>>>>>=20 >>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li < >> ethanopensource@gmail.com = >> >>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> That sounds better. It will be easier for release. Thank you = for >>>>>>>> looking into this. >>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde D=C3=B8ssing < >>>>>>>> stigdoessing@gmail.com = >> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Makes sense. I'll take a look at it. Ideally I'd want the >> license >>>>>>>> files to >>>>>>>>>>>> just not include org.apache.storm artifacts. I don't think = we >> need to >>>>>>>> tell >>>>>>>>>>>> people that the project depends on itself. >>>>>>>>>>>>=20 >>>>>>>>>>>> If we can exclude these artifacts from the lists, I don't = think >> the >>>>>>>> release >>>>>>>>>>>> plugin needs to update these files. >>>>>>>>>>>>=20 >>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li < >>>>>>>> ethanopensource@gmail.com = >>: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks Stig. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> In this case, we probably should abort release process and = get >> this >>>>>>>> merged >>>>>>>>>>>>> into master first. Also we need to make sure it works with = =E2=80=9Cmvn >>>>>>>>>>>>> release:prepare=E2=80=9D since =E2=80=9C mvn = release:prepare=E2=80=9D will >> automatically >>>>>>>> push two >>>>>>>>>>>>> commits. For example, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> (1) [maven-release-plugin] prepare release v2.1.0: this = commit >>>>>>>> changes >>>>>>>>>>>>> the pom version to 2.1.0, push the commit, and then create = a >> git tag >>>>>>>> v2.1.0. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> (2) [maven-release-plugin] prepare for next development >> iteration: >>>>>>>> this >>>>>>>>>>>>> commit changes the pom version to 2.1.1-SNAPSHOT. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We need DEPENDENCY-LICENSES to be updated on every step. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde D=C3=B8ssing < >>>>>>>> stigdoessing@gmail.com = >> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup = was >> disabled >>>>>>>> in >>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 = < >> https://github.com/apache/storm/pull/3031 = > due to a bug in the >>>>>>>> license >>>>>>>>>>>>>> plugin. It is added back in >>>>>>>> https://github.com/apache/storm/pull/3053 = < >> https://github.com/apache/storm/pull/3053 = >, >>>>>>>>>>>>>> where we've upgraded the plugin. Until that PR goes in, = we >> can't >>>>>>>> easily >>>>>>>>>>>>>> regenerate DEPENDENCY-LICENSES. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde = D=C3=B8ssing < >>>>>>>>>>>>>> stigdoessing@gmail.com = >>: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> There's a script that can help you do it in >>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 = < >> https://github.com/apache/storm/pull/3053 = >. It checks the >>>>>>>>>>>>>>> DEPENDENCY-LICENSES and LICENSE-binary contain the right >>>>>>>> dependencies, >>>>>>>>>>>>> and >>>>>>>>>>>>>>> prints which licenses are redundant or should be added. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> For DEPENDENCY-LICENSES specifically you can run "mvn >>>>>>>>>>>>>>> = license:aggregate-add-third-party@generate-and-check-licenses >>>>>>>>>>>>>>> -Dlicense.skipAggregateAddThirdParty=3Dfalse -B" in the = project >>>>>>>> root. It >>>>>>>>>>>>>>> should update the file for you. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li < >>>>>>>>>>>>> ethanopensource@gmail.com = > >>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hi Stig, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> How do we update >>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? = < >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? = > >>>>>>>> < >>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? = < >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? = >> >>>>>>>> Is >>>>>>>>>>>>>>>> there a command I can use? Or I just replace strings >> manually? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li < >> ethanopensource@gmail.com = > >>>>>>>>>=20 >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Yes my public keys in that file. Thanks! Ready to set = up a >> vote. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz < >> ptgoetz@gmail.com = > >>>>>>>>>=20 >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Yes. Is you public key in that file? If not you = should >> add it. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -Taylor >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li < >>>>>>>> ethanopensource@gmail.com = >> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I have one more question before I can start a vote. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> In previous [VOTE] thread, Taylor always has this: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> The release artifacts are signed with the following = key: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >> = https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3DK= EYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd = >> < >> = https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3DK= EYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd = >>>=20 >>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >> = https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3DK= EYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >> < >> = https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3DK= EYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Does anyone know where to find the updated KEYs = file? >> Should I >>>>>>>> just >>>>>>>>>>>>>>>> use https://www.apache.org/dist/storm/KEYS < >>>>>>>>>>>>>>>> https://www.apache.org/dist/storm/KEYS> ? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Thanks very much >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li < >>>>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue = the >>>>>>>> process now >>>>>>>>>>>>>>>> and update the documentation later. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz < >>>>>>>> ptgoetz@gmail.com> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> For the 2.x version lines, there are a bunch of >> profiles you >>>>>>>> need >>>>>>>>>>>>>>>> to enable. This is what I use when preparing a release: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -Taylor >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde D=C3=B8ssin= g < >>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Try enabling the "dist" profile by adding "-P >>>>>>>>>>>>>>>> dist,externals,examples" to >>>>>>>>>>>>>>>>>>>>>> the command you're running. See >>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/blob/master/pom.xml#L518. >>>>>>>> Unless >>>>>>>>>>>>>>>> you enable >>>>>>>>>>>>>>>>>>>>>> that profile, the storm-dist modules aren't in = the >> reactor. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li < >>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Just in case if anyone happens to know the = answer: >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> I created a branch >>>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch < >>>>>>>>>>>>>>>>>>>>>>> = https://github.com/apache/storm/tree/2.1.x-branch> >> and ran >>>>>>>>>>>>>>>> =E2=80=9Cmvn:prepare=E2=80=9D >>>>>>>>>>>>>>>>>>>>>>> and =E2=80=9Cmvn:perform=E2=80=9D. It created = two commits and >> created a >>>>>>>> v2.1.0 >>>>>>>>>>>>>>>> git tag. But >>>>>>>>>>>>>>>>>>>>>>> I realized that the pom version under storm-dist = was >> not >>>>>>>> updated >>>>>>>>>>>>>>>> and it=E2=80=99s >>>>>>>>>>>>>>>>>>>>>>> still 2.0.1-SNAPSHOT. I checked the commits in = other >> tags >>>>>>>> like >>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0 < >>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0> = and >> it >>>>>>>> looks >>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>>>> storm-dist got updated within the = =E2=80=9Cmvn:prepare=E2=80=9D >> step. How >>>>>>>> do I >>>>>>>>>>>>>>>> get >>>>>>>>>>>>>>>>>>>>>>> storm-dist pom version updated with = =E2=80=9Cmv:prepare=E2=80=9D? >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> I am currently blocked on this. Any help will be >>>>>>>> appreciated. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde = D=C3=B8ssing < >>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Sounds good Ethan. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Derek, I also think being clear about how long = we >> expect >>>>>>>> to >>>>>>>>>>>>>>>> support a >>>>>>>>>>>>>>>>>>>>>>>> release line is a good idea. Maybe we should do = a >> separate >>>>>>>>>>>>>>>> discuss thread >>>>>>>>>>>>>>>>>>>>>>>> on this, or if you already have a good idea for >> what the >>>>>>>> policy >>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>> look >>>>>>>>>>>>>>>>>>>>>>>> like you could put it up as a PR for either the >> Downloads >>>>>>>> page >>>>>>>>>>>>>>>> or a new >>>>>>>>>>>>>>>>>>>>>>>> page on the Storm site? >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Den s=C3=B8n. 11. aug. 2019 kl. 08.37 skrev = Ethan Li < >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> I am doing the release following >>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/blob/master/RELEASING.md >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/blob/master/RELEASING.md> >>>>>>>> . I >>>>>>>>>>>>>>>> made some >>>>>>>>>>>>>>>>>>>>>>>>> progress but I have some questions so I just = sent >> an >>>>>>>> email to >>>>>>>>>>>>>>>> Taylor. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> Please don=E2=80=99t merge anything to master = or >> 2.1.x-branch >>>>>>>> for now. >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li < >>>>>>>>>>>>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we >> wanted to >>>>>>>>>>>>>>>> include in the >>>>>>>>>>>>>>>>>>>>>>>>> new release: >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> >> (Travis has >>>>>>>> some >>>>>>>>>>>>>>>> issues >>>>>>>>>>>>>>>>>>>>>>>>> connecting to repository.apache.org < >>>>>>>>>>>>>>>> http://repository.apache.org/> >>>>>>>>>>>>>>>>>>>>>>>>> recently. Travis build fails consistently) >>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> = (Some >>>>>>>> comments are >>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>>>>>>> addressed but Author hasn=E2=80=99t responded = yet.) >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s not absolutely necessary to = include them in >> this >>>>>>>> new >>>>>>>>>>>>>>>> release so I >>>>>>>>>>>>>>>>>>>>>>>>> think I should move forward with the release >> process. >>>>>>>> These >>>>>>>>>>>>> two >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>>>>>>>>>> PRs can be included in the next release. >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> For the release, I will create a new branch >> 2.1.x-branch >>>>>>>>>>>>> based >>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>>>> current master branch, and release 2.1.0 from >> there. I >>>>>>>> will >>>>>>>>>>>>>>>> then move >>>>>>>>>>>>>>>>>>>>>>>>> master to 2.2.0-SNAPSHOT. Please let me know = if >> there >>>>>>>> is any >>>>>>>>>>>>>>>>>>>>>>> objections. >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit < >>>>>>>> dagit@apache.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> We might not able to say how long we want = to >> support a >>>>>>>>>>>>>>>> specific >>>>>>>>>>>>>>>>>>>>>>>>>>>> release line but I would love to see a = clear >> release >>>>>>>> policy >>>>>>>>>>>>>>>> being >>>>>>>>>>>>>>>>>>>>>>>>>>>> made. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> That makes sense. It seems better for us not = to >> choose >>>>>>>> a >>>>>>>>>>>>>>>> specific >>>>>>>>>>>>>>>>>>>>>>>>>>> calendar date or duration of time. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> - We do not want too many release lines = supported >>>>>>>>>>>>>>>> concurrently. >>>>>>>>>>>>>>>>>>>>>>>>>>> - We want devs and users to know what to = expect. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, = Ethan >> Li >>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> Derek, >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it=E2=80=99s a good idea to be more = clear on the >>>>>>>> versioning >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>> release process so users and developers know = what >> to >>>>>>>> expect. >>>>>>>>>>>>> We >>>>>>>>>>>>>>>> might >>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>> able to say how long we want to support a = specific >>>>>>>> release >>>>>>>>>>>>> line >>>>>>>>>>>>>>>> but I >>>>>>>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>>>>>>> love to see a clear release policy being made. >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit < >>>>>>>> dagit@apache.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, = Stig >> Rohde >>>>>>>>>>>>>>>> D=C3=B8ssing wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Where on the Traffic Server page do they = list >> how >>>>>>>> long >>>>>>>>>>>>>>>> their >>>>>>>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trains survive? I only see dates of = release, >> not >>>>>>>> how long >>>>>>>>>>>>>>>> e.g. 7.x >>>>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to receive support. Derek, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is a better link: >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >> https://cwiki.apache.org/confluence/display/TS/Release+Management >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >> https://cwiki.apache.org/confluence/display/TS/Release+Management >>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release >> Manager": >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / = year, >> but >>>>>>>> the RM >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>> community >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can of course make more as necessary >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS = branches, >>>>>>>> which are >>>>>>>>>>>>>>>> cut once a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> year off master >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of >> change >>>>>>>>>>>>> (including >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break >>>>>>>> compatibility just >>>>>>>>>>>>>>>> for fun! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits >> should be >>>>>>>>>>>>>>>> properly tested >>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed before committed to master. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases, = following >>>>>>>> strict >>>>>>>>>>>>>>>> Semantic >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Versioning. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the = discretion >> at the >>>>>>>>>>>>>>>> discretion of >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> community and the RM. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small = / >> safe) >>>>>>>>>>>>> features, >>>>>>>>>>>>>>>> but must >>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatible within the LTS major version. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months = Sunset, >> does >>>>>>>> not >>>>>>>>>>>>>>>> reset when we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make a minor release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly = this. >> The goal >>>>>>>> would >>>>>>>>>>>>>>>> be to set >>>>>>>>>>>>>>>>>>>>>>>>>>>>> expectations among developers and the >> community, and >>>>>>>> here >>>>>>>>>>>>>>>> is one >>>>>>>>>>>>>>>>>>>>>>>>>>>>> concrete example of how it could be done. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If we're going to promise that a release = line >>>>>>>> survives >>>>>>>>>>>>> for >>>>>>>>>>>>>>>> a given >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> amount of time, I think we should do it = at >> the major >>>>>>>>>>>>>>>> version level >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we >> choose to >>>>>>>> commit >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>>>>>>>>>>>> like the above, we should base the = decision in >> part >>>>>>>> on >>>>>>>>>>>>> what >>>>>>>>>>>>>>>> kind of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> resources we have so that we do not >> over-commit. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev = Derek >> Dagit < >>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org >>>>>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What do we think about defining = Long-Term >> Support >>>>>>>>>>>>>>>> branches with a >>>>>>>>>>>>>>>>>>>>>>>>> fixed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> period of support? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an = LTS >> release >>>>>>>> line >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>> support >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ending no earlier than a certain = calendar >> date. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The date could be extended, and it might >>>>>>>> ultimately be >>>>>>>>>>>>>>>> governed by >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> timing of the subsequent release (e.g., >> 2.1.x or >>>>>>>> 3.0.x). >>>>>>>>>>>>>>>> Keeping >>>>>>>>>>>>>>>>>>>>>>>>> things >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clear would imply semantic versioning as >> mentioned >>>>>>>>>>>>> earlier >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (https://semver.org/ = ). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something = like >> this, to >>>>>>>> name >>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>>>> project: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = https://trafficserver.apache.org/downloads < >>>>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Having a regular cadence of releases = might >> also >>>>>>>> help >>>>>>>>>>>>> make >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easier and help set expectations for = users >> and >>>>>>>> devs. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM = -0500, >> Ethan Li >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Currently we don=E2=80=99t have a = 2.0.x-branch and >> master >>>>>>>> is >>>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=9C2.0.1-SNAPSHOT=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So if we do a 2.1.0 release, we will >> create a >>>>>>>>>>>>>>>> 2.1.x-branch >>>>>>>>>>>>>>>>>>>>>>> based >>>>>>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> current master, release from there. And = we >> change >>>>>>>> master >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=9C2.2.0-SNAPSHOT=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But we will have one problem: we will = lose >> 2.0.x >>>>>>>>>>>>> release >>>>>>>>>>>>>>>> line. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are two things I can do: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on = v2.0.0 >> tag. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with >> 2.0.x >>>>>>>> release, >>>>>>>>>>>>>>>> ask users >>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> upgrade to 2.1.0. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it=E2=80=99s = the right >> way to >>>>>>>> make >>>>>>>>>>>>>>>> things >>>>>>>>>>>>>>>>>>>>>>>>> right. Or >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood >> something >>>>>>>> and it=E2=80=99s >>>>>>>>>>>>>>>> not an >>>>>>>>>>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Btw, I am seeing the same issue with >> 1.x-branch. >>>>>>>> We >>>>>>>>>>>>>>>> shouldn=E2=80=99t >>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1.x-branch. Instead, we should have >> 1.2.x-branch. >>>>>>>> But >>>>>>>>>>>>>>>> this is not >>>>>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>>>>> problem >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> since we will not release 1.3.x. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li = < >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig = Rohde >> D=C3=B8ssing >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your = key to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/storm/KEYS, >>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> able >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to update it with an SVN client. See = also >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://www.apache.org/dev/openpgp.html#update. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev >> Ethan Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. = Call >> < >>>>>>>>>>>>>>>> bcall@apache.org >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@apache.org>> (Thanks to him). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My pgp key: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >> = http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0xA= 4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >> = http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0xA= 4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good = to do >>>>>>>> release >>>>>>>>>>>>> with >>>>>>>>>>>>>>>> this key >>>>>>>>>>>>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might = want >> to >>>>>>>> include >>>>>>>>>>>>>>>> in the new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/3098 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/3098> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/3096 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/3096> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/2878> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance. >> Thanks >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig = Rohde >>>>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes = sense. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 = skrev >> Ethan >>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s a good point. I will = start a >> discussion >>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> for it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went = through >> the list: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >> = https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%2= 0fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >> = https://issues.apache.org/jira/issues/?jql=3Dproject%20=3D%20STORM%20AND%2= 0fixVersion%20=3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new = functionalities, >>>>>>>> including >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-2720 >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-2720> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3412 >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3412> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3411 >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3411> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3442 >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3442> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3396 >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3396> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3392 >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3392> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3395 >>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://issues.apache.org/jira/browse/STORM-3395> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0 >> rather >>>>>>>> than >>>>>>>>>>>>>>>> 2.0.1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we = may >> want to >>>>>>>>>>>>> review >>>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>>>>>>>>>>> the next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/3094 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/3094> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/2990 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/2990> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/2878> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, = Hugo >> Louro < >>>>>>>>>>>>>>>>>>>>>>> hmclouro@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it would facilitate more >> frequent >>>>>>>>>>>>> releases >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>> summarize >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> page >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the testing that all >>>>>>>> contributors/committers do >>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>> anticipation >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release, plus any "new" testing = that >> may >>>>>>>> become >>>>>>>>>>>>>>>> relevant >>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> newer >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> releases. Doing so would make it = easy >> to >>>>>>>> create a >>>>>>>>>>>>>>>> check >>>>>>>>>>>>>>>>>>>>>>> form >>>>>>>>>>>>>>>>>>>>>>>>> or or >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> email >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> template that what we feel should = be >> done to >>>>>>>>>>>>>>>> guarantee a >>>>>>>>>>>>>>>>>>>>>>>>> stable >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hugo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM = Ethan >> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into = it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, = Stig >> Rohde >>>>>>>>>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think ideally we've been = trying >> for >>>>>>>> semver, >>>>>>>>>>>>>>>> but it's >>>>>>>>>>>>>>>>>>>>>>> been >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretty >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loose, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. there were breaking = changes in >> one >>>>>>>> of the >>>>>>>>>>>>>>>> 1.2.x >>>>>>>>>>>>>>>>>>>>>>>>> releases >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> storm-kafka-client. I don't = know >> what >>>>>>>> rules >>>>>>>>>>>>> we've >>>>>>>>>>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>>>>>>>>>>>> been >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> using, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility >> would >>>>>>>> probably >>>>>>>>>>>>>>>> be a good >>>>>>>>>>>>>>>>>>>>>>>>> rule of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thumb. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. = 20.01 >> skrev >>>>>>>> Ethan >>>>>>>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what=E2=80=99s the = versioning >>>>>>>> standard we >>>>>>>>>>>>>>>> have been >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or = 2.1.0 >>>>>>>> release) ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, >> Stig Rohde >>>>>>>>>>>>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. = 19.16 >> skrev >>>>>>>> Ethan >>>>>>>>>>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s good idea to do = more >> frequent >>>>>>>> release. >>>>>>>>>>>>> I >>>>>>>>>>>>>>>> can run >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both = PRs. >> Other >>>>>>>> than >>>>>>>>>>>>>>>> that, I >>>>>>>>>>>>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get >>>>>>>>>>>>> https://github.com/apache/storm/pull/3093 >>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://github.com/apache/storm/pull/3093> >>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 = AM, >> Stig >>>>>>>> Rohde >>>>>>>>>>>>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we've talked about = more >>>>>>>> frequent >>>>>>>>>>>>>>>> releases >>>>>>>>>>>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Releasing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> versions every few months = means >> people >>>>>>>>>>>>> don't >>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>>>>> wait >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> long >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fixes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get out, and smaller = releases >> are >>>>>>>> probably >>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>> easier >>>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> users >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> grips with (the fix list = for >> 2.0.0 is >>>>>>>>>>>>>>>> enormous). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that in mind, I think = we >> should >>>>>>>> start >>>>>>>>>>>>>>>> looking at >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.x >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since = it's >> been a >>>>>>>> couple >>>>>>>>>>>>>>>> of months >>>>>>>>>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.0.0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> released. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fix list would be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>=20 >> = https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%2= 0fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Govind and Ethan have = offered >> to run >>>>>>>> the >>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>> release, >>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validate >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our release process = guidelines. >> Would >>>>>>>> one >>>>>>>>>>>>> of >>>>>>>>>>>>>>>> you have >>>>>>>>>>>>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in the near future? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good to take a = look >> at >>>>>>>>>>>>> currently >>>>>>>>>>>>>>>> open PRs >>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decide >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feel need to get merged = before >> the >>>>>>>> next >>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at = least >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >> https://github.com/apache/storm/pull/2990 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>> https://github.com/apache/storm/pull/2878 >>>>>>>>>>>>>>>> seems like >>>>>>>>>>>>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> close >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too? --Apple-Mail=_A3472241-B31C-463F-82D6-DFA0CB74276C--