From dev-return-60464-archive-asf-public=cust-asf.ponee.io@storm.apache.org Tue Aug 13 15:54:45 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 49B2E180652 for ; Tue, 13 Aug 2019 17:54:45 +0200 (CEST) Received: (qmail 58348 invoked by uid 500); 13 Aug 2019 15:54:44 -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 58225 invoked by uid 99); 13 Aug 2019 15:54:44 -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; Tue, 13 Aug 2019 15:54:44 +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 7E589C09F3 for ; Tue, 13 Aug 2019 15:54:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.801 X-Spam-Level: ** X-Spam-Status: No, score=2.801 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, FREEMAIL_REPLY=1, 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: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id IgmAsPUQt5WS for ; Tue, 13 Aug 2019 15:54:39 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.210.41; helo=mail-ot1-f41.google.com; envelope-from=generalbas.srd@gmail.com; receiver= Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id A1C70BC7B3 for ; Tue, 13 Aug 2019 15:54:38 +0000 (UTC) Received: by mail-ot1-f41.google.com with SMTP id e12so30089742otp.10 for ; Tue, 13 Aug 2019 08:54:38 -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=/dGA3RZc8Uls6Q1uXCaYybts+/A7u/ratLmAu4cNRu0=; b=oGyuWL/cEm38xr+yaFT6IP+Kr3z+yzWi1f/GIOyLP//H97nABrly/OULXRsVwkIfm4 SZnqn1WqDCLV/YRi/rneLUpKKLRlZO/8sDhm25HWUYZIA1UAqAHJflmyoGA+Dyaypxtq n8blco1nAV0WedLXqTbFrqRHBGgVeCaSb+SSzLWnG/oK3yVf1bsT/qxSXTlsYoV/WNZW zSMiIUFa081wvPPW8fNKAEn3/Ja4H7gn2ytygT5jG3F5xlPMvtUI9p0LMnkgs/SPjtzp emYs8ldv3j4Kw44FY5XXAbQimQJk5QBQYqN2gXUPVv3x8Dw6SqRlmLWIRlDvVGpZPUdk plsw== 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=/dGA3RZc8Uls6Q1uXCaYybts+/A7u/ratLmAu4cNRu0=; b=Wv7yihgsDcycUrbdF+klZ0HADEB0Xxm2DwVEuyXyhP6AP7EBji4xiipHJguEoRPZw3 gxmyrEH3WQ1RacOFZEN/mAt7/H3Y3u24OQx9fxbuMrDegTnBkR5eloE76h4unz1XaB4p /DXH6MzACsiuFgei+hhPELa1whRqcKZUcUxiuxmAVLju9f4r+gY+aVEGrHtSCqMo4jfr OSP3Xy5aIiOTO1r0rmVKWlSUOhbVI8USsQQwu7J+544GvDYgqOOGVIJ05DjWErJzpkru AKb2sFLU29Z5WQyb9Ia1ZyqjRU8jwuCDI2zs9/alj1+3MNo0imCkZxKqQ9ubor32/EJv UYMA== X-Gm-Message-State: APjAAAXQESApE+Mg6lKW+zW6KAqreNk/ZHFovRTOlM8zgPaL5LCuh3KK b5LeWtydMH553jYhXk6GipPXcfPdLV8lBQOzRhdwHw== X-Google-Smtp-Source: APXvYqxlFY5a08M22wudIM5Zdefc73Vwm18QOI6JZw7HFirxakhYA/10xlFh+Ts/v55qS/8pD+8TuWJ4uK5hYZ65DBs= X-Received: by 2002:a05:6808:8e1:: with SMTP id d1mr1793381oic.167.1565711677387; Tue, 13 Aug 2019 08:54:37 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <4BA37104-3E51-4AE6-BD6C-B510988C689C@gmail.com> From: =?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?= Date: Tue, 13 Aug 2019 17:54:25 +0200 Message-ID: Subject: Re: [DISCUSS] Next 2.x release To: dev@storm.apache.org Content-Type: multipart/alternative; boundary="00000000000059fb93059001a8e4" --00000000000059fb93059001a8e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. If we can exclude these artifacts from the lists, I don't think the release plugin needs to update these files. Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li = : > Thanks Stig. > > In this case, we probably should abort release process and get this merge= d > 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 wil= l automatically push two > commits. For example, > > (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. > > (2) [maven-release-plugin] prepare for next development iteration: this > commit changes the pom version to 2.1.1-SNAPSHOT. > > > We need DEPENDENCY-LICENSES to be updated on every step. > > > > > On Aug 13, 2019, at 10:24 AM, Stig Rohde D=C3=B8ssing > wrote: > > > > Oops, sorry that's not right. The license plugin setup was disabled in > > 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, > > where we've upgraded the plugin. Until that PR goes in, we can't easily > > regenerate DEPENDENCY-LICENSES. > > > > Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde D=C3=B8ssing < > > stigdoessing@gmail.com>: > > > >> There's a script that can help you do it in > >> 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. > >> > >> 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. > >> > >> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li < > ethanopensource@gmail.com > >>> : > >> > >>> Hi Stig, > >>> > >>> How do we update > >>> 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? > >>> > >>> Thanks > >>> Ethan > >>> > >>>> On Aug 12, 2019, at 3:54 PM, Ethan Li > >>> wrote: > >>>> > >>>> Yes my public keys in that file. Thanks! Ready to set up a vote. > >>>> > >>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz > >>> wrote: > >>>>> > >>>>> Yes. Is you public key in that file? If not you should add it. > >>>>> > >>>>> -Taylor > >>>>> > >>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li > >>> wrote: > >>>>>> > >>>>>> I have one more question before I can start a vote. > >>>>>> > >>>>>> In previous [VOTE] thread, Taylor always has this: > >>>>>> > >>>>>> The release artifacts are signed with the following key: > >>>>>> > >>> > https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3D= KEYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd > >>> < > >>> > https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3D= KEYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd > >>>> > >>>>>> > >>>>>> > >>>>>> Does anyone know where to find the updated KEYs file? Should I jus= t > >>> use https://www.apache.org/dist/storm/KEYS < > >>> https://www.apache.org/dist/storm/KEYS> ? > >>>>>> > >>>>>> Thanks very much > >>>>>> > >>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li > >>> wrote: > >>>>>>> > >>>>>>> Thanks Stig and Taylor! It worked. I will continue the process no= w > >>> and update the documentation later. > >>>>>>> > >>>>>>> > >>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz > >>> wrote: > >>>>>>>> > >>>>>>>> For the 2.x version lines, there are a bunch of profiles you nee= d > >>> to enable. This is what I use when preparing a release: > >>>>>>>> > >>>>>>>> -P dist,include-shaded-deps,rat,externals,examples > >>>>>>>> > >>>>>>>> -Taylor > >>>>>>>> > >>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde D=C3=B8ssing < > >>> stigdoessing@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> Try enabling the "dist" profile by adding "-P > >>> dist,externals,examples" to > >>>>>>>>> the command you're running. See > >>>>>>>>> https://github.com/apache/storm/blob/master/pom.xml#L518. Unles= s > >>> you enable > >>>>>>>>> that profile, the storm-dist modules aren't in the reactor. > >>>>>>>>> > >>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li < > >>> ethanopensource@gmail.com>: > >>>>>>>>> > >>>>>>>>>> Just in case if anyone happens to know the answer: > >>>>>>>>>> > >>>>>>>>>> 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 updat= ed > >>> 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? > >>>>>>>>>> > >>>>>>>>>> I am currently blocked on this. Any help will be appreciated. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Ethan > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde D=C3=B8ssing < > >>> stigdoessing@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Sounds good Ethan. > >>>>>>>>>>> > >>>>>>>>>>> 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 poli= cy > >>> should > >>>>>>>>>> look > >>>>>>>>>>> like you could put it up as a PR for either the Downloads pag= e > >>> or a new > >>>>>>>>>>> page on the Storm site? > >>>>>>>>>>> > >>>>>>>>>>> Den s=C3=B8n. 11. aug. 2019 kl. 08.37 skrev Ethan Li < > >>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>> > >>>>>>>>>>>> I am doing the release following > >>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md < > >>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md> . = I > >>> made some > >>>>>>>>>>>> progress but I have some questions so I just sent an email t= o > >>> Taylor. > >>>>>>>>>>>> > >>>>>>>>>>>> Please don=E2=80=99t merge anything to master or 2.1.x-branc= h for now. > >>> Thanks > >>>>>>>>>>>> > >>>>>>>>>>>> Best, > >>>>>>>>>>>> Ethan > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li < > >>> ethanopensource@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Currently we have two outstanding PRs that we wanted to > >>> include in the > >>>>>>>>>>>> new release: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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 ar= e > >>> to be > >>>>>>>>>>>> addressed but Author hasn=E2=80=99t responded yet.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> It=E2=80=99s not absolutely necessary to include them in th= is 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. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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 wil= l > >>> then move > >>>>>>>>>>>> master to 2.2.0-SNAPSHOT. Please let me know if there is an= y > >>>>>>>>>> objections. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> Ethan > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit >>> >>>>>>>>>>>> dagit@apache.org>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 poli= cy > >>> being > >>>>>>>>>>>>>>> made. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> That makes sense. It seems better for us not to choose a > >>> specific > >>>>>>>>>>>>>> calendar date or duration of time. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - We do not want too many release lines supported > >>> concurrently. > >>>>>>>>>>>>>> - We want devs and users to know what to expect. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Derek > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Derek, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit >>> >>>>>>>>>>>> dagit@apache.org>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 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 lo= ng > >>> e.g. 7.x > >>>>>>>>>> is > >>>>>>>>>>>>>>>>> supposed to receive support. Derek, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This is a better link: > >>>>>>>>>>>> > >>> https://cwiki.apache.org/confluence/display/TS/Release+Management < > >>>>>>>>>>>> > >>> https://cwiki.apache.org/confluence/display/TS/Release+Management> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> This example, where "RM" means "Release Manager": > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / year, but the R= M > >>> and > >>>>>>>>>>>> community > >>>>>>>>>>>>>>>>> can of course make more as necessary > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 2. We only make releases off the LTS branches, which ar= e > >>> cut once a > >>>>>>>>>>>>>>>>> year off master > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 3. Master is always open, for any type of change > (including > >>>>>>>>>>>>>>>>> incompatible changes). But don't break compatibility ju= st > >>> for fun! > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits should be > >>> properly tested > >>>>>>>>>>>> and > >>>>>>>>>>>>>>>>> reviewed before committed to master. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 5. All releases are stable releases, following strict > >>> Semantic > >>>>>>>>>>>>>>>>> Versioning. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 6. Minor releases are made at the discretion at the > >>> discretion of > >>>>>>>>>> the > >>>>>>>>>>>>>>>>> community and the RM. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 7. Minor releases can include new (small / safe) > features, > >>> but must > >>>>>>>>>>>> be > >>>>>>>>>>>>>>>>> compatible within the LTS major version. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does not > >>> reset when we > >>>>>>>>>>>>>>>>> make a minor release. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this. The goal wou= ld > >>> be to set > >>>>>>>>>>>>>>>> expectations among developers and the community, and her= e > >>> is one > >>>>>>>>>>>>>>>> concrete example of how it could be done. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we choose to comm= it > >>> 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. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit < > >>>>>>>>>> dagit@apache.org > >>>>>>>>>>>> >: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> What do we think about defining Long-Term Support > >>> branches with a > >>>>>>>>>>>> fixed > >>>>>>>>>>>>>>>>>> period of support? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an LTS release line > >>> with > >>>>>>>>>> support > >>>>>>>>>>>>>>>>>> ending no earlier than a certain calendar date. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 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/ ). > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Apache Traffic Server does something like this, to nam= e > >>> one > >>>>>>>>>> project: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads < > >>>>>>>>>>>> https://trafficserver.apache.org/downloads> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Having a regular cadence of releases might also help > make > >>> the > >>>>>>>>>>>> process > >>>>>>>>>>>>>>>>>> easier and help set expectations for users and devs. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>> Derek > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li > wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Currently we don=E2=80=99t have a 2.0.x-branch and ma= ster is > >>> actually > >>>>>>>>>>>>>>>>>> =E2=80=9C2.0.1-SNAPSHOT=E2=80=9D. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 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 mast= er > >>> to > >>>>>>>>>>>>>>>>>> =E2=80=9C2.2.0-SNAPSHOT=E2=80=9D. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> But we will have one problem: we will lose 2.0.x > release > >>> line. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> There are two things I can do: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0 tag. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with 2.0.x release= , > >>> ask users > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> upgrade to 2.1.0. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it=E2=80=99s the right wa= y to make > >>> things > >>>>>>>>>>>> right. Or > >>>>>>>>>>>>>>>>>> please let me know if I misunderstood something and it= =E2=80=99s > >>> not an > >>>>>>>>>>>> issue. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 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. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li < > >>>>>>>>>> ethanopensource@gmail.com> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Yes thanks. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde D=C3=B8ssin= g < > >>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your key to > >>>>>>>>>>>>>>>>>>>>> > https://dist.apache.org/repos/dist/release/storm/KEYS, > >>> you > >>>>>>>>>>>> should be > >>>>>>>>>>>>>>>>>> able > >>>>>>>>>>>>>>>>>>>>> to update it with an SVN client. See also > >>>>>>>>>>>>>>>>>>>>> https://www.apache.org/dev/openpgp.html#update. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li < > >>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call < > >>> bcall@apache.org > >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> bcall@apache.org>> (Thanks to him). > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> My pgp key: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>> > http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0x= A4A672F11B5050C8 > >>>>>>>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>> > http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0x= A4A672F11B5050C8 > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good to do release > with > >>> this key > >>>>>>>>>>>> now. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might want to includ= e > >>> in the new > >>>>>>>>>>>>>>>>>> release: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098 < > >>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098> > >>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < > >>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> > >>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < > >>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance. Thanks > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde D=C3=B8ssi= ng < > >>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li < > >>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s a good point. I will start a discus= sion > thread > >>> for it. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through the list: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>> > https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%= 20fixVersion%20%3D%202.0.1 > >>>>>>>>>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>> > https://issues.apache.org/jira/issues/?jql=3Dproject%20=3D%20STORM%20AND%= 20fixVersion%20=3D%202.0.1 > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> We introduced some new functionalities, includin= g > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-2720 > < > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-2720= > > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3412 > < > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3412= > > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3411 > < > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3411= > > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3442 > < > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3442= > > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3396 > < > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3396= > > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3392 > < > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3392= > > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3395 > < > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3395= > > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0 rather than > >>> 2.0.1. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we may want to > review > >>> before > >>>>>>>>>>>> the next > >>>>>>>>>>>>>>>>>>>>>>>> release: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094 < > >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094> > >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 < > >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990> > >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < > >>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo Louro < > >>>>>>>>>> hmclouro@gmail.com > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> +1 > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> 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. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>> Hugo > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM Ethan Li < > >>>>>>>>>>>>>>>>>> ethanopensource@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde > D=C3=B8ssing < > >>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I think ideally we've been trying for semver, > >>> but it's > >>>>>>>>>> been > >>>>>>>>>>>>>>>>>> pretty > >>>>>>>>>>>>>>>>>>>>>>>> loose, > >>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. there were breaking changes in one of th= e > >>> 1.2.x > >>>>>>>>>>>> releases > >>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>>>>> storm-kafka-client. I don't know what rules > we've > >>>>>>>>>> actually > >>>>>>>>>>>> been > >>>>>>>>>>>>>>>>>>>>>> using, > >>>>>>>>>>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>>>>>>>>>>>> any. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility would probabl= y > >>> be a good > >>>>>>>>>>>> rule of > >>>>>>>>>>>>>>>>>>>>>> thumb. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan > Li < > >>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what=E2=80=99s the versioning st= andard we > >>> have been > >>>>>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>>>>>>> (to > >>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or 2.1.0 release) = ? > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, Stig Rohde > >>> D=C3=B8ssing < > >>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Etha= n > >>> Li < > >>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s good idea to do more frequent= release. > I > >>> can run > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> next > >>>>>>>>>>>>>>>>>>>>>>>>>> release. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both PRs. Other than > >>> that, I > >>>>>>>>>>>> think we > >>>>>>>>>>>>>>>>>> should > >>>>>>>>>>>>>>>>>>>>>>>>>> also > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get > https://github.com/apache/storm/pull/3093 > >>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3093> > >>> in the > >>>>>>>>>> new > >>>>>>>>>>>>>>>>>> release. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM, Stig Rohde > >>> D=C3=B8ssing < > >>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 probabl= y > >>> also > >>>>>>>>>> easier > >>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>> users > >>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>> get > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> grips with (the fix list for 2.0.0 is > >>> enormous). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that in mind, I think we should star= t > >>> looking at > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> next > >>>>>>>>>>>>>>>>>>>>>> 2.x > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since it's been a coup= le > >>> of months > >>>>>>>>>>>> since > >>>>>>>>>>>>>>>>>> 2.0.0 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> released. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fix list would be > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>> > https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%= 20fixVersion%20%3D%202.0.1 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> . > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at least > >>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 > >>> seems like > >>>>>>>>>>>> it's > >>>>>>>>>>>>>>>>>> close > >>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > > --00000000000059fb93059001a8e4--