storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stig Rohde Døssing <stigdoess...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Mon, 12 Aug 2019 13:27:48 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message