>> 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] > >
