Those can be safely deleted. -Taylor
> On Aug 13, 2019, at 12:15 PM, Ethan Li <[email protected]> wrote: > > 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://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails > > <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails> > 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/> > > Just want to be absolutely sure about this. Thanks. > >> On Aug 13, 2019, at 10:56 AM, Ethan Li <[email protected]> wrote: >> >> That sounds better. It will be easier for release. Thank you for looking >> into this. >> >>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <[email protected]> >>> wrote: >>> >>> 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 <[email protected]>: >>> >>>> Thanks Stig. >>>> >>>> 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 “mvn >>>> release:prepare” since “ mvn release:prepare” will 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øssing <[email protected]> >>>> 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øssing < >>>>> [email protected]>: >>>>> >>>>>> 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=false -B" in the project root. It >>>>>> should update the file for you. >>>>>> >>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li < >>>> [email protected] >>>>>>> : >>>>>> >>>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>> 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=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >>>>>>> < >>>>>>> >>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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> ? >>>>>>>>>> >>>>>>>>>> Thanks very much >>>>>>>>>> >>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li <[email protected]> >>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue the process now >>>>>>> and update the documentation later. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz <[email protected]> >>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 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: >>>>>>>>>>>> >>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples >>>>>>>>>>>> >>>>>>>>>>>> -Taylor >>>>>>>>>>>> >>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing < >>>>>>> [email protected]> 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. Unless >>>>>>> you enable >>>>>>>>>>>>> that profile, the storm-dist modules aren't in the reactor. >>>>>>>>>>>>> >>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li < >>>>>>> [email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>> “mvn:prepare” >>>>>>>>>>>>>> and “mvn:perform”. 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’s >>>>>>>>>>>>>> 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 “mvn:prepare” step. How do I >>>>>>> get >>>>>>>>>>>>>> storm-dist pom version updated with “mv:prepare”? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am currently blocked on this. Any help will be appreciated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing < >>>>>>> [email protected]> >>>>>>>>>>>>>> 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 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? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li < >>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 to >>>>>>> Taylor. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please don’t merge anything to master or 2.1.x-branch for now. >>>>>>> Thanks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li < >>>>>>> [email protected]> >>>>>>>>>>>>>> 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 are >>>>>>> to be >>>>>>>>>>>>>>>> addressed but Author hasn’t responded yet.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It’s 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit <[email protected] >>>>>>> <mailto: >>>>>>>>>>>>>>>> [email protected]>> 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 policy >>>>>>> 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’s 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 <[email protected] >>>>>>> <mailto: >>>>>>>>>>>>>>>> [email protected]>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde >>>>>>> Døssing 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, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 RM >>>>>>> and >>>>>>>>>>>>>>>> community >>>>>>>>>>>>>>>>>>>>> can of course make more as necessary >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS branches, which are >>>>>>> cut once a >>>>>>>>>>>>>>>>>>>>> year off master >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of change >>>> (including >>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break compatibility just >>>>>>> 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 would >>>>>>> be to set >>>>>>>>>>>>>>>>>>>> expectations among developers and the community, and here >>>>>>> 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 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. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit < >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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/ <https://semver.org/>). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something like this, to name >>>>>>> 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’t have a 2.0.x-branch and master is >>>>>>> actually >>>>>>>>>>>>>>>>>>>>>> “2.0.1-SNAPSHOT”. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>> “2.2.0-SNAPSHOT”. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 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’s the right way to make >>>>>>> things >>>>>>>>>>>>>>>> right. Or >>>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood something and it’s >>>>>>> not an >>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Btw, I am seeing the same issue with 1.x-branch. We >>>>>>> shouldn’t >>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yes thanks. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing < >>>>>>>>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call < >>>>>>> [email protected] >>>>>>>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>> (Thanks to him). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> My pgp key: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 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 include >>>>>>> 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øssing < >>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li < >>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s a good point. I will start a discussion >>>> thread >>>>>>> for it. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through the list: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new functionalities, including >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde >>>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 the >>>>>>> 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 probably >>>>>>> be a good >>>>>>>>>>>>>>>> rule of >>>>>>>>>>>>>>>>>>>>>>>>>> thumb. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan >>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what’s the versioning standard 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øssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan >>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s 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øssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 probably >>>>>>> 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 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>> https://issues.apache.org/jira/issues/?jql=project%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? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>> >>>> >> >
