Yes this was started with my bad interpreting BYLAWS. I misunderstood "call for a release vote" as initiating discussion about new release. Sorry about that all.
2016년 8월 17일 (수) 오후 11:45, Bobby Evans <ev...@yahoo-inc.com.invalid>님이 작성: > 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 <kabh...@gmail.com> > 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 <ptgo...@gmail.com>님이 작성: > > > 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 <st...@harsha.io> > > 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 <kabh...@gmail.com> > 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 <ptgo...@gmail.com>님이 작성: > > >> > > >>> 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 > > >>> > > >> > > > > > >
