Received loud and clear Larry. Sorry for the extra work of sizing up a new set of changes beyond conformance. I think I talked about moving to the latest master for a 0.8.0 release on this list, and didn’t hear back, so I took the plunge. That’s not to discard anything you’re saying though.
On Jun 17, 2019, at 21:07, larry mccay <[email protected]> wrote: >>> 2. It seems more is making its way into what probably should have been a >>> new RC of 0.7.0 than just fixes for issues identified during the previous >>> VOTE >> That’s fair. I can fix the 0.7 branch backporting the fixes and run a > 0.7.0 release. >> I moved to 0.8.0 since quite a few changes were introduced and the user > community- not on the users list unfortunately - expressed interest for. > > I would suggest that while ironing out the mechanics of getting an Apache > release out where multiple RCs are expected (and they should be for the > first few) that limiting the changes between RCs to only those things that > blocked the previous RC would be prudent. > > Adding any new code potentially invalidates previous testing and finding > cycles to start from scratch on a 4th or 5th RC can be challenging. > > I guess what you are doing here is explicitly calling out that we have to > start from scratch for a whole new scope that is to be considered 0.8.0. > Again, without an 0.7.0 release an 0.8.0 seems odd but of course there was > no 0.6.0 release from Apache either so.... > >> On Mon, Jun 17, 2019 at 4:51 PM Antoine Toulme <[email protected]> wrote: >> >> >> >>> On Jun 17, 2019, at 14:27, larry mccay <[email protected]> wrote: >>> >>> Just a couple things that may or may not be considered as part of the >> VOTE >>> here: >>> >>> 1. I may have missed it but I didn't see a successful 0.7.0 release - if >>> there wasn't one then why are we voting on 0.8.0? >> 0.7.0 was not successful in passing the IPMC vote. >>> 2. It seems more is making its way into what probably should have been a >>> new RC of 0.7.0 than just fixes for issues identified during the previous >>> VOTE >> That’s fair. I can fix the 0.7 branch backporting the fixes and run a >> 0.7.0 release. >> I moved to 0.8.0 since quite a few changes were introduced and the user >> community- not on the users list unfortunately - expressed interest for. >>> 3. To help mitigate #2 we should consider branching from master when it >>> seems to be in a releasable state then provide tags for each RC to that >>> release branch and only include fixes that are required to resolve issues >>> from the previous RC or some actual critical bug that was found and you >>> don't want to release with. Having the release scope creep between RCs >>> increases the required retesting for each RC. As it stands now, it seems >>> that in order to determine the changes between the last two RCs we need >> to >>> check and test everything between the 0.7.0 and 0.8.0 tags - which >> includes >>> things that were not required for the 0.7.0 release. I'm not sure that >> any >>> actual code changes were required in order to resolve 0.7.0. >> Yes, some changes were required. >>> 4. Having release branches also provides the ability to patch security >> bugs >>> on a given release and provide separate patch releases more easily. >> Certainly. We have a 0.7 and 0.8 branch. >>> >>> I did check NOTICE, LICENSE and signatures. >>> I built from source after downloading gradle and ran tests. >>> >>> While I do feel odd to approve a 0.8.0 release instead of 0.7.0, I don't >>> know whether I missed a 0.7.0 announcement or if there wasn't one whether >>> this is a reason to hold the release. >>> It seems to me that the mechanics of the release are in a shape to >> approve >>> with perhaps some improvements in order for process. >>> >>> Here is my +1. >>> >>> >>> >>>> On Sun, Jun 16, 2019 at 10:07 PM Antoine Toulme <[email protected]> >> wrote: >>>> >>>> >>>> >>>>> On Jun 16, 2019, at 5:21 PM, Michael Wall <[email protected]> wrote: >>>>> >>>>> Thanks Antoine, >>>>> >>>>> 1) gradle >>>>> I see now in the README it says to install gradle first. I thought the >>>>> whole point of the gradle wrapper to not have to install gradle. I >>>>> expected to see a gradlew checked in. The gradlew should download the >>>>> gradle-wrapper.jar if needed, based on the version configured in the >>>>> gradle/wrapper/gradle-wrapper.properties. In fact, when I run 'gradle >>>>> setup' and then ./gradlew it does just that. Can we check in gradlew >> and >>>>> gradlew.bat? Want a PR for that? >>>> I did as well. But no, the Apache guidelines say absolutely no binaries >> in >>>> source distribs. >>>> >>>> I received that feedback when 0.7.0 went up for voting on the incubator >>>> general list. >>>> >>>> I have therefore followed what Kafka did and removed the wrapper. >>>>> >>>>> 2) test jar file >>>>> How was that jar made? Can it be made as part of the build. Should >> not >>>>> hold up the release. >>>> Yeah, we can open an issue for this. The problem is that different >>>> versions of java create different jars, from what I’ve seen. >>>>> >>>>> 3) failing test >>>>> Seems like it is from running in parallel. Do different tests use the >>>> same >>>>> port? Can that be changed? Also should not hold up the release. >>>> They do run in parallel. Yes, we can make it better. I’ll open an issue. >>>>> >>>>> 4) ./gradlew rat >>>>> After running gradle setup, I still get this from the unzipped tgz >>>> file. I >>>>> can't explain that. I tried unzipping the zip and got an error, see >>>> below. >>>>> >>>>> 5 ) zip file seems wrong >>>>> Unzipping the zip, I got this >>>>> replace tuweni-src-0.8.0/hobbits-relayer/build.gradle? [y]es, [n]o, >>>> [A]ll, >>>>> [N]one, [r]ename: >>>>> >>>>> Looking at the zip there are 2 build.gradle files in the >> hobbits-relayer >>>>> directory. It is not the only file duplicated in the zip though. >>>>> >>>>> Actually, opening the tgz file, that file is duplicated too. Maybe >> gzip >>>>> silently overwrites. Any thoughts on that? >>>> >>>> The hobbits-relayer app was barely flushed when I got the go ahead from >>>> the incubator general list to run another release. >>>> Unfortunately, it’s likely that particular package is DOA. >>>> >>>> I won’t have time to look at that issue for a couple weeks. Maybe we can >>>> exclude the relayer from the release artifacts this time around, if >> that’s >>>> doable. >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Jun 16, 2019 at 3:31 PM Antoine Toulme <[email protected]> >>>> wrote: >>>>> >>>>>> See comments inline: >>>>>> >>>>>>> On Jun 16, 2019, at 16:12, Michael Wall <[email protected]> wrote: >>>>>>> >>>>>>> +0 >>>>>>> >>>>>>> I don't want to hold up the first release any longer, but I can't >> give >>>> it >>>>>>> a +1 at this time. >>>>>>> >>>>>>> Good >>>>>>> - Signatures good using >>>>>>> https://dist.apache.org/repos/dist/release/incubator/tuweni/KEYS >>>>>>> >>>>>>> Bad (I could give a +1 with just items 1 and 2) >>>>>>> 1) gradle wrapper needs fixing, jar is included but ./gradlew is not. >>>>>> Actually the jar should not be there either. I have to fix that. >>>>>>> Building with gradle 4.10.3 failed >>>>>> We require gradle 5 (see README). >>>>>>> 2) test jar file >>>>>>> include ./io/src/test/resources/resourceresolver-test.jar. Apologies >>>> if >>>>>>> this has been discussed. >>>>>> Yes, that’s used in tests. >>>>>>> 3) got this building with java 11 and java 8. Maybe it is my setup >>>> since >>>>>>> others have built the source >>>>>>> ``` >>>>>>>> Task :hobbits:test >>>>>>> >>>>>>> org.apache.tuweni.hobbits.WebSocketTest > testTwoWSConnections(Vertx) >>>>>> FAILED >>>>>>> java.net.BindException >>>>>>> Caused by: java.net.BindException >>>>>>> <=======------> 60% EXECUTING [35m 36s] >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>>> :hobbits:test > 13 tests completed, 1 failed >>>>>>>> :hobbits:test > Executing test >>>>>>> org.apache.tuweni.hobbits.HobbitsTransportTest >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>>> IDLE >>>>>>> ``` >>>>>> Maybe you have something on one of the ports used by those tests. Or >>>> tests >>>>>> ran in parallel in a way they deadlocked. >>>>>>> >>>>>>> 4) gradle rat works on the tag, but does not work extracted source >>>>>>> directory. I get this. >>>>>>> ``` >>>>>>> FAILURE: Build failed with an exception. >>>>>>> >>>>>>> * What went wrong: >>>>>>> Task 'rat' not found in root project 'tuweni'. >>>>>>> >>>>>>> * Try: >>>>>>> Run gradle tasks to get a list of available tasks. Run with >>>> --stacktrace >>>>>>> option to get the stack trace. Run with --info or --debug option to >> get >>>>>>> more log output. Run with --scan to get full insights. >>>>>>> >>>>>>> * Get more help at https://help.gradle.org >>>>>>> >>>>>>> BUILD FAILED in 1s >>>>>>> ``` >>>>>> Is this after running gradle setup and using the gradle wrapper? >>>>>>> >>>>>>> What is the plan for binary releases? I see bin, gossip and relayer >>>>>>> artifacts at >>>>>> https://dist.apache.org/repos/dist/dev/incubator/tuweni/0.8.0/ >>>>>> Make gossip and relayer available for download and have folks use them >>>> as >>>>>> applications. >>>>>> Binaries is a standard full distribution binary package. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>>> On Fri, Jun 14, 2019 at 2:36 AM Pierre Smits < >> [email protected]> >>>>>> wrote: >>>>>>>> >>>>>>>> checked signature and checksums >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Pierre Smits >>>>>>>> >>>>>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President* >>>>>>>> *Apache Directory <https://directory.apache.org>, PMC Member* >>>>>>>> Apache Incubator <https://incubator.apache.org>, committer >>>>>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without >>>>>> privileges) >>>>>>>> since 2008* >>>>>>>> Apache Steve <https://steve.apache.org>, committer >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 13, 2019 at 9:13 PM Antoine Toulme <[email protected] >>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 as well. >>>>>>>>> >>>>>>>>> Folks, please vote. Mentors and IPMC members in particular. >>>>>>>>> >>>>>>>>>> On Jun 12, 2019, at 4:31 PM, Dave Fisher <[email protected]> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> +1 (binding) IPMC vote. >>>>>>>>>> >>>>>>>>>> Signature and checksums are correct. >>>>>>>>>> DISCLAIMER is correct. >>>>>>>>>> LICENSE looks good. >>>>>>>>>> NOTICE looks good. >>>>>>>>>> Ratcheck is good - please make an issue to create a .ratcheck file >>>> for >>>>>>>>> the next release. >>>>>>>>>> I excluded ./eth-reference-tests since it has 30,000 json >> files. >>>>>>>>>> Build works. >>>>>>>>>> >>>>>>>>>> A suggestion for the next release is to write versions of the >> README >>>>>>>>> that are appropriate to each package. The current README.md is for >>>> the >>>>>>>>> GitHub repos. >>>>>>>>>> Also the gradle-wrapper.jar is still included, but that is a minor >>>>>>>> issue. >>>>>>>>>> >>>>>>>>>> Looks good! >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Dave >>>>>>>>>> >>>>>>>>>>> On Jun 12, 2019, at 3:21 PM, Antoine Toulme <[email protected] >>> >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> We're voting on the source distributions available here: >>>>>>>>>>> https://dist.apache.org/repos/dist/dev/incubator/tuweni/0.8.0/ >>>>>>>>>>> The release tag is present here: >>>>>>>>>>> https://github.com/apache/incubator-tuweni/releases/tag/v0.8.0 >>>>>>>>>>> >>>>>>>>>>> Please review and vote as appropriate. >>>>>>>>>>> >>>>>>>>>>> The vote is open for at least until Monday of next week. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Antoine >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
