[VOTE]: Release Apache RocketMQ 4.0.0(incubating) (RC3)
Hello Incubator PMC, The Apache RocketMQ community has voted and approved the proposal to release Apache RocketMQ 4.0.0 (incubating). We now kindly request the IPMC review and vote on this incubator release. [VOTE] Thread: https://lists.apache.org/thread.html/349e3268cf5ae7ec65d1cd584362c76bd11f86afb935b2bfb8ee6b6b@%3Cdev.rocketmq.apache.org%3E [RESULT][VOTE] Thread: https://lists.apache.org/thread.html/6487e8afc7a71cbdf9848d1270997ec55ffe6cb9e7a2ddfce2bedb35@%3Cdev.rocketmq.apache.org%3E The RC3 artifacts: https://dist.apache.org/repos/dist/dev/incubator/rocketmq/4.0.0-incubating-rc3/ Git tag for the release: https://github.com/apache/incubator-rocketmq/tree/rocketmq-4.0.0-incubating Hash for the release tag: dddc3daa2cbec4c7240d6525d2ce198826d29967 Release Notes: http://rocketmq.incubator.apache.org/release_notes/release-notes-4.0.0-incubating/ The artifacts have been signed with Key : E9BDDB0E, which can be found in the keys file: https://dist.apache.org/repos/dist/dev/incubator/rocketmq/KEYS The maven release artifacts: https://repository.apache.org/content/repositories/orgapacherocketmq-1003 The vote will be open for at least 72 hours or until necessary number of votes are reached. Please vote accordingly: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove with the reason Here is my +1 Thanks, The Apache RocketMQ Team
Re: Approving flawed release candidates
While I agree with what both John and Marvin are saying, the key word here is “discretion”. Obviously the IPMC shouldn’t give podlings too hard a time (we all know how difficult and time consuming it is to go through a cycle consisting of a release candidate and TWO votes, and the mechanics of the release process are intimidating to the uninitiated). But also IPMC members are at liberty to say “I don’t like the look of that, I’m voting -1”. A -1 doesn’t veto a release (we just need 3 more +1s than -1s), and IPMC members can always change their vote after a discussion. I would strongly recommend podlings to log JIRA cases when issues raised during the vote. If they show that they are committed to fixing those issues in the next release, the IPMC almost always relents. Conversely, nothing pisses me off more when reviewing a release than seeing the same issue I raised last release, and you can guess how I’m going to vote when I feel my time has been wasted. Julian > On Feb 15, 2017, at 6:54 PM, John D. Ament wrote: > > Hi Marvin, > > I don't think there's anything you're stating here that isn't in accordance > to processes we have been following. If I look at the current Traffic > Control vote, the problems I see are: > > - Assertion from the podling that they fixed the release, and votes from > mentors indicating they fixed the prior release problems, but in actuality > many of them are not fixed. > > - In the prior release vote (and I apologize, I missed that there was an > RC8 passed our way), questions were raised by Justin asking for JIRA > tickets for the open issues that were not addressed, without any response > (hence I can only assume no JIRAs were filed) > > In general, I think what you're describing is what we're following. Its > the uncommon case where an imperfect release is being revoted on, mostly > because of the podling not following up with questions. > > I'll point out that the Singa vote is one where I feel the current legal > advice is vague enough that I cannot make a clear statement whether or not > allowing the release would put any legal strain on the ASF, in addition to > it being vague enough on what we consider a build tool, or how to interpret > the autoconf headers. One way to look at it - the ASF would produce GPL'd > code which is a big no-no (and I wouldn't think would be acceptable as a > JIRA ticket to fix later). > > - John > > > On Wed, Feb 15, 2017 at 8:27 PM Marvin Humphrey > wrote: > >> Greets, >> >> We take pains to advise downstream consumers that podling releases are >> "incubating" because they may not live up to the standards expected of >> Apache TLPs -- whether that is because the community is not mature, >> because the release is not fully compliant with ASF policies, or what >> have you. >> >> A while back, the IPMC arrived at a consensus about the circumstances >> under which we might approve incubating release candidates which are >> legal to distribute yet do not fulfill all aspects of Apache policy. >> A test was proposed by IPMC member and ASF Board member Bertrand >> Delacretaz: "Does it put the Foundation at risk?" >> >> https://wiki.apache.org/incubator/January2014 >> >> 3. Consensus was built for a controlled regime for relaxing policy on >> incubating releases under appropriate circumstances, potentially >> reducing the number of release candidates we force podlings to >> cycle through. >> >> The first release candidate approved under that relaxed regime bundled >> jar files in the source release. The podling promised to remove them in >> the next point release (and subsequently followed through): >> >> * Exercising the new regime for controlled relaxation of policy, a >>bugfix release by Spark (0.8.1) which bundled jar files was approved >>by the IPMC after the podling presented a roadmap to eliminating >>them in the next minor point release (0.9). >> >> For IPMC members evaluating a flawed release candidate (whether Mentors >> or "freelance" IPMC reviewers on general@incubator), perhaps consider >> the following workflow: >> >>1. When policy violations which do not put the Foundation at risk >>are discovered in an RC, vote -1 until tickets are filed. Once >>they're filed, change vote to +1. >>2. If a release candidate has policy issues which were brought to >>light on a previous RC and should reasonably have been fixed >>already, vote -1. (We may be tolerant but we're still serious.) >> >> In particular, there are two common classes of problem that I think can >> be handled this way: >> >> The first is licensing documentation bugs, such as missing "forwarded" >> dependency licenses in LICENSE, and extra junk in NOTICE. (Actual >> licensing violations which make the RC illegal to redistribute are a >> different story.) >> >> The second is bundled compiled code, such as jar files. I've written at >> length elsewhere on why we exclude
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
Hi, > Or is your feeling that inclusion of the LICENSE is enough of a prominent > statement? In this case yes I can't see any reason to include it in NOTICE and LICENSE inclusion would be enough. But I'd be interested in what other IPMC people think. Either way it’s not a big issue, at worst a minor documentation issue, but if NOTICEs can be kept small they should. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Approving flawed release candidates
Hi Marvin, I don't think there's anything you're stating here that isn't in accordance to processes we have been following. If I look at the current Traffic Control vote, the problems I see are: - Assertion from the podling that they fixed the release, and votes from mentors indicating they fixed the prior release problems, but in actuality many of them are not fixed. - In the prior release vote (and I apologize, I missed that there was an RC8 passed our way), questions were raised by Justin asking for JIRA tickets for the open issues that were not addressed, without any response (hence I can only assume no JIRAs were filed) In general, I think what you're describing is what we're following. Its the uncommon case where an imperfect release is being revoted on, mostly because of the podling not following up with questions. I'll point out that the Singa vote is one where I feel the current legal advice is vague enough that I cannot make a clear statement whether or not allowing the release would put any legal strain on the ASF, in addition to it being vague enough on what we consider a build tool, or how to interpret the autoconf headers. One way to look at it - the ASF would produce GPL'd code which is a big no-no (and I wouldn't think would be acceptable as a JIRA ticket to fix later). - John On Wed, Feb 15, 2017 at 8:27 PM Marvin Humphrey wrote: > Greets, > > We take pains to advise downstream consumers that podling releases are > "incubating" because they may not live up to the standards expected of > Apache TLPs -- whether that is because the community is not mature, > because the release is not fully compliant with ASF policies, or what > have you. > > A while back, the IPMC arrived at a consensus about the circumstances > under which we might approve incubating release candidates which are > legal to distribute yet do not fulfill all aspects of Apache policy. > A test was proposed by IPMC member and ASF Board member Bertrand > Delacretaz: "Does it put the Foundation at risk?" > >https://wiki.apache.org/incubator/January2014 > >3. Consensus was built for a controlled regime for relaxing policy on > incubating releases under appropriate circumstances, potentially > reducing the number of release candidates we force podlings to > cycle through. > > The first release candidate approved under that relaxed regime bundled > jar files in the source release. The podling promised to remove them in > the next point release (and subsequently followed through): > > * Exercising the new regime for controlled relaxation of policy, a > bugfix release by Spark (0.8.1) which bundled jar files was approved > by the IPMC after the podling presented a roadmap to eliminating > them in the next minor point release (0.9). > > For IPMC members evaluating a flawed release candidate (whether Mentors > or "freelance" IPMC reviewers on general@incubator), perhaps consider > the following workflow: > > 1. When policy violations which do not put the Foundation at risk > are discovered in an RC, vote -1 until tickets are filed. Once > they're filed, change vote to +1. > 2. If a release candidate has policy issues which were brought to > light on a previous RC and should reasonably have been fixed > already, vote -1. (We may be tolerant but we're still serious.) > > In particular, there are two common classes of problem that I think can > be handled this way: > > The first is licensing documentation bugs, such as missing "forwarded" > dependency licenses in LICENSE, and extra junk in NOTICE. (Actual > licensing violations which make the RC illegal to redistribute are a > different story.) > > The second is bundled compiled code, such as jar files. I've written at > length elsewhere on why we exclude these systemically (as have others > such as Roy Fielding), but they are a policy issue rather than a legal > issue. > > Finally, there's one other common case worth mentioning which requires > slightly different treatement: dependencies with unapproved licenses. > These may be OK for incubating releases, but first require approval by > VP Legal. > > Incubation disclaimers give us the flexibility to bring podlings into > compliance incrementally. At the same time, because podlings may not be > in compliance, incubation disclaimers are important -- two sides of the > same coin. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On Wed, Feb 15, 2017 at 9:27 PM Justin Mclean wrote: > Hi, > > > The reason is that the license is a Cat B. Otherwise, I would advise to > > include it in your notices file as well. NiFi does this well IMHO > > > https://github.com/apache/nifi/blob/d838f61291d2582592754a37314911b701c6891b/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/resources/META-INF/NOTICE > > As far as I can see there nothing in the OFL that makes it a required > notice and for anything to be place in NOTICE. What am I missing? > TBH, I'm not sure, and I'm perfectly OK if someone says "no, you're wrong." Most projects I've looked at have it within the NOTICE file. This seems to line up with our application of it in the Cat B list though http://apache.org/legal/resolved.html#category-b Or is your feeling that inclusion of the LICENSE is enough of a prominent statement? > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
Hi, > The reason is that the license is a Cat B. Otherwise, I would advise to > include it in your notices file as well. NiFi does this well IMHO > https://github.com/apache/nifi/blob/d838f61291d2582592754a37314911b701c6891b/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/resources/META-INF/NOTICE As far as I can see there nothing in the OFL that makes it a required notice and for anything to be place in NOTICE. What am I missing? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
Perfect, thanks Dan. I'll point out that after looking at the PR I do see one more issue. For the font files, can you point to a public location for them? google tends to provide a free service hosting a number of fonts. The reason is that the license is a Cat B. Otherwise, I would advise to include it in your notices file as well. NiFi does this well IMHO https://github.com/apache/nifi/blob/d838f61291d2582592754a37314911b701c6891b/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/resources/META-INF/NOTICE John On Wed, Feb 15, 2017 at 7:56 PM Dan Kirkwood wrote: > Thanks, John..we do have a new PR that intends to address these > issues (currently only in master): > https://github.com/apache/incubator-trafficcontrol/pull/285 > > I intend to examine that tomorrow morning and pull it in to 1.8 if all > looks good -- there will be a few changes needed to address diffs > between 1.8 and master, but not significant. If you have a chance > to look at that PR and give a thumbs-up, it would help greatly.. > > thanks for all your help.. Dan > > On Wed, Feb 15, 2017 at 5:37 PM, John D. Ament > wrote: > > On Wed, Feb 15, 2017 at 5:10 PM Marvin Humphrey > > wrote: > > > >> On Wed, Feb 15, 2017 at 1:00 PM, John D. Ament > >> wrote: > >> > On Wed, Feb 15, 2017 at 3:05 PM Marvin Humphrey < > mar...@rectangular.com> > >> > wrote: > >> > > >> >> On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood > >> wrote: > >> > >> > Personally, the reason why I'm asking about the impact is to better > make > >> a > >> > judgment call on whether to block or not. I don't particularly see > why > >> > we're now being jumped on over this fact. > >> > >> John, > >> > >> My email was rushed because I wanted to preempt cancellation of the > >> vote. I see now that it can be read in a more confrontational tone > >> than was meant. > >> > >> Thank you very much for taking the time to review the release > >> candidate. I'll make the case for more lenience in general when > >> approving incubating release candidates on a separate thread later > >> today. > >> > > > > Marvin, > > > > Its OK. I myself am frazzled over lots of things going on around me. > So I > > know some of my responses as of late have either been way too > > short/confrontational and too long/fillibustery. So I know where you're > > coming from. > > > > I look forward to arguing with you over podling releases in a separate > > thread. > > > > Dan, > > > > So here's my point of view. Justin's provided some more context on how > to > > shape licenses. If you feel very strongly that the release should go out > > the door, the way it is, then I am OK with changing my vote to a +1. If > > however, you're like me, and would prefer accuracy over speed, I think > its > > worth your time to fix the remaining license issues, package up a CR10, > and > > see that the IPMC votes +1 without reservations (it gives better > confidence > > that you can cut an ASF release). > > > > I'm even willing to help you rewrite your license file for accuracy. > > > > John > > > > > >> > >> Marvin Humphrey > >> > >> - > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[RESULT][VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1
Hello All, Voting for Apache Mynewt 1.0.0-b2-incubating-rc1. The release has passed. The vote breakdown is as follows: +1 John D Ament (binding) +1 Jim Jagielski (binding) +1 Sterling Hughes (binding) Total: +3 binding. Thank you to all who voted. Thanks, Will - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Approving flawed release candidates
Greets, We take pains to advise downstream consumers that podling releases are "incubating" because they may not live up to the standards expected of Apache TLPs -- whether that is because the community is not mature, because the release is not fully compliant with ASF policies, or what have you. A while back, the IPMC arrived at a consensus about the circumstances under which we might approve incubating release candidates which are legal to distribute yet do not fulfill all aspects of Apache policy. A test was proposed by IPMC member and ASF Board member Bertrand Delacretaz: "Does it put the Foundation at risk?" https://wiki.apache.org/incubator/January2014 3. Consensus was built for a controlled regime for relaxing policy on incubating releases under appropriate circumstances, potentially reducing the number of release candidates we force podlings to cycle through. The first release candidate approved under that relaxed regime bundled jar files in the source release. The podling promised to remove them in the next point release (and subsequently followed through): * Exercising the new regime for controlled relaxation of policy, a bugfix release by Spark (0.8.1) which bundled jar files was approved by the IPMC after the podling presented a roadmap to eliminating them in the next minor point release (0.9). For IPMC members evaluating a flawed release candidate (whether Mentors or "freelance" IPMC reviewers on general@incubator), perhaps consider the following workflow: 1. When policy violations which do not put the Foundation at risk are discovered in an RC, vote -1 until tickets are filed. Once they're filed, change vote to +1. 2. If a release candidate has policy issues which were brought to light on a previous RC and should reasonably have been fixed already, vote -1. (We may be tolerant but we're still serious.) In particular, there are two common classes of problem that I think can be handled this way: The first is licensing documentation bugs, such as missing "forwarded" dependency licenses in LICENSE, and extra junk in NOTICE. (Actual licensing violations which make the RC illegal to redistribute are a different story.) The second is bundled compiled code, such as jar files. I've written at length elsewhere on why we exclude these systemically (as have others such as Roy Fielding), but they are a policy issue rather than a legal issue. Finally, there's one other common case worth mentioning which requires slightly different treatement: dependencies with unapproved licenses. These may be OK for incubating releases, but first require approval by VP Legal. Incubation disclaimers give us the flexibility to bring podlings into compliance incrementally. At the same time, because podlings may not be in compliance, incubation disclaimers are important -- two sides of the same coin. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
Thanks, John..we do have a new PR that intends to address these issues (currently only in master): https://github.com/apache/incubator-trafficcontrol/pull/285 I intend to examine that tomorrow morning and pull it in to 1.8 if all looks good -- there will be a few changes needed to address diffs between 1.8 and master, but not significant. If you have a chance to look at that PR and give a thumbs-up, it would help greatly.. thanks for all your help.. Dan On Wed, Feb 15, 2017 at 5:37 PM, John D. Ament wrote: > On Wed, Feb 15, 2017 at 5:10 PM Marvin Humphrey > wrote: > >> On Wed, Feb 15, 2017 at 1:00 PM, John D. Ament >> wrote: >> > On Wed, Feb 15, 2017 at 3:05 PM Marvin Humphrey >> > wrote: >> > >> >> On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood >> wrote: >> >> > Personally, the reason why I'm asking about the impact is to better make >> a >> > judgment call on whether to block or not. I don't particularly see why >> > we're now being jumped on over this fact. >> >> John, >> >> My email was rushed because I wanted to preempt cancellation of the >> vote. I see now that it can be read in a more confrontational tone >> than was meant. >> >> Thank you very much for taking the time to review the release >> candidate. I'll make the case for more lenience in general when >> approving incubating release candidates on a separate thread later >> today. >> > > Marvin, > > Its OK. I myself am frazzled over lots of things going on around me. So I > know some of my responses as of late have either been way too > short/confrontational and too long/fillibustery. So I know where you're > coming from. > > I look forward to arguing with you over podling releases in a separate > thread. > > Dan, > > So here's my point of view. Justin's provided some more context on how to > shape licenses. If you feel very strongly that the release should go out > the door, the way it is, then I am OK with changing my vote to a +1. If > however, you're like me, and would prefer accuracy over speed, I think its > worth your time to fix the remaining license issues, package up a CR10, and > see that the IPMC votes +1 without reservations (it gives better confidence > that you can cut an ASF release). > > I'm even willing to help you rewrite your license file for accuracy. > > John > > >> >> Marvin Humphrey >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On 2/15/17, 4:37 PM, "John D. Ament" wrote: >Dan, > >So here's my point of view. Justin's provided some more context on how to >shape licenses. If you feel very strongly that the release should go out >the door, the way it is, then I am OK with changing my vote to a +1. If >however, you're like me, and would prefer accuracy over speed, I think its >worth your time to fix the remaining license issues, package up a CR10, >and >see that the IPMC votes +1 without reservations (it gives better >confidence >that you can cut an ASF release). > >I'm even willing to help you rewrite your license file for accuracy. Here's another possible way to think about it: A podling really should be trying to graduate ASAP. My project only cut one release before graduating. If you are pretty certain you are going to cut another release before graduating, I would ship RC9 and fix it for the next release. And even if you aren't going to cut another release before graduating, since the point of incubation is education, unless anybody in the IPMC thinks you haven't learned enough, I'd say you have. That's because to me, an even more important aspect than choosing "accuracy over speed" is whether your community and RM has the time and energy to go through another RC after 9 RCs so far. Sometimes it is better to ship and take a break from the RC train, especially if you are sure you are going to cut another release while in incubation. The foundation probably isn't at risk here. Community over code. My 2 cents -Alex
Re: [VOTE] Releasing Apache Metron (incubating) 0.3.1-RC4
+1 release contents look good. Please don't forget as a part of https://issues.apache.org/jira/browse/METRON-589 I'll be expecting to see you remove 0.3.0 once 0.3.1 is published. John On Wed, Feb 15, 2017 at 10:21 AM Casey Stella wrote: > This is a call to vote on releasing Apache Metron 0.3.1-RC4 incubating > > Full list of changes in this release: > https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. > 1-RC4-incubating/CHANGES > > The tag/commit to be voted upon is apache-metron-0.3.1-rc4-incubating: > https://git-wip-us.apache.org/repos/asf?p=incubator-metron. > git;a=shortlog;h=refs/tags/apache-metron-0.3.1-rc4-incubating > > The source archive being voted upon can be found here: > https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. > 1-RC4-incubating/apache-metron-0.3.1-rc4-incubating.tar.gz > > Other release files, signatures and digests can be found here: > https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. > 1-RC4-incubating/ > > The release artifacts are signed with the following key: > https://git-wip-us.apache.org/repos/asf?p=incubator-metron. > git;a=blob;f=KEYS;h=8381e96d64c249a0c1b489bc0c234d9c260ba55e;hb=refs/tags/ > apache-metron-0.3.1-rc4-incubating > > The book associated with this RC is located at > https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. > 1-RC4-incubating/book-site/index.html > > Please vote on releasing this package as Apache Metron 0.3.1-RC4 incubating > > When voting, please list the actions taken to verify the release. > > Recommended build validation and verification instructions are posted here: > https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds > > > This vote will be open for at least 72 hours. > > [ ] +1 Release this package as Apache Metron 0.3.1-RC4 incubating > > [ ] 0 No opinion > > [ ] -1 Do not release this package because... >
Re: [VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1
+1 release contents look good. On Thu, Feb 9, 2017 at 10:25 PM will sanfilippo wrote: > Hello, > > The Apache Mynewt Incubator PPMC has approved a proposal to release > Apache Mynewt 1.0.0-b2-incubating-rc1. We now kindly request that the > Incubator PMC members review and vote on this incubator release. > > Apache Mynewt is a community-driven, permissively licensed open source > initiative for constrained, embedded applications. Mynewt provides a > real-time operating system, flash file system, network stacks, and > support utilities for real-world embedded systems. > > For full release notes, please visit the Apache Mynewt Wiki: > https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes > > [VOTE] thread: > > https://lists.apache.org/thread.html/250715a1a904632ee77d1ca1c24e657dd2eda42d782f3d27ee93e57e@%3Cdev.mynewt.apache.org%3E > > [RESULT][VOTE] thread: > > https://lists.apache.org/thread.html/73ca1bec7bcfbf84643d9d9d474381d280f5069503aece2d00e74667@%3Cdev.mynewt.apache.org%3E > > [DISCUSS] thread: > > https://lists.apache.org/thread.html/c5323ae5cd8d41dadc908a84b5ce994d64f1ac2df84b3ae27a1529ea@%3Cdev.mynewt.apache.org%3E > > This release candidate was tested as follows: > 1. Manual execution of the Mynewt Test plan: > > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan > > The test results can be found at: > > https://cwiki.apache.org/confluence/display/MYNEWT/1.0.0-b2+Test+Results > > 2. The full unit test suite for this release was executed via “newt > test all” with no failures. This testing was performed on the > following platforms: > * OS X 10.10.5 > * Linux 4.4.6 (Gentoo) > > The release candidate to be voted on is available at: > > https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b2-incubating/rc1/ > > The commits under consideration are as follows: > blinky: > repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky > commit a69b409197a845bc75748af564cb08c4ec7701d4 > core: > repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core > commit de35d2337189a69d97aa3fdccc4f7bfaeb31efc9 > newt: > repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt > commit fdac74ff83f21a11c7fbaa2e1adc2d50cbf1e612 > > In addition, the following newt convenience binaries are available: > linux: > https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b2-incubating/rc1/apache-mynewt-newt-bin-linux-1.0.0-b2-incubating.tgz > osx: > https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b2-incubating/rc1/apache-mynewt-newt-bin-osx-1.0.0-b2-incubating.tgz > > The release candidate is signed with a GPG key available at: > https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS > > The vote is open for at least 72 hours. > > [ ] +1 Release this package > [ ] 0 I don't feel strongly about it, but don't object > [ ] -1 Do not release this package because... > > Thanks, > Will San Filippo > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On Wed, Feb 15, 2017 at 5:10 PM Marvin Humphrey wrote: > On Wed, Feb 15, 2017 at 1:00 PM, John D. Ament > wrote: > > On Wed, Feb 15, 2017 at 3:05 PM Marvin Humphrey > > wrote: > > > >> On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood > wrote: > > > Personally, the reason why I'm asking about the impact is to better make > a > > judgment call on whether to block or not. I don't particularly see why > > we're now being jumped on over this fact. > > John, > > My email was rushed because I wanted to preempt cancellation of the > vote. I see now that it can be read in a more confrontational tone > than was meant. > > Thank you very much for taking the time to review the release > candidate. I'll make the case for more lenience in general when > approving incubating release candidates on a separate thread later > today. > Marvin, Its OK. I myself am frazzled over lots of things going on around me. So I know some of my responses as of late have either been way too short/confrontational and too long/fillibustery. So I know where you're coming from. I look forward to arguing with you over podling releases in a separate thread. Dan, So here's my point of view. Justin's provided some more context on how to shape licenses. If you feel very strongly that the release should go out the door, the way it is, then I am OK with changing my vote to a +1. If however, you're like me, and would prefer accuracy over speed, I think its worth your time to fix the remaining license issues, package up a CR10, and see that the IPMC votes +1 without reservations (it gives better confidence that you can cut an ASF release). I'm even willing to help you rewrite your license file for accuracy. John > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [discuss] Apache Gobblin Incubator Proposal
Hi Thanks for the proposal Jim! I will add you as a mentor then start the vote Cheers Olivier On 16 February 2017 at 02:35, Jim Jagielski wrote: > If you need/want another mentor, I volunteer > > > On Feb 14, 2017, at 3:53 PM, Olivier Lamy wrote: > > > > Hi > > Well I don't see issues as no one discuss the proposal. > > So I will start the official vote tomorrow. > > Cheers > > Olivier > > > > On 6 February 2017 at 14:08, Olivier Lamy wrote: > > > >> Hello everyone, > >> I would like to submit to you a proposal to bring Gooblin to the Apache > >> Software Foundation. > >> The text of the proposal is included below and available as a draft here > >> in the Wiki: https://wiki.apache.org/incubator/GobblinProposal > >> > >> We will appreciate any feedback and input. > >> > >> Olivier on behalf of the Gobblin community > >> > >> > >> = Apache Gobblin Proposal = > >> == Abstract == > >> Gobblin is a distributed data integration framework that simplifies > common > >> aspects of big data integration such as data ingestion, replication, > >> organization and lifecycle management for both streaming and batch data > >> ecosystems. > >> > >> == Proposal == > >> > >> Gobblin is a universal data integration framework. The framework has > been > >> used to build a variety of big data applications such as ingestion, > >> replication, and data retention. The fundamental constructs provided by > the > >> Gobblin framework are: > >> > >> 1. An expandable set of connectors that allow data to be integrated from > >> a variety of sources and sinks. The range of connectors already > available > >> in Gobblin are quite diverse and are an ever expanding set. To highlight > >> just a few examples, connectors exist for databases (e.g., MySQL, Oracle > >> Teradata, Couchbase etc.), web based technologies (REST APIs, FTP/SFTP > >> servers, Filers), scalable storage (HDFS, S3, Ambry etc,), streaming > data > >> (Kafka, EventHubs etc.), and a variety of proprietary data sources and > >> sinks (e.g.Salesforce, Google Analytics, Google Webmaster etc.). > Similarly, > >> Gobblin has a rich library of converters that allow for conversion of > data > >> from one format to another as data moves across system boundaries (e.g. > >> AVRO in HDFS to JSON in another system). > >> > >> > >> 2. Gobblin has a well defined and customizable state management layer > >> that allows writing stateful applications. These are particularly useful > >> when solving problems like bulk incremental ingest and keeping several > >> clusters replicated in sync. The ability to record work that has been > >> completed and what remains in a scalable manner is critical to writing > such > >> diverse applications successfully. > >> > >> > >> 3. Gobblin is agnostic to the underlying execution engine. It can be > >> tailored to run ontop of a variety of execution frameworks ranging from > >> multiple processes on a single node, to open source execution engines > like > >> MapReduce, Spark or Samza, natively on top of raw containers like Yarn > or > >> Mesos, and the public cloud like Amazon AWS or Microsoft Azure. We are > >> extending Gobblin to run on top of a self managed cluster when security > is > >> vital. This allows different applications that require different > degrees > >> of scalability, latency or security to be customized to for their > specific > >> needs. For example, highly latency sensitive applications can be > executed > >> in a streaming environment while batch based execution might benefit > >> applications where the priority might be geared towards optimal > container > >> utilization. > >> > >> 4.Gobblin comes out of the box with several diagnosability features like > >> Gobblin metrics and error handling. Collectively, these features allow > >> Gobblin to operate at the scale of petabytes of data. To give just one > >> example, the ability to quarantine a few bad records from an isolated > Kafka > >> topic without stopping the entire flow from continued execution is vital > >> when the number of Kafka topics range in the thousands and the > collective > >> data handled is in the petabytes. > >> > >> Gobblin thus provides crisply defined software constructs that can be > used > >> to build a vast array of data integration applications customizable for > >> varied user needs. It has become a preferred technology for data > >> integration use-cases by many organizations worldwide (see a partial > list > >> here). > >> > >> == Background == > >> > >> Over the last decade, data integration has evolved use case by use case > in > >> most companies. For example, at LinkedIn, when Kafka became a > significant > >> part of the data ecosystem, a system called Camus was built to ingest > this > >> data for analytics processing on Hadoop. Similarly, we had custom > pipelines > >> to ingest data from Salesforce, Oracle and myriad other sources. This > >> pattern became the norm rather than the exception and one point, > LinkedIn > >> was running at leas
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On Wed, Feb 15, 2017 at 1:00 PM, John D. Ament wrote: > On Wed, Feb 15, 2017 at 3:05 PM Marvin Humphrey > wrote: > >> On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood wrote: > Personally, the reason why I'm asking about the impact is to better make a > judgment call on whether to block or not. I don't particularly see why > we're now being jumped on over this fact. John, My email was rushed because I wanted to preempt cancellation of the vote. I see now that it can be read in a more confrontational tone than was meant. Thank you very much for taking the time to review the release candidate. I'll make the case for more lenience in general when approving incubating release candidates on a separate thread later today. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
Hi, > Thanks, John.. I'm confused on this. According to > http://www.apache.org/dev/licensing-howto.html#permissive-deps : > > `In LICENSE, add a pointer to the dependency's license within the > distribution and a short note summarizing its licensing:` The pointer mentioned there is a file path to a text file in the release containing the full text of the license. The problem with using URLs is that decay over time or their contents may change or the software may be re-released under another license. > Is MIT a special case in this regard? No, the it a condition of the license "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” and most licenses have a clause similar to this. Note that in a lot of cases you are abiding by this clause if the MIT licensed files in question have MIT headers. However in this case the MIT licensed JS files don’t have license headers. > And in that case, do we need a separate full license entry for each > MIT-licensed component we use? Yes as per terms of the MIT license, but it doesn’t have to be in the LICENSE file, a pointer to the full text is preferred, especially in the case of long/many licenses. > Is this RC acceptable other than the license issues you pointed out? Sorry I’ve not had a chance to look in detail yet but will do in the next couple of days. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On Wed, Feb 15, 2017 at 3:05 PM Marvin Humphrey wrote: > On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood wrote: > > You're right -- fixing the license file is not a huge effort (now that > > we understand what's expected..). The effort is in going thru the > > voting process again.. > > > > I'll go with whatever you recommend.. > > Folks, we're on RC *nine*. The IPMC has the discretion to apply the > "does it put the Foundation at risk" test for releases which don't > follow policy yet are still legal. This would seem like a good time > to be flexible. > While we're on RC9, the IPMC has only been presented with 2 votes. I have no idea what happened between RC5 and RC9. Personally, the reason why I'm asking about the impact is to better make a judgment call on whether to block or not. I don't particularly see why we're now being jumped on over this fact. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood wrote: > You're right -- fixing the license file is not a huge effort (now that > we understand what's expected..). The effort is in going thru the > voting process again.. > > I'll go with whatever you recommend.. Folks, we're on RC *nine*. The IPMC has the discretion to apply the "does it put the Foundation at risk" test for releases which don't follow policy yet are still legal. This would seem like a good time to be flexible. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
You're right -- fixing the license file is not a huge effort (now that we understand what's expected..). The effort is in going thru the voting process again.. I'll go with whatever you recommend.. thanks.. Dan On Wed, Feb 15, 2017 at 10:58 AM, John D. Ament wrote: > I'd like to know the effort required from your POV to fix the license > file. Alex's description matches my expectations, thanks for clarifying > it. I would rather not create a release that didn't match the licensing > requirements, but will be OK if you come back saying its a huge effort > (however, I can't imagine copy and pasting license contents is difficult). > > On Wed, Feb 15, 2017 at 12:14 PM Dan Kirkwood wrote: > >> Thanks, Alex.. >> >> John -- would it be reasonable to fix this in the next release barring >> any other major issues? >> >> thanks.. Dan >> >> On Wed, Feb 15, 2017 at 9:34 AM, Alex Harui wrote: >> > >> > >> > On 2/15/17, 7:40 AM, "Dan Kirkwood" wrote: >> > >> >>Thanks, John.. I'm confused on this. According to >> >>http://www.apache.org/dev/licensing-howto.html#permissive-deps : >> >> >> >>`In LICENSE, add a pointer to the dependency's license within the >> >>distribution and a short note summarizing its licensing:` >> >> >> >>Is MIT a special case in this regard? And in that case, do we need a >> >>separate full license entry for each MIT-licensed component we use? >> >>Is this RC acceptable other than the license issues you pointed out? >> > >> > AIUI, a "pointer" is the text from that web page: >> > >> > This product bundles SuperWidget 1.2.3, which is available under a >> > MIT license. For details, see deps/superwidget/LICENSE.txt. >> > >> > Your build/packaging should copy the dependency's MIT License into a file >> > in the release package. MIT-licensed projects are supposed to have their >> > own copy of the MIT license in their release distributions with a >> > project-specific copyright. The pointer isn't supposed to be a >> > third-party URL since URLs are not stable, although I would have probably >> > advised you to fix that in the next release. IMO, it isn't a major flaw >> > for an incubating release. >> > >> > Instead of a "pointer" you can copy whole license files into LICENSE, but >> > many prefer "pointers" to keep the LICENSE file shorter. >> > >> > Of course, I could be wrong... >> > >> > -Alex >> > >> > >> > - >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [discuss] Apache Gobblin Incubator Proposal
Thanks for the proposal Jim. Regards JB On Feb 15, 2017, 11:37, at 11:37, Jim Jagielski wrote: >If you need/want another mentor, I volunteer > >> On Feb 14, 2017, at 3:53 PM, Olivier Lamy wrote: >> >> Hi >> Well I don't see issues as no one discuss the proposal. >> So I will start the official vote tomorrow. >> Cheers >> Olivier >> >> On 6 February 2017 at 14:08, Olivier Lamy wrote: >> >>> Hello everyone, >>> I would like to submit to you a proposal to bring Gooblin to the >Apache >>> Software Foundation. >>> The text of the proposal is included below and available as a draft >here >>> in the Wiki: https://wiki.apache.org/incubator/GobblinProposal >>> >>> We will appreciate any feedback and input. >>> >>> Olivier on behalf of the Gobblin community >>> >>> >>> = Apache Gobblin Proposal = >>> == Abstract == >>> Gobblin is a distributed data integration framework that simplifies >common >>> aspects of big data integration such as data ingestion, replication, >>> organization and lifecycle management for both streaming and batch >data >>> ecosystems. >>> >>> == Proposal == >>> >>> Gobblin is a universal data integration framework. The framework has >been >>> used to build a variety of big data applications such as ingestion, >>> replication, and data retention. The fundamental constructs provided >by the >>> Gobblin framework are: >>> >>> 1. An expandable set of connectors that allow data to be integrated >from >>> a variety of sources and sinks. The range of connectors already >available >>> in Gobblin are quite diverse and are an ever expanding set. To >highlight >>> just a few examples, connectors exist for databases (e.g., MySQL, >Oracle >>> Teradata, Couchbase etc.), web based technologies (REST APIs, >FTP/SFTP >>> servers, Filers), scalable storage (HDFS, S3, Ambry etc,), streaming >data >>> (Kafka, EventHubs etc.), and a variety of proprietary data sources >and >>> sinks (e.g.Salesforce, Google Analytics, Google Webmaster etc.). >Similarly, >>> Gobblin has a rich library of converters that allow for conversion >of data >>> from one format to another as data moves across system boundaries >(e.g. >>> AVRO in HDFS to JSON in another system). >>> >>> >>> 2. Gobblin has a well defined and customizable state management >layer >>> that allows writing stateful applications. These are particularly >useful >>> when solving problems like bulk incremental ingest and keeping >several >>> clusters replicated in sync. The ability to record work that has >been >>> completed and what remains in a scalable manner is critical to >writing such >>> diverse applications successfully. >>> >>> >>> 3. Gobblin is agnostic to the underlying execution engine. It can be >>> tailored to run ontop of a variety of execution frameworks ranging >from >>> multiple processes on a single node, to open source execution >engines like >>> MapReduce, Spark or Samza, natively on top of raw containers like >Yarn or >>> Mesos, and the public cloud like Amazon AWS or Microsoft Azure. We >are >>> extending Gobblin to run on top of a self managed cluster when >security is >>> vital. This allows different applications that require different >degrees >>> of scalability, latency or security to be customized to for their >specific >>> needs. For example, highly latency sensitive applications can be >executed >>> in a streaming environment while batch based execution might benefit >>> applications where the priority might be geared towards optimal >container >>> utilization. >>> >>> 4.Gobblin comes out of the box with several diagnosability features >like >>> Gobblin metrics and error handling. Collectively, these features >allow >>> Gobblin to operate at the scale of petabytes of data. To give just >one >>> example, the ability to quarantine a few bad records from an >isolated Kafka >>> topic without stopping the entire flow from continued execution is >vital >>> when the number of Kafka topics range in the thousands and the >collective >>> data handled is in the petabytes. >>> >>> Gobblin thus provides crisply defined software constructs that can >be used >>> to build a vast array of data integration applications customizable >for >>> varied user needs. It has become a preferred technology for data >>> integration use-cases by many organizations worldwide (see a partial >list >>> here). >>> >>> == Background == >>> >>> Over the last decade, data integration has evolved use case by use >case in >>> most companies. For example, at LinkedIn, when Kafka became a >significant >>> part of the data ecosystem, a system called Camus was built to >ingest this >>> data for analytics processing on Hadoop. Similarly, we had custom >pipelines >>> to ingest data from Salesforce, Oracle and myriad other sources. >This >>> pattern became the norm rather than the exception and one point, >LinkedIn >>> was running at least fifteen different types of ingestion pipelines. >This >>> fragmentation has several unfortunate implications. Operational >costs scale >>> with
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
I'd like to know the effort required from your POV to fix the license file. Alex's description matches my expectations, thanks for clarifying it. I would rather not create a release that didn't match the licensing requirements, but will be OK if you come back saying its a huge effort (however, I can't imagine copy and pasting license contents is difficult). On Wed, Feb 15, 2017 at 12:14 PM Dan Kirkwood wrote: > Thanks, Alex.. > > John -- would it be reasonable to fix this in the next release barring > any other major issues? > > thanks.. Dan > > On Wed, Feb 15, 2017 at 9:34 AM, Alex Harui wrote: > > > > > > On 2/15/17, 7:40 AM, "Dan Kirkwood" wrote: > > > >>Thanks, John.. I'm confused on this. According to > >>http://www.apache.org/dev/licensing-howto.html#permissive-deps : > >> > >>`In LICENSE, add a pointer to the dependency's license within the > >>distribution and a short note summarizing its licensing:` > >> > >>Is MIT a special case in this regard? And in that case, do we need a > >>separate full license entry for each MIT-licensed component we use? > >>Is this RC acceptable other than the license issues you pointed out? > > > > AIUI, a "pointer" is the text from that web page: > > > > This product bundles SuperWidget 1.2.3, which is available under a > > MIT license. For details, see deps/superwidget/LICENSE.txt. > > > > Your build/packaging should copy the dependency's MIT License into a file > > in the release package. MIT-licensed projects are supposed to have their > > own copy of the MIT license in their release distributions with a > > project-specific copyright. The pointer isn't supposed to be a > > third-party URL since URLs are not stable, although I would have probably > > advised you to fix that in the next release. IMO, it isn't a major flaw > > for an incubating release. > > > > Instead of a "pointer" you can copy whole license files into LICENSE, but > > many prefer "pointers" to keep the LICENSE file shorter. > > > > Of course, I could be wrong... > > > > -Alex > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org >
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
Thanks, Alex.. John -- would it be reasonable to fix this in the next release barring any other major issues? thanks.. Dan On Wed, Feb 15, 2017 at 9:34 AM, Alex Harui wrote: > > > On 2/15/17, 7:40 AM, "Dan Kirkwood" wrote: > >>Thanks, John.. I'm confused on this. According to >>http://www.apache.org/dev/licensing-howto.html#permissive-deps : >> >>`In LICENSE, add a pointer to the dependency's license within the >>distribution and a short note summarizing its licensing:` >> >>Is MIT a special case in this regard? And in that case, do we need a >>separate full license entry for each MIT-licensed component we use? >>Is this RC acceptable other than the license issues you pointed out? > > AIUI, a "pointer" is the text from that web page: > > This product bundles SuperWidget 1.2.3, which is available under a > MIT license. For details, see deps/superwidget/LICENSE.txt. > > Your build/packaging should copy the dependency's MIT License into a file > in the release package. MIT-licensed projects are supposed to have their > own copy of the MIT license in their release distributions with a > project-specific copyright. The pointer isn't supposed to be a > third-party URL since URLs are not stable, although I would have probably > advised you to fix that in the next release. IMO, it isn't a major flaw > for an incubating release. > > Instead of a "pointer" you can copy whole license files into LICENSE, but > many prefer "pointers" to keep the LICENSE file shorter. > > Of course, I could be wrong... > > -Alex > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On 2/15/17, 7:40 AM, "Dan Kirkwood" wrote: >Thanks, John.. I'm confused on this. According to >http://www.apache.org/dev/licensing-howto.html#permissive-deps : > >`In LICENSE, add a pointer to the dependency's license within the >distribution and a short note summarizing its licensing:` > >Is MIT a special case in this regard? And in that case, do we need a >separate full license entry for each MIT-licensed component we use? >Is this RC acceptable other than the license issues you pointed out? AIUI, a "pointer" is the text from that web page: This product bundles SuperWidget 1.2.3, which is available under a MIT license. For details, see deps/superwidget/LICENSE.txt. Your build/packaging should copy the dependency's MIT License into a file in the release package. MIT-licensed projects are supposed to have their own copy of the MIT license in their release distributions with a project-specific copyright. The pointer isn't supposed to be a third-party URL since URLs are not stable, although I would have probably advised you to fix that in the next release. IMO, it isn't a major flaw for an incubating release. Instead of a "pointer" you can copy whole license files into LICENSE, but many prefer "pointers" to keep the LICENSE file shorter. Of course, I could be wrong... -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
Thanks, John.. I'm confused on this. According to http://www.apache.org/dev/licensing-howto.html#permissive-deps : `In LICENSE, add a pointer to the dependency's license within the distribution and a short note summarizing its licensing:` Is MIT a special case in this regard? And in that case, do we need a separate full license entry for each MIT-licensed component we use? Is this RC acceptable other than the license issues you pointed out? Thanks.. Dan On Tue, Feb 14, 2017 at 7:10 PM, John D. Ament wrote: > -1 license file still needs a lot of work. > > MIT licenses need to be explicitly included in the license, not just > linked. In general, the license contents need to be in the LICENSE file, > not just links to the licenses. In some cases, its done like this (full > license headers copied) and in others there's a path link to the license. > > John > > On Thu, Feb 2, 2017 at 2:38 PM Dan Kirkwood wrote: > >> Hello Incubator PMC, >> >> The Apache Traffic Control community has voted on and approved a >> proposal to release Apache Traffic Control 1.8.0-incubating. We now >> kindly request that the Incubator PMC members review and vote on this >> incubator release. >> >> The VOTE RESULT is here: >> >> >> https://lists.apache.org/thread.html/4aa7f70b34ba9d2e4190301ae7ea118aa86b297c81e60467aedaf3dc@%3Cdev.trafficcontrol.apache.org%3E >> >> The draft release notes (along with links to artifacts, >> signatures/checksums, and updated documentation) can be found here: >> >> http://trafficcontrol.incubator.apache.org/downloads/ >> >> The git tag for the repository is "RELEASE-1.8.0-RC9": >> >> https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.0-RC9 >> >> The source distribution (also linked in the release notes) is here: >> >> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC9/ >> >> Build instructions are included in the BUILD.md file which is >> included in the source artifact. >> >> Artifacts have been signed with the "dang...@apache.org" key listed in: >> >> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS >> >> Please review and vote: >> >> [ ] +1 Approve the release >> [ ] -1 Don't approve the release (please provide specific comments) >> >> This vote will be open for at least 72 hours. >> >> Thanks, >> >> - Dan >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Mynewt 1.0.0-b2-incubating-rc1
+1 (binding) > On Feb 9, 2017, at 10:24 PM, will sanfilippo wrote: > > Hello, > > The Apache Mynewt Incubator PPMC has approved a proposal to release > Apache Mynewt 1.0.0-b2-incubating-rc1. We now kindly request that the > Incubator PMC members review and vote on this incubator release. > > Apache Mynewt is a community-driven, permissively licensed open source > initiative for constrained, embedded applications. Mynewt provides a > real-time operating system, flash file system, network stacks, and > support utilities for real-world embedded systems. > > For full release notes, please visit the Apache Mynewt Wiki: > https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes > > [VOTE] thread: > https://lists.apache.org/thread.html/250715a1a904632ee77d1ca1c24e657dd2eda42d782f3d27ee93e57e@%3Cdev.mynewt.apache.org%3E > > [RESULT][VOTE] thread: > https://lists.apache.org/thread.html/73ca1bec7bcfbf84643d9d9d474381d280f5069503aece2d00e74667@%3Cdev.mynewt.apache.org%3E > > [DISCUSS] thread: > https://lists.apache.org/thread.html/c5323ae5cd8d41dadc908a84b5ce994d64f1ac2df84b3ae27a1529ea@%3Cdev.mynewt.apache.org%3E > > This release candidate was tested as follows: > 1. Manual execution of the Mynewt Test plan: > > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan > > The test results can be found at: > https://cwiki.apache.org/confluence/display/MYNEWT/1.0.0-b2+Test+Results > > 2. The full unit test suite for this release was executed via “newt > test all” with no failures. This testing was performed on the > following platforms: > * OS X 10.10.5 > * Linux 4.4.6 (Gentoo) > > The release candidate to be voted on is available at: > https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b2-incubating/rc1/ > > The commits under consideration are as follows: > blinky: > repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky > commit a69b409197a845bc75748af564cb08c4ec7701d4 > core: > repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core > commit de35d2337189a69d97aa3fdccc4f7bfaeb31efc9 > newt: > repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt > commit fdac74ff83f21a11c7fbaa2e1adc2d50cbf1e612 > > In addition, the following newt convenience binaries are available: > linux: > https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b2-incubating/rc1/apache-mynewt-newt-bin-linux-1.0.0-b2-incubating.tgz > osx: > https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-1.0.0-b2-incubating/rc1/apache-mynewt-newt-bin-osx-1.0.0-b2-incubating.tgz > > The release candidate is signed with a GPG key available at: > https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS > > The vote is open for at least 72 hours. > > [ ] +1 Release this package > [ ] 0 I don't feel strongly about it, but don't object > [ ] -1 Do not release this package because... > > Thanks, > Will San Filippo > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [discuss] Apache Gobblin Incubator Proposal
If you need/want another mentor, I volunteer > On Feb 14, 2017, at 3:53 PM, Olivier Lamy wrote: > > Hi > Well I don't see issues as no one discuss the proposal. > So I will start the official vote tomorrow. > Cheers > Olivier > > On 6 February 2017 at 14:08, Olivier Lamy wrote: > >> Hello everyone, >> I would like to submit to you a proposal to bring Gooblin to the Apache >> Software Foundation. >> The text of the proposal is included below and available as a draft here >> in the Wiki: https://wiki.apache.org/incubator/GobblinProposal >> >> We will appreciate any feedback and input. >> >> Olivier on behalf of the Gobblin community >> >> >> = Apache Gobblin Proposal = >> == Abstract == >> Gobblin is a distributed data integration framework that simplifies common >> aspects of big data integration such as data ingestion, replication, >> organization and lifecycle management for both streaming and batch data >> ecosystems. >> >> == Proposal == >> >> Gobblin is a universal data integration framework. The framework has been >> used to build a variety of big data applications such as ingestion, >> replication, and data retention. The fundamental constructs provided by the >> Gobblin framework are: >> >> 1. An expandable set of connectors that allow data to be integrated from >> a variety of sources and sinks. The range of connectors already available >> in Gobblin are quite diverse and are an ever expanding set. To highlight >> just a few examples, connectors exist for databases (e.g., MySQL, Oracle >> Teradata, Couchbase etc.), web based technologies (REST APIs, FTP/SFTP >> servers, Filers), scalable storage (HDFS, S3, Ambry etc,), streaming data >> (Kafka, EventHubs etc.), and a variety of proprietary data sources and >> sinks (e.g.Salesforce, Google Analytics, Google Webmaster etc.). Similarly, >> Gobblin has a rich library of converters that allow for conversion of data >> from one format to another as data moves across system boundaries (e.g. >> AVRO in HDFS to JSON in another system). >> >> >> 2. Gobblin has a well defined and customizable state management layer >> that allows writing stateful applications. These are particularly useful >> when solving problems like bulk incremental ingest and keeping several >> clusters replicated in sync. The ability to record work that has been >> completed and what remains in a scalable manner is critical to writing such >> diverse applications successfully. >> >> >> 3. Gobblin is agnostic to the underlying execution engine. It can be >> tailored to run ontop of a variety of execution frameworks ranging from >> multiple processes on a single node, to open source execution engines like >> MapReduce, Spark or Samza, natively on top of raw containers like Yarn or >> Mesos, and the public cloud like Amazon AWS or Microsoft Azure. We are >> extending Gobblin to run on top of a self managed cluster when security is >> vital. This allows different applications that require different degrees >> of scalability, latency or security to be customized to for their specific >> needs. For example, highly latency sensitive applications can be executed >> in a streaming environment while batch based execution might benefit >> applications where the priority might be geared towards optimal container >> utilization. >> >> 4.Gobblin comes out of the box with several diagnosability features like >> Gobblin metrics and error handling. Collectively, these features allow >> Gobblin to operate at the scale of petabytes of data. To give just one >> example, the ability to quarantine a few bad records from an isolated Kafka >> topic without stopping the entire flow from continued execution is vital >> when the number of Kafka topics range in the thousands and the collective >> data handled is in the petabytes. >> >> Gobblin thus provides crisply defined software constructs that can be used >> to build a vast array of data integration applications customizable for >> varied user needs. It has become a preferred technology for data >> integration use-cases by many organizations worldwide (see a partial list >> here). >> >> == Background == >> >> Over the last decade, data integration has evolved use case by use case in >> most companies. For example, at LinkedIn, when Kafka became a significant >> part of the data ecosystem, a system called Camus was built to ingest this >> data for analytics processing on Hadoop. Similarly, we had custom pipelines >> to ingest data from Salesforce, Oracle and myriad other sources. This >> pattern became the norm rather than the exception and one point, LinkedIn >> was running at least fifteen different types of ingestion pipelines. This >> fragmentation has several unfortunate implications. Operational costs scale >> with the number of pipelines even if the myriad pipelines share a vasty >> array of common features. Bug fixes and performance optimizations cannot be >> shared across the pipelines. A common set of practices around debugging an
[VOTE] Releasing Apache Metron (incubating) 0.3.1-RC4
This is a call to vote on releasing Apache Metron 0.3.1-RC4 incubating Full list of changes in this release: https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. 1-RC4-incubating/CHANGES The tag/commit to be voted upon is apache-metron-0.3.1-rc4-incubating: https://git-wip-us.apache.org/repos/asf?p=incubator-metron. git;a=shortlog;h=refs/tags/apache-metron-0.3.1-rc4-incubating The source archive being voted upon can be found here: https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. 1-RC4-incubating/apache-metron-0.3.1-rc4-incubating.tar.gz Other release files, signatures and digests can be found here: https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. 1-RC4-incubating/ The release artifacts are signed with the following key: https://git-wip-us.apache.org/repos/asf?p=incubator-metron. git;a=blob;f=KEYS;h=8381e96d64c249a0c1b489bc0c234d9c260ba55e;hb=refs/tags/ apache-metron-0.3.1-rc4-incubating The book associated with this RC is located at https://dist.apache.org/repos/dist/dev/incubator/metron/0.3. 1-RC4-incubating/book-site/index.html Please vote on releasing this package as Apache Metron 0.3.1-RC4 incubating When voting, please list the actions taken to verify the release. Recommended build validation and verification instructions are posted here: https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds This vote will be open for at least 72 hours. [ ] +1 Release this package as Apache Metron 0.3.1-RC4 incubating [ ] 0 No opinion [ ] -1 Do not release this package because...
