Hi,
Branch-3.6 is broken due to the fatjat stuff

[eolivelli@localhost zookeeper]$ mvn clean -Pfull-build,fatjar
[INFO] Scanning for projects...
[ERROR] [ERROR] Project
'org.apache.zookeeper:zookeeper-contrib-fatjar:3.6.1-SNAPSHOT' is
duplicated in the reactor @
[ERROR] Project
'org.apache.zookeeper:zookeeper-contrib-fatjar:3.6.1-SNAPSHOT' is
duplicated in the reactor -> [Help 1]
[ERROR]


I am preparing a fix

Enrico

Il giorno sab 18 apr 2020 alle ore 07:08 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

>
>
> Il Ven 17 Apr 2020, 08:50 Enrico Olivelli <eolive...@gmail.com> ha
> scritto:
>
>> Thank you Christopher !
>>
>> I have manually fixed the pom.xml files in branch-3.6 and release-3.6.1
>> branches.
>>
>> I would like to port ZOOKEEPER-3791 to branch-3.6 (that is now
>> 3.6.2-SNAPSHOT) and to 3.6.1 (that is now 3.6.1-SNAPSHOT)
>>
>
> I will try to perform the release without ZOOKEEPER-3791
>
> Enrico
>
>
>
>> We need another binding +1 on ZOOKEEPER-3791, Benjamin Reed already
>> started a review.
>>
>> I hope we can fix this stuff soon, this way we can release 3.6.1 to the
>> public
>>
>> Enrico
>>
>>
>> Il giorno gio 16 apr 2020 alle ore 23:08 Christopher <ctubb...@apache.org>
>> ha scritto:
>>
>>> On Thu, Apr 16, 2020 at 9:52 AM Enrico Olivelli <eolive...@gmail.com>
>>> wrote:
>>> >
>>> > Christopher,
>>> > answers inline.
>>> > Thank you for testing !
>>> >
>>> > Il giorno gio 16 apr 2020 alle ore 15:12 Christopher <
>>> ctubb...@apache.org>
>>> > ha scritto:
>>> >
>>> > > -0 (non-binding), I did find some problems that prevent some maven
>>> > > profiles, including fatjar, from being activated, among other minor
>>> > > issues; nothing too serious, but the inability to run the fatjar
>>> > > profile might be a blocker for some, as might be the missing patch
>>> for
>>> > > ipv6 comparisons in the C client.
>>> > >
>>> > > Good
>>> > > * I tested the convenience binary with Apache Accumulo 2.0.0 and
>>> basic
>>> > > functionality is all there
>>> > > * I checked the LICENSE.txt/NOTICE.txt files for expected content
>>> > > (copyright year was 2020, as expected)
>>> > > * Provided SHA512 signatures and GPG signatures match the tarballs
>>> > > (though the .sha512 files don't have terminating EOL chars)
>>> > >
>>> > >
>>> 3cc33e7630eb47e5807bc90610ae084c603960645ab36d4d6f775715ea75a7041835507029a2ca815ae16f4b8110bf9001a602ed78f0a7866c11dc15643b747c
>>> > >  apache-zookeeper-3.6.1-bin.tar.gz
>>> > >
>>> > >
>>> 21741f5ee09a8ad897da965c4e3570e4dd7d3a24bf990a8d77738144f4ca883ae6ccf86eb6f9a248c772ef2a22eaed438f4f3313166f89b8e28448d59a6ea7bd
>>> > >  apache-zookeeper-3.6.1.tar.gz
>>> > > * The contents of the source tarball match the contents of the tag
>>> > > (3ed3a9890472b251f9a6241317feef5f02cc0692)
>>> > > * Was able to build from source using `mvn clean verify -Pfull-build
>>> > > -DskipTests`
>>> > >
>>> > > Bad
>>> > > * The tag (and source tarball) is missing the commit for '754cf015f
>>> > > ZOOKEEPER-3726: invalid ipv6 address comparison in C client', which
>>> is
>>> > > present in the branch-3.6 branch
>>> >
>>> >   ** This might be resolvable by simply updating the JIRA to mark
>>> > > 3.6.2 as the fixVersion instead of 3.6.1, unless it's critical to
>>> > > include
>>> > >
>>> >
>>> > Done. If ZOOKEEPER-3726 is not a blocker then I feel we can live
>>> without it.
>>> > We can add it in case of the need of a new iteration.
>>>
>>> Agreed. Makes sense.
>>>
>>> >
>>> > > * Saw a few unit test failures on Fedora 31 x86_64 with Maven 3.6.3
>>> > > and java-13-openjdk-13.0.2.8-1.rolling.fc31.x86_64 (I ran `mvn clean
>>> > > package`)
>>> > >   ** org.apache.zookeeper.server.util.RequestPathMetricsCollectorTest
>>> > > failed with AssertionError
>>> > >   ** org.apache.zookeeper.server.quorum.QuorumDigestTest failed with
>>> > > AssertionError
>>> > >
>>> > Does it pass if you rerun it again ? This test is not failing for me
>>> (on
>>> > Linux + jdk8)
>>>
>>> They both pass on a second run, when I ran them in isolation. It might
>>> just be because surefire forkCount is 8, and my laptop is slow. Not
>>> sure. Would need further investigation. I'm not worried about this,
>>> though, and wouldn't consider it a blocker... but I might open up a
>>> JIRA if I see it again and can capture a stack trace or logs.
>>>
>>> >
>>> >
>>> > > * release did not appear to be prepared using the
>>> maven-release-plugin
>>> > > from the branch-3.6, but from a different (local?) branch; this
>>> > > resulted in a few minor issues
>>> > >
>>> >
>>> > yes, the tradition here is to create a work branch release-3.6.1 and
>>> then
>>> > it up to the Release Manager to handle the status of that branch
>>> > it is not strictly the Maven way, but we discussed that approach while
>>> > releasing 3.6.0, that was the first release with the
>>> maven-release-plugin
>>> >
>>> > this is our guide
>>> >
>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease+using+maven+release+plugin
>>> >
>>>
>>> I recommend using the <pushChanges>false</pushChanges> and
>>> <localCheckout>true</localCheckout> in maven-release-plugin (for
>>> release:prepare and release:perform) and using '3.6.1' instead as the
>>> release version. Improving the build and release process is something
>>> I have a lot of experience with, so I may look into this more later.
>>> Much of the details on this page can be replaced with an interactive
>>> helper script, as I've done for both Accumulo and Fluo already.
>>>
>>> >
>>> >
>>> > >   ** git commit hashes don't match up with the branch (commits appear
>>> > > cherry-picked and exclude ZOOKEEPER-3726, mentioned above)
>>> > >
>>> > This is not a big deal, it is important that we have the good tag
>>> > (release-3.6.1-0)
>>>
>>> Agreed. This is minor. It was just confusing. Missing commits in the
>>> release can be included in future releases. A bigger problem would be
>>> if the commits only existed in the tag and not in the maintenance
>>> branch, because that might mean a regression in the next release. The
>>> main concern I had here was that the JIRA issue was marked as fixed
>>> for this release, but it wasn't included.
>>>
>>> >
>>> >   ** the content of the pom.xml's <scm> <tag> includes `-0`, which
>>> > > will not be the final tag name if the artifacts are approved for
>>> > > release (actual tag should be "release-3.6.1")
>>> > >
>>> >
>>> > I agree, this is not nice. We can improve it.
>>> > Not a blocker for this release
>>> >
>>> >
>>> > > * fatjar profile is broken because fatjar module and zookeeper-it
>>> > > module specify wrong parent pom version (bad cherry-pick from
>>> > > master/3.7.0-SNAPSHOT?)
>>> > >
>>> >
>>> > This may be a problem that leads to the inability of building the
>>> source
>>> > release.
>>> > If you do not have ever built 3.7.0-SNAPSHOT locally you won't be able
>>> to
>>> > build from the released sources.
>>> > The source tarball we release is actually the main (an only) release
>>> > artifact and it should be buildable.
>>> >
>>> > I will double check, but I feel this can be a showstopper for this RC
>>> >
>>> > Christopher, do you want to send a fix patch for branch-3.6 ?
>>>
>>> I think the core of the problem is that not all modules are activated
>>> during `mvn release:prepare` when the POM versions are updated.
>>> However, you can't activate all modules at once because `fatjar` and
>>> `full-build` profiles are mutually exclusive.
>>> This is something I've already fixed in my PR for ZOOKEEPER-3791.
>>>
>>> I didn't anticipate backporting my PR for ZOOKEEPER-3791 to 3.6,
>>> but... the work was already done, and I'm pretty sure it fixes the
>>> issue here. So, I added an additional commit to that PR that updates
>>> the `<preparationGoals>` to activate all modules (and to use `verify`
>>> instead of `install`, since `install` is generally not advised... and
>>> can specifically cause problems with `release:prepare` creating
>>> different local artifacts than what are staged in `release:perform`).
>>> Backporting my PR to 3.6 should fix the problem, but you should test
>>> it.
>>>
>>> >
>>> > Enrico
>>> >
>>> >
>>> > >
>>> > > Did not check
>>> > > * did not run any unit tests from modules other than
>>> zookeeper-server,
>>> > > since the two test failures mentioned above terminated the build
>>> > > prematurely, and I didn't feel like running it again to skip those.
>>> :)
>>> > >
>>> >
>>> > You can re-run the build. Or if you want you can build the full
>>> repository
>>> > with -DskipTests and then build with the "-rf" option (Resume from) and
>>> > start the tests from the module after zookeeper-server.
>>> > Actually we still have some flaky tests that should be improved, but
>>> this
>>> > is not a blocker for a release.
>>> >
>>> > Enrico
>>> >
>>> >
>>> > >
>>> > >
>>> > > On Thu, Apr 16, 2020 at 6:34 AM Szalay-Bekő Máté
>>> > > <szalay.beko.m...@gmail.com> wrote:
>>> > > >
>>> > > > +1 (non-binding)
>>> > > >
>>> > > > - I built the source code on Ubuntu 18.4 using OpenJDK 8u242 and
>>> maven
>>> > > > 3.6.3.
>>> > > > - All the unit tests passed (both Java and C-client).
>>> > > > - Checkstyle passed
>>> > > > - I executed a rolling-upgrade test from 3.5.7 to 3.6.1. (using
>>> > > > https://github.com/symat/zk-rolling-upgrade-test)
>>> > > >
>>> > > > Kind regards,
>>> > > > Mate
>>> > > >
>>> > > > On Thu, Apr 16, 2020 at 5:45 AM Patrick Hunt <ph...@apache.org>
>>> wrote:
>>> > > >
>>> > > > > +1 - xsum/sig validated, rat ran clean, I was able to compile
>>> and ran
>>> > > some
>>> > > > > manual tests on varying cluster sizes.
>>> > > > >
>>> > > > > Patrick
>>> > > > >
>>> > > > > On Wed, Apr 15, 2020 at 11:44 AM Enrico Olivelli <
>>> eolive...@gmail.com>
>>> > > > > wrote:
>>> > > > >
>>> > > > > > This is a release candidate for 3.6.1.
>>> > > > > >
>>> > > > > > It is a bugfix release and it introduces a few bugfixes and new
>>> > > features
>>> > > > > in
>>> > > > > > these areas:
>>> > > > > > - compatibility with applications built against 3.5 client
>>> libraries
>>> > > > > > (restored a few non public APIs)
>>> > > > > > - update Netty to 4.1.48.Final
>>> > > > > > - ability to pass configuration as file in zkCli for TLS config
>>> > > > > > - Add setKeepAlive support for NIOServerCnxn
>>> > > > > > - Fix server side request throttling
>>> > > > > >
>>> > > > > > The full release notes is available at:
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > >
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12346764
>>> > > > > >
>>> > > > > > *** Please download, test and vote by April 19th 2020, 23:59
>>> UTC+0.
>>> > > ***
>>> > > > > >
>>> > > > > > Source files:
>>> > > > > >
>>> https://people.apache.org/~eolivelli/zookeeper-3.6.1-candidate-0/
>>> > > > > >
>>> > > > > > Maven staging repo:
>>> > > > > >
>>> > > > >
>>> > >
>>> https://repository.apache.org/content/repositories/orgapachezookeeper-1056
>>> > > > > >
>>> > > > > > The release candidate tag in git to be voted upon:
>>> release-3.6.1-0
>>> > > > > > https://github.com/apache/zookeeper/tree/release-3.6.0-1
>>> > > > > >
>>> > > > > > ZooKeeper's KEYS file containing PGP keys we use to sign the
>>> release:
>>> > > > > > https://www.apache.org/dist/zookeeper/KEYS
>>> > > > > >
>>> > > > > > The staging version of the website is:
>>> > > > > >
>>> > > > >
>>> > >
>>> https://people.apache.org/~eolivelli/zookeeper-3.6.1-candidate-0/website/
>>> > > > > >
>>> > > > > > Should we release this candidate?
>>> > > > > >
>>> > > > > > Enrico Olivelli
>>> > > > > >
>>> > > > >
>>> > >
>>>
>>

Reply via email to