Okay, if you sent an email discussing this than it is perfectly fine - basically the same as having a successful 0.7.0. Sorry for missing that and starting this whole thread. :)
My +1 still stands. On Mon, Jun 17, 2019 at 10:29 PM Antoine Toulme <[email protected]> wrote: > 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] > >
