storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Li <ethanopensou...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Tue, 13 Aug 2019 15:56:28 GMT
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 <stigdoessing@gmail.com> 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 <ethanopensource@gmail.com>:
> 
>> 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 <stigdoessing@gmail.com>
>> 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 <
>>> 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=false -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 <ethanopensource@gmail.com>
>>>>> 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 <ptgoetz@gmail.com>
>>>>> 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 <ethanopensource@gmail.com>
>>>>> 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 <ethanopensource@gmail.com>
>>>>> 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 <ptgoetz@gmail.com>
>>>>> 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 <
>>>>> 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. 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 <
>>>>> 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
>>>>> “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 <
>>>>> 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 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 <
>>>>>>>>>>>> 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 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 <
>>>>> 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 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 <dagit@apache.org
>>>>> <mailto:
>>>>>>>>>>>>>> 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 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 <dagit@apache.org
>>>>> <mailto:
>>>>>>>>>>>>>> dagit@apache.org>> 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 <
>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>> <mailto: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/ <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 <
>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>> bcall@apache.org>> (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 <
>>>>>>>>>>>>>>>>>>>> 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’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 <
>>>>>>>>>>>> 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øssing <
>>>>>>>>>>>>>>>>>>>>>>>>>> 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 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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>> 
>> 


Mime
View raw message