Re: Podling releases and release policy
I agree. For example it would help heaps if there was a list of violations podling releases make, and which are immediate showstoppers and which need to be noted (filed as tickets) and fixed in a release before graduation. Certainly, having that list would help land this discussion a bit better. Justin, I think above all others you are the one sitting on a ton, the real wealth, of knowledge here. I appreciate the need to "know exactly what the rules are", but culturally I hope the emphasis remains on figuring out how the incubator can improve at helping podlings get to and through graduation without having to police them along the way. A lot of work has gone into improving the Incubator recently and it has been very much appreciated. I'm uncertain though as to whether seeking such explicit approval from the board and infra is but in the spirit of further policing podlings, or if in putting at ease some of the more serious concerns that the incubator has it allows it to better focus on what services it can better provide. I can't speak for all, but I know some folk really get the benefit from the public praise of catching podlings doing it right. The incubator's documentation isn't perfect, and it'll also be shifting sands and slightly out of date, so making it easy for newcomers in the incubator to know what are the good examples to be learning from always goes a long way. regards, Mick On Sat, 1 Jun 2019, at 13:55, Dave Fisher wrote: > Kevin and Justin, > > This is spot on. > > Disclaimer, signatures/checksums, Apache license, and a start to notes > are the minimum. > > Acceptance of issues to fix is also a requirement. > > Full compliance with Apache Release and Distribution Policies are some > of our agreed Incubation requirements for graduation recommendation. > > Do we need to confirm all requirements or should we limit to this > discussion to Releases? > > Regards, > Dave > > Sent from my iPhone > > > On May 31, 2019, at 8:45 PM, Kevin A. McGrail wrote: > > > > Hi Justin, > > > > Before putting it to the board, have we ever had a IPMC vote on the > > matter? I think the board wants to delegate because legally, there > > isn't a chance in hell they are going to vote on it any way but > > negatively because to me, they have no choice but to formally say no. > > This is a possible example of purposefully turning a blind eye because > > it's hard for podlings to come up to speed. > > > > So perhaps if we set an incubator policy of a podling release being a > > little more lenient, the board would delegate because the legal issues > > are about nil. It's like making a law where 20% of America is a > > criminal. Is it really enforceable and especially without prejudicial > > or preferential treatment? > > > > What I like to see from a podling is: acknowledgment of the issues, > > tickets on the issues, and consistent improvement. > > > > What we cannot see is: a podling NOT saying "incubating" in a release or > > saying no, we will not fix these issues. > > > > Perhaps we need a podling disclaimer for all podling releases that > > explains more about what is a podlings and what is an incubating > > release. Perhaps it can contain appropriate caveats that the release > > may have issues that are being worked on that up to and including > > licensing issues. Links to Jira as well would be good. Then if we > > enforce tickets about known issues, we can both hold podlings > > accountable and enlighten users about the risks. > > > > I agree there are some examples where podlings are pushing our good > > faith on not fixing issues. But there are others that are just > > overwhelmed and we need to help more with the podlings where English is > > a second language. Perhaps something to ask the new D&I committee to > > assist with. Lots of discussion about overcoming language barriers of > > late on board-chat too. > > > > Regards, > > KAM > >> On 5/31/2019 11:28 PM, Justin Mclean wrote: > >> Hi, > >> > >> It been suggested a few times by several people on several lists that > >> podling releases (particularly early one’s) don’t need to comply with > >> release and distribution policy even if they have serious issues. The > >> question has been asked to the board several times but we’ve never got a > >> clear answer (as the question is hypothetical) or the answer is no that’s > >> not allowed. The incubator does not set those policies, the board and > >> infra do. I’m going to ask the board to give us a clear answer on this to > >> see if they are OK to grant an exception to those policies for podling > >> releases and if our current DISCLAIMER covers those sort of issues. > >> > >> Anyone have anything to add or any objections to this before I ask them? > >> > >> The serious issues I’m talking about here include compiled source or > >> inclusion of GPL (or other Category X) code in a source release or a > >> Category X dependancy or include code tha
Re: [VOTE] Apache Tuweni (incubating) 0.7.0
Hi, > This class is not GPL. It was written by me. It is based on the ProgPoW > algorithm specification. That specification is licensed CC0, scroll to the > bottom of the README please: > https://github.com/ifdefelse/ProgPOW/blob/master/README.md Thanks for clarifying that, you might want to make that clear in the LICENSE file in that repo. 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
HI, > Before putting it to the board, have we ever had a IPMC vote on the matter? Sure if you think one is needed, but probably best to have some discussion about it first. > So perhaps if we set an incubator policy of a podling release being a > little more lenient We do not own the release policy so I don’t think we can change it like that, but we could ask the board to do so. We are already lenient on minor issues (missing headers, missing stuff in licenses and the like), this is more about the more serious issues, see for example the vote today on Tuweni. I don’t think we can ignore these without board permision to ignore their release policy. It may be that having that DISCLAIMER is good enough for them to be OK with that. For instance a podling a few months back went directly to board when we voted -1 on their release for including a jar in it and we’ve had some people express the opinion that everything is allowed in a release if it's fixed before the project graduates. Again I’m not sure we can do that without the board’s permission given it's their policy not ours. There has only been a couple of cases where this has come up given most podlings cancel the vote and make another release when a serious issue is found / someone IPMC member votes -1 on a release. > Perhaps we need a podling disclaimer for all podling releases that > explains more about what is a podlings and what is an incubating > release. That a good idea and having a list of know issues that are being worked on in the release sounds like it would help. Quite often the podling may not be aware of the issues until the IPMC finds them, possibly related to mentor engagement, or where there is a conflict of interest that might cloud mentors judgment. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Tuweni (incubating) 0.7.0
Hi Justin, This class is not GPL. It was written by me. It is based on the ProgPoW algorithm specification. That specification is licensed CC0, scroll to the bottom of the README please: https://github.com/ifdefelse/ProgPOW/blob/master/README.md I’ll address the other points separately. > On May 31, 2019, at 20:29, Justin Mclean wrote: > > Hi, > > -1 for missing DISCLAIMER, GPL source code in the release and a compiled code > in the release. > > I suggest you use a checklist like this one to help you. [1]. This page is > also very useful when making your license and notice filed [2]. > > If you need any help or want the IPMC to check think before you make a > release just ask. > > I checked: > - incubating in name > - DISCLAIMER is missing > - LICENSE is missing a number of things (see below) > - NOTICE contains license information that should be in LICENSE > - Source file have ASF headers > - There’s an unexpected binary file in the release [11] > - THE GPL licensed content in the release > - I didn’t try to compile the code > > LICENSE is missing license: > - for this this file [3] which may be this [4] > - this file [5] which also include has two headers. > - in the directory of [5] other files have ASF headers and I’m wondering if > they should, looking at [6] it mention this link [7] which is GPL licensed > [8]. GPL licensed code can’t be included in a source release, > - several files like this one [9] which are MIT licenses > > This file [10] (and I assume others in that directory) is also GPL licensed. > > Thanks, > Justin > > 1. > https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist > 2. http://www.apache.org/dev/licensing-howto.html > 3. > ./tuweni-src-0.7.0/progpow/src/main/java/org/apache/tuweni/progpow/Keccakf800.java > 4. https://github.com/bcgit/bc-java/blob/master/LICENSE.html > 5. > ./tuweni-src-0.7.0/scuttlebutt-rpc/src/test/java/org/apache/tuweni/scuttlebutt/rpc/mux/PatchworkIntegrationTest.java > 6../progpow/src/main/java/org/apache/tuweni/progpow/ProgPoW.java > 7. https://github.com/ifdefelse/ProgPOW > 8. https://github.com/ifdefelse/ProgPOW/blob/master/LICENSE > 9. ./toml/src/test/resources/org/apache/tuweni/toml/hard_example.toml > 10. ./eth-reference-tests/src/test/resources/tests/ansible/ec2.py > 11. ./gradle/wrapper/gradle-wrapper.jar > - > 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
Kevin and Justin, This is spot on. Disclaimer, signatures/checksums, Apache license, and a start to notes are the minimum. Acceptance of issues to fix is also a requirement. Full compliance with Apache Release and Distribution Policies are some of our agreed Incubation requirements for graduation recommendation. Do we need to confirm all requirements or should we limit to this discussion to Releases? Regards, Dave Sent from my iPhone > On May 31, 2019, at 8:45 PM, Kevin A. McGrail wrote: > > Hi Justin, > > Before putting it to the board, have we ever had a IPMC vote on the > matter? I think the board wants to delegate because legally, there > isn't a chance in hell they are going to vote on it any way but > negatively because to me, they have no choice but to formally say no. > This is a possible example of purposefully turning a blind eye because > it's hard for podlings to come up to speed. > > So perhaps if we set an incubator policy of a podling release being a > little more lenient, the board would delegate because the legal issues > are about nil. It's like making a law where 20% of America is a > criminal. Is it really enforceable and especially without prejudicial > or preferential treatment? > > What I like to see from a podling is: acknowledgment of the issues, > tickets on the issues, and consistent improvement. > > What we cannot see is: a podling NOT saying "incubating" in a release or > saying no, we will not fix these issues. > > Perhaps we need a podling disclaimer for all podling releases that > explains more about what is a podlings and what is an incubating > release. Perhaps it can contain appropriate caveats that the release > may have issues that are being worked on that up to and including > licensing issues. Links to Jira as well would be good. Then if we > enforce tickets about known issues, we can both hold podlings > accountable and enlighten users about the risks. > > I agree there are some examples where podlings are pushing our good > faith on not fixing issues. But there are others that are just > overwhelmed and we need to help more with the podlings where English is > a second language. Perhaps something to ask the new D&I committee to > assist with. Lots of discussion about overcoming language barriers of > late on board-chat too. > > Regards, > KAM >> On 5/31/2019 11:28 PM, Justin Mclean wrote: >> Hi, >> >> It been suggested a few times by several people on several lists that >> podling releases (particularly early one’s) don’t need to comply with >> release and distribution policy even if they have serious issues. The >> question has been asked to the board several times but we’ve never got a >> clear answer (as the question is hypothetical) or the answer is no that’s >> not allowed. The incubator does not set those policies, the board and infra >> do. I’m going to ask the board to give us a clear answer on this to see if >> they are OK to grant an exception to those policies for podling releases and >> if our current DISCLAIMER covers those sort of issues. >> >> Anyone have anything to add or any objections to this before I ask them? >> >> The serious issues I’m talking about here include compiled source or >> inclusion of GPL (or other Category X) code in a source release or a >> Category X dependancy or include code that the podling doesn’t have >> permission to distribute i.e. the ones that people constantly vote -1 for. >> Last time I calculated the stats for 300+ released I found 1 in 5 podling >> releases had a serious issue like this. >> >> If the board (and infra) does say this is OK, podlings would still have to >> have releases that copy with policy on graduation, so this puts more >> responsibility on the mentors and the projects themselves. Worse case the >> IPMC may have to reject graduation of a project that hasn’t got its releases >> in order. >> >> Thanks, >> Justin >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > -- > Kevin A. McGrail > Member, Apache Software Foundation > Chair Emeritus Apache SpamAssassin Project > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > - > 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: Podling releases and release policy
Hi Justin, Before putting it to the board, have we ever had a IPMC vote on the matter? I think the board wants to delegate because legally, there isn't a chance in hell they are going to vote on it any way but negatively because to me, they have no choice but to formally say no. This is a possible example of purposefully turning a blind eye because it's hard for podlings to come up to speed. So perhaps if we set an incubator policy of a podling release being a little more lenient, the board would delegate because the legal issues are about nil. It's like making a law where 20% of America is a criminal. Is it really enforceable and especially without prejudicial or preferential treatment? What I like to see from a podling is: acknowledgment of the issues, tickets on the issues, and consistent improvement. What we cannot see is: a podling NOT saying "incubating" in a release or saying no, we will not fix these issues. Perhaps we need a podling disclaimer for all podling releases that explains more about what is a podlings and what is an incubating release. Perhaps it can contain appropriate caveats that the release may have issues that are being worked on that up to and including licensing issues. Links to Jira as well would be good. Then if we enforce tickets about known issues, we can both hold podlings accountable and enlighten users about the risks. I agree there are some examples where podlings are pushing our good faith on not fixing issues. But there are others that are just overwhelmed and we need to help more with the podlings where English is a second language. Perhaps something to ask the new D&I committee to assist with. Lots of discussion about overcoming language barriers of late on board-chat too. Regards, KAM On 5/31/2019 11:28 PM, Justin Mclean wrote: > Hi, > > It been suggested a few times by several people on several lists that podling > releases (particularly early one’s) don’t need to comply with release and > distribution policy even if they have serious issues. The question has been > asked to the board several times but we’ve never got a clear answer (as the > question is hypothetical) or the answer is no that’s not allowed. The > incubator does not set those policies, the board and infra do. I’m going to > ask the board to give us a clear answer on this to see if they are OK to > grant an exception to those policies for podling releases and if our current > DISCLAIMER covers those sort of issues. > > Anyone have anything to add or any objections to this before I ask them? > > The serious issues I’m talking about here include compiled source or > inclusion of GPL (or other Category X) code in a source release or a Category > X dependancy or include code that the podling doesn’t have permission to > distribute i.e. the ones that people constantly vote -1 for. Last time I > calculated the stats for 300+ released I found 1 in 5 podling releases had a > serious issue like this. > > If the board (and infra) does say this is OK, podlings would still have to > have releases that copy with policy on graduation, so this puts more > responsibility on the mentors and the projects themselves. Worse case the > IPMC may have to reject graduation of a project that hasn’t got its releases > in order. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Tuweni (incubating) 0.7.0
Hi, -1 for missing DISCLAIMER, GPL source code in the release and a compiled code in the release. I suggest you use a checklist like this one to help you. [1]. This page is also very useful when making your license and notice filed [2]. If you need any help or want the IPMC to check think before you make a release just ask. I checked: - incubating in name - DISCLAIMER is missing - LICENSE is missing a number of things (see below) - NOTICE contains license information that should be in LICENSE - Source file have ASF headers - There’s an unexpected binary file in the release [11] - THE GPL licensed content in the release - I didn’t try to compile the code LICENSE is missing license: - for this this file [3] which may be this [4] - this file [5] which also include has two headers. - in the directory of [5] other files have ASF headers and I’m wondering if they should, looking at [6] it mention this link [7] which is GPL licensed [8]. GPL licensed code can’t be included in a source release, - several files like this one [9] which are MIT licenses This file [10] (and I assume others in that directory) is also GPL licensed. Thanks, Justin 1. https://cwiki.apache.org/confluence/display/INCUBATOR/Incubator+Release+Checklist 2. http://www.apache.org/dev/licensing-howto.html 3. ./tuweni-src-0.7.0/progpow/src/main/java/org/apache/tuweni/progpow/Keccakf800.java 4. https://github.com/bcgit/bc-java/blob/master/LICENSE.html 5. ./tuweni-src-0.7.0/scuttlebutt-rpc/src/test/java/org/apache/tuweni/scuttlebutt/rpc/mux/PatchworkIntegrationTest.java 6../progpow/src/main/java/org/apache/tuweni/progpow/ProgPoW.java 7. https://github.com/ifdefelse/ProgPOW 8. https://github.com/ifdefelse/ProgPOW/blob/master/LICENSE 9. ./toml/src/test/resources/org/apache/tuweni/toml/hard_example.toml 10. ./eth-reference-tests/src/test/resources/tests/ansible/ec2.py 11. ./gradle/wrapper/gradle-wrapper.jar - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Podling releases and release policy
Hi, It been suggested a few times by several people on several lists that podling releases (particularly early one’s) don’t need to comply with release and distribution policy even if they have serious issues. The question has been asked to the board several times but we’ve never got a clear answer (as the question is hypothetical) or the answer is no that’s not allowed. The incubator does not set those policies, the board and infra do. I’m going to ask the board to give us a clear answer on this to see if they are OK to grant an exception to those policies for podling releases and if our current DISCLAIMER covers those sort of issues. Anyone have anything to add or any objections to this before I ask them? The serious issues I’m talking about here include compiled source or inclusion of GPL (or other Category X) code in a source release or a Category X dependancy or include code that the podling doesn’t have permission to distribute i.e. the ones that people constantly vote -1 for. Last time I calculated the stats for 300+ released I found 1 in 5 podling releases had a serious issue like this. If the board (and infra) does say this is OK, podlings would still have to have releases that copy with policy on graduation, so this puts more responsibility on the mentors and the projects themselves. Worse case the IPMC may have to reject graduation of a project that hasn’t got its releases in order. 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 Zipkin Reporter (incubating) version 2.8.3
+1 (binding) Here are what I checked * Built the kit from source * Checked the release tag and release note * There is no binary in the source release kit * License and Notice are OK Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, May 28, 2019 at 12:56 AM Jorge Quilcate wrote: > > Hello All, > > This is a call for vote to release Apache Zipkin Reporter > (Incubating) version 2.8.3 > > The Apache Zipkin community has voted on and approved a proposal to > release Apache Zipkin Reporter (Incubating) version 2.8.3. > > We now kindly request the Incubator PMC members review and vote on > this incubator release. > > Apache Zipkin Reporter (Incubating) is the component that send spans > collected on the client-side to the Zipkin Server, via different kind of > transports. > > Zipkin community vote and result thread: > https://lists.apache.org/thread.html/33ad2ce409c5d08e4193d317200bf0bb95a4cf217eefec424826ace0@%3Cdev.zipkin.apache.org%3E > > The release candidates: > https://dist.apache.org/repos/dist/dev/incubator/zipkin/zipkin-reporter-java/2.8.3/ > > Git tag for the release: > https://github.com/apache/incubator-zipkin-reporter-java/tree/v2.8.3 > > Hash for the release tag: e6791fcd4081fb58cd9d5f7e3eac42fbbb034d51 > > Release Notes: > https://github.com/apache/incubator-zipkin-reporter-java/releases/tag/v2.8.3 > > The artifacts have been signed with Key : BB67A050, which can be found > in the keys file: > https://dist.apache.org/repos/dist/dev/incubator/zipkin/KEYS > > Verification Hints: > For your convenience, the below includes detailed how-to on verifying > a source release. Please note that this document is a work-in-progress > https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+Release > > 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 > > Thanks, > The Apache Zipkin (Incubating) Team > > - > 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] Apache Tuweni (incubating) 0.7.0
Apologies for the delay. -1 (binding) Policy violations: The missing DISCLAIMER in the source release is a blocker. Please move https://dist.apache.org/repos/dist/dev/tuweni to https://dist.apache.org/repos/dist/dev/incubator/tuweni for the next candidate. I checked the signatures and checksums. I checked LICENSE and NOTICE. There can be some improvements for the binary packages, but these are not blockers on a first release. The tgz and zip versions diffs match. README.md should be directed towards building and not to advertising nightly snapshots and referencing project build infrastructure. CI builds are not what projects produce. Releases are what projects produce. CI builds are for the project developer community and not the project user community. My ./gradlew build fails in the javadoc with tuweni-src-0.7.0/progpow/src/main/java/org/apache/tuweni/progpow/ProgPoW.java:29: error: unknown tag: implSpe * @implSpec https://github.com/ifdefelse/ProgPOW ^ RAT Check is pretty good once the eth-reference tests are excluded. The two archives in the source release make sense as exceptions. A rewritten README.md would explain the gradle wrapper. The file licenses/license-dependency.xml is very helpful. How is it generated? Since Tuweni includes Crypto code the podling will need to file export controls with the release [1] HTH, Dave [1] https://www.apache.org/dev/crypto.html > On May 31, 2019, at 10:24 AM, Kenneth Knowles wrote: > > I could not find the disclaimer from > http://incubator.apache.org/guides/branding.html#disclaimers anywhere in > the release. > > Kenn > > On Tue, May 28, 2019 at 11:47 AM Antoine Toulme wrote: > >> Hello IPMC, >> >> The Apache Tuweni community has voted on and approved a proposal to >> release Apache Tuweni (incubating) version 0.7.0. >> >> The voting thread can be found here: >> >> https://lists.apache.org/thread.html/65cc15293b9bc3598d0c3ca8ba4f7dbc402b6064372c14f0fae0d295@%3Cdev.tuweni.apache.org%3E >> >> Two binding +1 vote from mentors Jim Jagielski and Larry McCay carry over >> from the dev list thread. >> >> We now kindly request the Incubator PMC members review and vote on this >> incubator release. >> >> Tuweni is a set of libraries and other tools to aid development of >> blockchain and other decentralized software in Java and other JVM languages. >> >> It includes a low-level bytes library, serialization and deserialization >> codecs (e.g. RLP), various cryptography functions and primatives, and lots >> of other helpful utilities. >> The release candidates: >> https://dist.apache.org/repos/dist/dev/tuweni/0.7.0/ >> >> Git tag for the release: >> https://github.com/apache/incubator-tuweni/tree/v0.7.0 >> >> Hash for the release tag: a8d55b7cd9196895a1b44be58cc33ef9d999c10b >> >> The artifacts have been signed with Key: 5E469BCB, which can be found in >> the keys file: >> >> https://www.apache.org/dist/incubator/tuweni/KEYS >> >> The vote will be open for at least 72 hours or until the necessary number >> of votes are reached. >> >> Please vote accordingly: >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove with the reason >> >> Thanks, >> The Apache Tuweni (Incubating) Team >> >> >> >> - >> 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] Apache Tuweni (incubating) 0.7.0
The disclaimer is missing from the source distribution, indeed. Sorry for that oversight. > On May 31, 2019, at 10:24 AM, Kenneth Knowles wrote: > > I could not find the disclaimer from > http://incubator.apache.org/guides/branding.html#disclaimers anywhere in > the release. > > Kenn > > On Tue, May 28, 2019 at 11:47 AM Antoine Toulme wrote: > >> Hello IPMC, >> >> The Apache Tuweni community has voted on and approved a proposal to >> release Apache Tuweni (incubating) version 0.7.0. >> >> The voting thread can be found here: >> >> https://lists.apache.org/thread.html/65cc15293b9bc3598d0c3ca8ba4f7dbc402b6064372c14f0fae0d295@%3Cdev.tuweni.apache.org%3E >> >> Two binding +1 vote from mentors Jim Jagielski and Larry McCay carry over >> from the dev list thread. >> >> We now kindly request the Incubator PMC members review and vote on this >> incubator release. >> >> Tuweni is a set of libraries and other tools to aid development of >> blockchain and other decentralized software in Java and other JVM languages. >> >> It includes a low-level bytes library, serialization and deserialization >> codecs (e.g. RLP), various cryptography functions and primatives, and lots >> of other helpful utilities. >> The release candidates: >> https://dist.apache.org/repos/dist/dev/tuweni/0.7.0/ >> >> Git tag for the release: >> https://github.com/apache/incubator-tuweni/tree/v0.7.0 >> >> Hash for the release tag: a8d55b7cd9196895a1b44be58cc33ef9d999c10b >> >> The artifacts have been signed with Key: 5E469BCB, which can be found in >> the keys file: >> >> https://www.apache.org/dist/incubator/tuweni/KEYS >> >> The vote will be open for at least 72 hours or until the necessary number >> of votes are reached. >> >> Please vote accordingly: >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove with the reason >> >> Thanks, >> The Apache Tuweni (Incubating) Team >> >> >> >> - >> 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] Apache Tuweni (incubating) 0.7.0
I could not find the disclaimer from http://incubator.apache.org/guides/branding.html#disclaimers anywhere in the release. Kenn On Tue, May 28, 2019 at 11:47 AM Antoine Toulme wrote: > Hello IPMC, > > The Apache Tuweni community has voted on and approved a proposal to > release Apache Tuweni (incubating) version 0.7.0. > > The voting thread can be found here: > > https://lists.apache.org/thread.html/65cc15293b9bc3598d0c3ca8ba4f7dbc402b6064372c14f0fae0d295@%3Cdev.tuweni.apache.org%3E > > Two binding +1 vote from mentors Jim Jagielski and Larry McCay carry over > from the dev list thread. > > We now kindly request the Incubator PMC members review and vote on this > incubator release. > > Tuweni is a set of libraries and other tools to aid development of > blockchain and other decentralized software in Java and other JVM languages. > > It includes a low-level bytes library, serialization and deserialization > codecs (e.g. RLP), various cryptography functions and primatives, and lots > of other helpful utilities. > The release candidates: > https://dist.apache.org/repos/dist/dev/tuweni/0.7.0/ > > Git tag for the release: > https://github.com/apache/incubator-tuweni/tree/v0.7.0 > > Hash for the release tag: a8d55b7cd9196895a1b44be58cc33ef9d999c10b > > The artifacts have been signed with Key: 5E469BCB, which can be found in > the keys file: > > https://www.apache.org/dist/incubator/tuweni/KEYS > > The vote will be open for at least 72 hours or until the necessary number > of votes are reached. > > Please vote accordingly: > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove with the reason > > Thanks, > The Apache Tuweni (Incubating) Team > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
