Re: late learnings, which could be helpful for all mentors to know
Very useful. On Tue, Jun 4, 2019 at 9:22 PM Adrian Cole wrote: > Hi, all. > > Through Zipkin's incubation, I noticed that knowledge of state of the > art is not equally distributed. Some voting approaches already in use > aren't known. Also what you can use to automate isn't known. As > podlings don't always know the right questions to ask, it might be > beneficial for future podlings if some advice about state of the art > was taught instead. This is especially important as many projects will > likely want to import multiple repos. I will inventory some. > > * "parallel votes" is a technique to reduce the lag between dev@ and > general@ by starting the IPMC vote slightly after, but before > conclusion of the PPMC one. This may have only been tried once (in > Zipkin) and met resistance. > * "bundled votes" is a technique where multiple repos are sent in a > single vote. This is much more efficient for coupled repos than > pipelining. OpenWhisk uses this and don't appear to have met > resistance. > * not all repos need to actually release prior to graduation. Both > Dubbo and OpenWhisk had unreleased repos when they called for > graduation (OpenWhisk has dozens). It isn't intuitive for projects to > know they don't have to release every repo, so they should be told > this. > * Jenkins is most ASF, but Travis is ok, but CircleCI is not, and > maybe Appveyor is ok. All we know now, is that CircleCI is not ok, > which is personally fine, but basically people should be able to know > what CI tools are allowed to be used. > * You are allowed to automate release process, even with Travis. It > can be confusing to know what you are allowed to automate, and whether > it must be done with ASF infra etc. The most elaborate example is > https://github.com/apache/incubator-openwhisk-release > * ASF tools like RAT and the release plugin are barely maintained in > comparison with Incubator policy. It is unintuitive that tools > projects use to audit themselves don't evolve lock-step with general > software, policy and discussion. This feels bad whenever told, but > earlier is better. > > Anyway, figured I would send off these notes so that folks entering > the incubator don't end up with a lot of unnecessary grief, irritation > due to ignorance about state of the art, or the disparity between > project-specific ASF tools and general ASF tools. > > -A > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc2)
+1 (binding) Looks ok for me [x ] Download links are valid. [x ] Checksums and PGP signatures are valid. [x ] DISCLAIMER is included. [x ] Source code artifacts have correct names matching the current release. [x ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [x ] All files have license headers as specified by OpenWhisk project policy [1]. [x ] No compiled archives bundled in source archive. Best regards Krzysztof On 03.06.2019 19:42, David P Grove wrote: Dear IPMC members, The OpenWhisk podling has voted to release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc2) with 5 +1 votes and no other votes cast per the vote thread at [1]. There were no IPMC member votes cast on that thread. We now ask IPMC members to review this release candidate and vote accordingly. Note that this is an improved version of the proposed release we brought to you on May 23rd in [2]. thanks, --dave This is a call to vote on releasing version 0.10.0-incubating release candidate rc2 of the following project module with artifacts built from the Git repositories and commit IDs listed below. * OpenWhisk API Gateway: a737552c https://github.com/apache/incubator-openwhisk-apigateway/commits/a737552c https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.sha512 This release is comprised of source code distribution only. You can use this UNIX script to download the release and verify the checklist below: https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD Usage: curl -s "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD; -o rcverify.sh chmod +x rcverify.sh rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' 0.10.0-incubating rc2 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] DISCLAIMER is included. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [ ] All files have license headers as specified by OpenWhisk project policy [3]. [ ] No compiled archives bundled in source archive. This majority vote is open for at least 72 hours. [1] https://lists.apache.org/thread.html/3f4f02baa2708da4868c79ed6bcb0241570f730dc14af3d1b4c295cf@%3Cdev.openwhisk.apache.org%3E [2] https://lists.apache.org/thread.html/d43cf440e4d90770160e969fecf2957644c47d7c14c5192eacde9cf0@%3Cgeneral.incubator.apache.org%3E [3] https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md -- Krzysztof Sobkowiak JEE & OSS Architect, Integration Architect Apache Software Foundation Member (http://apache.org/) Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/) Apache Incubator PMC Member (https://incubator.apache.org/) Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
Re: late learnings, which could be helpful for all mentors to know
Thanks Adrian, this is all good to know. > On Jun 4, 2019, at 9:21 PM, Adrian Cole wrote: > > Hi, all. > > Through Zipkin's incubation, I noticed that knowledge of state of the > art is not equally distributed. Some voting approaches already in use > aren't known. Also what you can use to automate isn't known. As > podlings don't always know the right questions to ask, it might be > beneficial for future podlings if some advice about state of the art > was taught instead. This is especially important as many projects will > likely want to import multiple repos. I will inventory some. > > * "parallel votes" is a technique to reduce the lag between dev@ and > general@ by starting the IPMC vote slightly after, but before > conclusion of the PPMC one. This may have only been tried once (in > Zipkin) and met resistance. > * "bundled votes" is a technique where multiple repos are sent in a > single vote. This is much more efficient for coupled repos than > pipelining. OpenWhisk uses this and don't appear to have met > resistance. > * not all repos need to actually release prior to graduation. Both > Dubbo and OpenWhisk had unreleased repos when they called for > graduation (OpenWhisk has dozens). It isn't intuitive for projects to > know they don't have to release every repo, so they should be told > this. > * Jenkins is most ASF, but Travis is ok, but CircleCI is not, and > maybe Appveyor is ok. All we know now, is that CircleCI is not ok, > which is personally fine, but basically people should be able to know > what CI tools are allowed to be used. > * You are allowed to automate release process, even with Travis. It > can be confusing to know what you are allowed to automate, and whether > it must be done with ASF infra etc. The most elaborate example is > https://github.com/apache/incubator-openwhisk-release > * ASF tools like RAT and the release plugin are barely maintained in > comparison with Incubator policy. It is unintuitive that tools > projects use to audit themselves don't evolve lock-step with general > software, policy and discussion. This feels bad whenever told, but > earlier is better. > > Anyway, figured I would send off these notes so that folks entering > the incubator don't end up with a lot of unnecessary grief, irritation > due to ignorance about state of the art, or the disparity between > project-specific ASF tools and general ASF tools. > > -A > > - > 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
late learnings, which could be helpful for all mentors to know
Hi, all. Through Zipkin's incubation, I noticed that knowledge of state of the art is not equally distributed. Some voting approaches already in use aren't known. Also what you can use to automate isn't known. As podlings don't always know the right questions to ask, it might be beneficial for future podlings if some advice about state of the art was taught instead. This is especially important as many projects will likely want to import multiple repos. I will inventory some. * "parallel votes" is a technique to reduce the lag between dev@ and general@ by starting the IPMC vote slightly after, but before conclusion of the PPMC one. This may have only been tried once (in Zipkin) and met resistance. * "bundled votes" is a technique where multiple repos are sent in a single vote. This is much more efficient for coupled repos than pipelining. OpenWhisk uses this and don't appear to have met resistance. * not all repos need to actually release prior to graduation. Both Dubbo and OpenWhisk had unreleased repos when they called for graduation (OpenWhisk has dozens). It isn't intuitive for projects to know they don't have to release every repo, so they should be told this. * Jenkins is most ASF, but Travis is ok, but CircleCI is not, and maybe Appveyor is ok. All we know now, is that CircleCI is not ok, which is personally fine, but basically people should be able to know what CI tools are allowed to be used. * You are allowed to automate release process, even with Travis. It can be confusing to know what you are allowed to automate, and whether it must be done with ASF infra etc. The most elaborate example is https://github.com/apache/incubator-openwhisk-release * ASF tools like RAT and the release plugin are barely maintained in comparison with Incubator policy. It is unintuitive that tools projects use to audit themselves don't evolve lock-step with general software, policy and discussion. This feels bad whenever told, but earlier is better. Anyway, figured I would send off these notes so that folks entering the incubator don't end up with a lot of unnecessary grief, irritation due to ignorance about state of the art, or the disparity between project-specific ASF tools and general ASF tools. -A - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling releases and release policy
Hi, Thanks Sam for the advice. > Been lurking. Before I proceed, I will note that you have two members > of the board and one infrastructure representative participating. > Each has either explicitly or implicitly supported the idea of the > incubator setting direction for podlings. Set direction sure, but does that include ignoring board policy? While we do currently for minor issues, I’m reasonably sure the board is OK with that, well none have complained. I’m not sure if doing that for serious issues is overstepping the mark or not. See, for example, "why a foundation wide policy is needed”: [1] "Deviations from this policy may have an adverse effect on the legal shield's effectiveness, or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged without prior, explicit board approval” > Now my observation. My experience is that when a PMC comes to the > board with an open ended question asking for advice, the responses are > not crisp. Understood. I was asked by a board member to ask the question in the next report, although they may not of been wearing that hat at the time. > An approach I have found much more successful: come up with a > proposal. Often times it will get approved. Some times you will be > asked to make changes. OK I've written down what we currently do and that some have expressed an opinion that podling should be able to ignore distribution policy up until graduation in the current report. There is some support for it and no strong objection if that is OK by the board which is I think close to consensus. If I am mistaken there please speak up. Personally I don’t really care either way other than A) if I vote on or am a release manger for a release do I have the ASF legal protection (even if that release has serious issues) and B) it’s clearer when podlings need to fix issues. I’m happy to change what I’ve written in the report into a proposal with the view that, from now on that IPMC will allow serious issues in podling releases, so the board only needs to say yes/no either explicitly or implicitly rather than choose from a list of options a sit currently worded. If permission is given, then we’ll modify documentation and the DISCLAIMER to cover this and you’ll see fewer -1 votes. Podlings will be expected (as before) to fix all issues before graduation, so this may potentially block some podlings from graduation. If they say no then we'll refine the list of serious issues we vote -1 on and communicate that to podlings. I think we can reasonably agree on that list with perhaps one possible exception (compiled code in binaries). If anyone disagrees with this approach, or has an alternative suggestion, please speak up. Thanks, Justin 1. http://www.apache.org/legal/release-policy.html#why - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling releases and release policy
On Sat, Jun 1, 2019 at 7:50 PM Justin Mclean wrote: > > Hi, > > > Point me to where you are not allowed to make non-official podling releases > > that conform to Incubator policy. > > I find that hard to parse and perhaps you meant don’t conform to incubator > policy? But either way it’s not incubators policy, it’s the boards and infra > policy. Been lurking. Before I proceed, I will note that you have two members of the board and one infrastructure representative participating. Each has either explicitly or implicitly supported the idea of the incubator setting direction for podlings. Now my observation. My experience is that when a PMC comes to the board with an open ended question asking for advice, the responses are not crisp. This is by design. We are not a top down organization. No one Director is authorized to speak for the board. An approach I have found much more successful: come up with a proposal. Often times it will get approved. Some times you will be asked to make changes. And some times you will get yelled at. But one thing you will get is a crisp answer. - Sam Ruby P.S. Don't take this advice as recommending that you create a board resolution. In most cases, coming to consensus in a transparent way and informing the board in a sentence or a paragraph in the next board report that unless you hear otherwise, the Incubator will be implementing X is sufficient. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling releases and release policy
On Tue, Jun 4, 2019 at 7:12 PM Adrian Cole wrote: >... > https://github.com/apache/incubator-zipkin/issues/2544 That is pretty damned awesome.
Re: Podling releases and release policy
> > As others have mentioned, such release bugs would be labelled as blocking > > for graduation. Ideally the bug ticket numbers would be listed in a > > disclaimer file within the release. > > Interesting idea, that list would need to be kept up to date in there. It > might be easier to just tag the issues with a “blocking-graduation” tag? Of > course each PPMC could come up with their own may of doing thi as long as it > easy for reviewers to check. FWIW as we have 10 repos, but no central issue repository specific to ASF graduation tracking, Zipkin decided to make one issue with tick boxes. We've added this issue to the bottom of vote requests in attempts to reduce effort mutually around known and/or in progress things https://github.com/apache/incubator-zipkin/issues/2544 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling releases and release policy
Hi, > Perhaps one approach is to maintain a list of "release issues" which are > deemed "minor offences". As long as there are bugs raised against such > "release issues", then no further permission would be required. Anything > outside the "minor offences" would require explicit permission. +1 But also see what going in this months board report. [1] If the board happy with anything outside “minor offences” not requiring permission then I am as well it is after all their policy. > As others have mentioned, such release bugs would be labelled as blocking > for graduation. Ideally the bug ticket numbers would be listed in a > disclaimer file within the release. Interesting idea, that list would need to be kept up to date in there. It might be easier to just tag the issues with a “blocking-graduation” tag? Of course each PPMC could come up with their own may of doing thi as long as it easy for reviewers to check. Thanks, Justin 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: wiki
Hi, > I would like to have the write access to the cwiki for uploading the report > for singa. You should already have access just log in with your ASF username and password. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
FWD: [VOTE] Apache OpenWhisk graduation to Top Level Project
This email is to notify general@i.a.o that a graduation community [VOTE] is in progress for Apache OpenWhisk (incubating). -r -- Forwarded message - From: Rodric Rabbah Date: Tue, Jun 4, 2019 at 5:25 PM Subject: [VOTE] Apache OpenWhisk graduation to Top Level Project To: Hi all, After a discussion among the Apache OpenWhisk community on the dev mailing list [1], we have completed all Trademark transfers, and we are now in the process of pruning the PMC roster, completing the podling status page and completing the project maturity model [2]. Apache OpenWhisk entered the incubator on November 23 2016. Since then, we have grown to be in the top 25 list of Apache projects by GitHub Stars at 4041, have 229 unique contributors across all our project repos, more than 2500 commits, and most importantly, our community has grown and is diversified beyond the initial founding contributors and organization. The project has come a long way in embracing The Apache Way, in no small part to our dedicated mentors and the community spirit that has grown along this journey. We are operating well as an Apache project and so we should take the next step. As such, I am calling a vote for Apache OpenWhisk to graduate to a top level project. If we agree that we should graduate to a top level project, the next step will be to draft a Resolution [3] for the PPMC and IPMC to vote upon. Please take a minute to vote on whether or not Apache OpenWhisk should graduate to a Top Level Project by responding with one of the following: [ ] +1 Apache OpenWhisk should graduate. [ ] +0 No opinion [ ] -1 Apache OpenWhisk should not graduate (please provide the reason) The VOTE is open for a minimum of 72 hours. Per Apache guidelines [4] I will notify the incubator mailing list that a community vote is under way. Thank you. -r (on behalf of the Apache OpenWhisk PPMC) [1] https://lists.apache.org/thread.html/8daa3a05148f54ca82458777e2b2b5e25ba99d39dcf8ce7dd85d0188@%3Cdev.openwhisk.apache.org%3E [2] https://cwiki.apache.org/confluence/display/OPENWHISK/Project+Maturity+Model [3] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115526932 [4] https://incubator.apache.org/guides/graduation.html#community_graduation_vote
Re: wiki
Hi, I would like to have the write access to the cwiki for uploading the report for singa. My apache ID wangwei; My wiki account is wangwei.cs Thanks. Regards, Wei On Thu, May 30, 2019 at 7:24 PM Justin Mclean wrote: > Hi, > > > I would like access to the wiki, I will help maintain the Milgaro podling > > reports. My wiki username is kealanmccusker > > You should have access to the page [1]. You need to login with your ASF > user name and password. > > Thanks, > Justin > > 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019 > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[ANNOUNCE] Apache OpenWhisk (Incubating) runtimes version 1.1.3.0 Released
Hello Community, The Apache OpenWhisk (incubating) team is pleased to announce the source release of 13 language runtimes version 1.13.0. These language runtimes allow Apache OpenWhisk (incubating) to run serverless function in JavaScript, Python, Go, Ruby, Dotnet, Swift, PHP, Java, and Docker container. The official source release are available from https://openwhisk.apache.org/downloads.html. If you have any usage questions, or have problems when upgrading, please don't hesitate to let us know by sending feedback to d...@openwhisk.apache.org or opening a GitHub issue in the appropriate runtime project https://github.com/apache/?q=incubator-openwhisk-runtime. *Disclaimer* Apache OpenWhisk is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
Re: Podling releases and release policy
Perhaps one approach is to maintain a list of "release issues" which are deemed "minor offences". As long as there are bugs raised against such "release issues", then no further permission would be required. Anything outside the "minor offences" would require explicit permission. As others have mentioned, such release bugs would be labelled as blocking for graduation. Ideally the bug ticket numbers would be listed in a disclaimer file within the release. This would make it easier for reviewers and act as a reminder for project members and users. IANAL, but I think it would help too in terms of legal shield etc. to have such a file within the release not just a generic disclaimer "on some web site at one point in time". Cheers, Paul. On Tue, Jun 4, 2019 at 7:16 PM Justin Mclean wrote: > Hi, > > > Historically, demonstrably, we have applied a different policy to > "podling > > releases" that is a bit more lenient. Once the podling graduates, it must > > conform to the formal Apache release guidelines. > > 1. There is no seperate incubator release policy for podling/IPMC > releases, well no formal written down one anyway. > 2. The IPMC does currenly give podlings a lot of leeway and treats IPMC > releases differently to TLP releases. A look at recent IPMC release votes > will find +1 votes on issues that would probably be -1 on a TLP release. > > Perhaps read what going in the board report [1] (still draft) as I think > that captures it well. > > Thanks, > Justin > > 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019
Re: Podling releases and release policy
Hi, > Historically, demonstrably, we have applied a different policy to "podling > releases" that is a bit more lenient. Once the podling graduates, it must > conform to the formal Apache release guidelines. 1. There is no seperate incubator release policy for podling/IPMC releases, well no formal written down one anyway. 2. The IPMC does currenly give podlings a lot of leeway and treats IPMC releases differently to TLP releases. A look at recent IPMC release votes will find +1 votes on issues that would probably be -1 on a TLP release. Perhaps read what going in the board report [1] (still draft) as I think that captures it well. Thanks, Justin 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019
Re: Podling releases and release policy
Hi, >> That is demonstrably not true, as (historically) the Incubator has made >> releases with GPL'd code in them (eg. Hibernate). > > I don’t understand the choice of words :( That’s because while it was a software a release is was not an Apache releases. The word release has several different meaning here. I’ve also seen a number of podlings do this and it's not a big deal. It’s usually only allowed for a one (perhaps 2) non-Apache releases however, although I think a few podling made more than that, one made about 200 releases before it was pointed out that perhaps they needed to make an Apache one. And where we’re we, come people have ben saying podling releasee, they are actually IPMC releases and it’s the IPMC that can vote and make official Apache releases. Hopefully those 3 +1 votes come from the mentors, but often teh wider IPMC is needed. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling releases and release policy
On Tue, Jun 4, 2019 at 12:08 AM Hen wrote: > On Sun, Jun 2, 2019 at 11:53 Greg Stein wrote: > > On Sun, Jun 2, 2019 at 1:22 PM Hen wrote: > > >... > > > * Incubating releases are Apache releases. > > > > That is demonstrably not true, as (historically) the Incubator has made > > releases with GPL'd code in them (eg. Hibernate). > > I don’t understand the choice of words :( > > To me that is an Apache release which did not adhere, or had an exception, > to foundation policy. I assume it was offered from an Apache url. > > If it wasn’t from an Apache url, then it wasn’t an Incubating release. > Tarballs on our server, falling under different release guidelines. In my emails on this topic, I've been trying to distinguish between "podling releases" and "Apache releases". As Ralph said, why a disclaimer, if there isn't a difference in the nature of these tarballs/releases? Historically, demonstrably, we have applied a different policy to "podling releases" that is a bit more lenient. Once the podling graduates, it must conform to the formal Apache release guidelines. Cheers, -g
Re: Podling releases and release policy
On Tue, Jun 4, 2019 at 2:40 AM Greg Stein wrote: > > > > Yes, I'd like to change the disclaimer to state that releases cannot be > > considered completely reliable, should not be depended on for production, > > > I believe the above two phrases would be unfair to mature projects. In > fact, to 95% of all the projects that arrive in the Incubator. The projects > *are* reliable and *are* used in production. > > The only difference is they are learning how to become an Apache-style > community. The software doesn't magically "degrade". > The real issue is not the reliability of the software. It's the reliability of the licensing of the software. The ASF name stands for stronger guarantees about your rights to use the IP than most podlings can give when they join the incubator. Talking about reliability and production is not only probably untrue, it could also distract from the real risks. Best, Myrle IPMC Member
