Boy I feel like Mr. bylaws today. Not trying to be a jerk about this. The
bylaws say.
"A vote is required to accept a proposed release as an official release of the
project. Any Committer may call for a release vote at any point in time."
So Taylor is in his right to call for a vote on this, "at any point in time".
That said, I also agree with HeartSaVioR, more transparency is better, and
having some guidelines or at least consensus in the community about releases
and such is important.
For me keeping a release line open is mostly a question of having people who
are willing to maintain it. I did this for the 0.23 line in Hadoop because we
were going to do it internally anyways so why not make it official out in open
source and let others use it if they wanted to. I don't want to restrict
people too much in this, but we also need a good clear way to communicate these
things to our users.
I would like to see something along the lines of having a release manager for a
line of releases e.g. 0.9.x 0.10.x 1.x etc. And a status for different release
lines. The manager has no special power, they are just someone who has
committed to keep that line open. If we cannot find anyone who is willing to
be the manager for that line, the release line is marked as EOL, and no bug
fixes/features will be merged in. Similarly a release manager can decide that
they don't want new features to go into a line and can propose to move a line
to maintenance, if someone else is willing to take over as the release manager
for that line and support new feature work then they can take on that role.
I know it will come up when someone wants to revive a line that was in EOL. I
really don't like the idea of this, but without changing the bylaws I don't
think we can technically stop it.
On a side note to me if a bug fix is critical enough to trigger a release by
itself, we really should talk to the community about doing a release for other
lines that have the same problem.
- Bobby
On Tuesday, August 16, 2016 11:33 PM, Jungtaek Lim <[email protected]>
wrote:
Yes I agree we should respect and support Storm ecosystem, and also I have
been supportive for multi-lang feature. (ex. I addressed some issues what
StreamParse was suffering.)
But I'm also not supportive on non-transparent requests. I'd like to see
the requests be placed to user@ list, and we can start discussing a new
release based on that.
I respect the transparent consensus-driven model, and I believe following
the steps helps keeping the all the things transparent.
And if we see the benefit from the changes, it would make sense to help
0.10.x user first.
For me I'm +1 to release this with some proposals:
1. 0.10.2 has this change and released prior to or at the same time
2. We start discussion defining EOL, deprecated, stable, unstable version
lines. I saw HBase community was discussed about this but can't find it.
- Jungtaek Lim (HeartSaVioR)
2016년 8월 17일 (수) 오후 12:42, P. Taylor Goetz <[email protected]>님이 작성:
> My apologies for not making this a little more clear as to why I proposed
> this release.
>
> Yes, there are requests to fix this, but not necessarily on this list. The
> issue affects frameworks that are based on the multi-lang protocol (pystorm
> pyleus, etc.), most of which are external projects hosted elsewhere.
> There’s been a lot of support and contributions from those communities
> (python community, Mesos, etc.). These are communities we shouldn’t ignore.
>
> The patch is small and was easy to apply. It may help some users. Since
> there are no changes that require changes to the N/L files, there’s not
> much to review.
>
> As far as supporting earlier versions, EOLing version lines, etc., I think
> we owe it to our users to at least hear them out on the matter. To that end
> I will start a poll thread on user@ to get a bead on what our users are
> using.
>
> I’m +1 (binding) for this release. It benefits the community, and I see no
> reason not to proceed.
>
> -Taylor
>
> > On Aug 16, 2016, at 1:47 PM, Harsha Chintalapani <[email protected]>
> wrote:
> >
> > Do we have any user requests on releasing 0.9.x . I rather propose them
> to
> > move on to 0.10.x line and retire 0.9.x branches. There are quite few
> > issues that got fixed in 0.10.x release line and keep maintaining 0.9.x
> > line wouldn't be beneficial.
> >
> > Thanks,
> > Harsha
> >
> > On Mon, Aug 15, 2016 at 4:48 PM Jungtaek Lim <[email protected]> wrote:
> >
> >> Would it be better to have consensus for this?
> >>
> >> In bylaw we have this sentence 'In particular all releases must be
> approved
> >> by the PMC.'
> >> One of PMC can call out the discussion for releasing specific version,
> but
> >> general consensus should be made before starting prepare release.
> >>
> >> I'd like to see this starting from there. If we just want to also
> address
> >> opinions (not verification) of release from VOTE thread, I'll do that.
> >>
> >> Btw, personally I'm -1 for this release, since STORM-1928 is even not
> >> backported to 0.10.x version line.
> >> I'm even not supportive to maintain 0.x line (because we did the best
> >> effort for 0.x line users to move on 1.x), but if we really want to ship
> >> this bugfix to 0.x version line, for me it's more making sense to
> release
> >> 0.10.2.
> >>
> >> Thanks,
> >> Jungtaek Lim (HeartSaVioR)
> >>
> >> 2016년 8월 16일 (화) 오전 5:10, P. Taylor Goetz <[email protected]>님이 작성:
> >>
> >>> This is a call to vote on releasing Apache Storm 0.9.7 (rc1).
> >>>
> >>> This release candidate addresses a critical issue with Storm’s
> multi-lang
> >>> component where an improperly formed multi-lang spout message would
> cause
> >>> the spout to hang indefinitely.
> >>>
> >>> Full list of changes in this release:
> >>>
> >>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=CHANGELOG.md;hb=b75d9b2b6dbfd0fda0b114feafec1384bbfa30aa
> >>>
> >>> The tag/commit to be voted upon is v0.9.7:
> >>>
> >>>
> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=3d7c7be37ecc1dcc25223fde670d8185a6afbf00;hb=b75d9b2b6dbfd0fda0b114feafec1384bbfa30aa
> >>>
> >>> The source archive being voted upon can be found here:
> >>>
> >>>
> >>>
> >>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-0.9.7-rc1//apache-storm-0.9.7-src.tar.gz
> >>>
> >>> Other release files, signatures and digests can be found here:
> >>>
> >>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-0.9.7-rc1/
> >>>
> >>> 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
> >>>
> >>> The Nexus staging repository for this release is:
> >>>
> >>> https://repository.apache.org/content/repositories/orgapachestorm-1039
> >>>
> >>> Please vote on releasing this package as Apache Storm 0.9.7.
> >>>
> >>> When voting, please list the actions taken to verify the release.
> >>>
> >>> This vote will be open for at least 72 hours.
> >>>
> >>> [ ] +1 Release this package as Apache Storm 0.9.7
> >>> [ ] 0 No opinion
> >>> [ ] -1 Do not release this package because...
> >>>
> >>> Thanks to everyone who contributed to this release.
> >>>
> >>> -Taylor
> >>>
> >>
>
>
