Re: ZooKeeper 3.6.1...is it time ?

[Ted Dunning]

What internal class?

Where is it used?

Why are others using JDK 13 not seeing the problem that you described?



On Thu, Mar 19, 2020 at 8:58 PM Christopher  wrote:

> Apologies, but it's a bit hard for me to explain briefly. Here's an attempt
> to be as brief as I can:
>
> Newer JDKs add a `-release` option to cross-compile with strict
> compatibility enforced. When this flag is enabled, as my PR does
> automatically with the profiles (when it detects building with a newer JDK
> or in m2e Eclipse), the compiler identifies the use of a class that is not
> strictly compatible with Java 8. My PR removes this not strictly compatible
> class. The use of this class should be considered a bug because it will
> cause a failure in some JDKs (those without the com.sun class)... a bug
> that is caught by the strict compatibility checks of the `-release` flag in
> newer JDKs.
>
> The problem with the class is that it only is available on some versions of
> Java (those with com.sun internals). It is not only not strictly compatible
> with Java 8 ("not guaranteed to work"), it is specifically "guaranteed to
> not work" in future Java versions, because it is planned for explicit
> removal. It already causes problems in current versions if you have an
> application that uses modules and depends on ZooKeeper, because the
> unsupported class is hidden away in an internal module.
>
> What you say about ensuring that releases are built with JDK8 is actually
> not necessary any longer with the use of the `-release` flag. Newer JDKs
> enforce cross-compilation compatibility better. This release flag option
> eliminates the need to hold yourself back, doing release builds on an older
> end-of-life JDK to retain compatibility. Now, you can build with a newer
> JDK (taking advantage of newer Maven plugins, etc.), avoid complex uses of
> Maven toolchains, the annoying `-bootclasspath`, or the
> maven-enforcer-plugin's animal-sniffer rule. The cross-compilation strict
> compatibility is now enforced as a built in feature of newer JDKs.
>
> Sorry I couldn't explain more briefly... it's a very tiny change, but
> there's a lot of backstory to communicate why it matters.
>
> Incidentally, you can probably get rid of a few build jobs in Jenkins if
> you were to use the maven-enforcer-plugin to *only* support builds on newer
> JDKs (but still using the release flag to target Java 8, of course). This
> is what Apache Accumulo does for the stuff that we want to be compatible
> with Java 8: we require the build to use at least 11, but cross-compile to
> 8, because some of the Maven plugins we use for quality control checks are
> now starting to require Java 11.
>
>
> On Thu, Mar 19, 2020 at 3:32 PM Enrico Olivelli 
> wrote:
>
> > Il Gio 19 Mar 2020, 20:11 Christopher  ha scritto:
> >
> > > I would very much like my pull request in
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-3739 to be merged in
> > 3.6.1
> > > and newer, because it helps ensure newer java APIs don't leak into pull
> > > requests/patches when developing stuff to contribute using a newer JDK,
> > by
> > > leveraging the "release" flag of newer JDKs. However, in order to do
> so,
> > it
> > > needs to remove the use of an internal com.sun API which is not
> supported
> > > in newer JDKs. I would like it included, because it makes it easier for
> > me
> > > (and others using newer JDKs) to contribute.
> > >
> >
> > I usually use jdk13 for my applications and while I work on ZK code.
> > What problems are you facing?
> >
> > It is important to remember to build with jdk8 while making releases. But
> > for dev it is not needed.
> >
> > Maybe we can merge that patch on master but I don't feel it is so
> important
> > at the moment. (With jdk13)
> >
> > Enrico
> >
> >
> > > The patch is currently pending additional reviewers.
> > >
> > > On Thu, Mar 19, 2020 at 11:17 AM Patrick Hunt 
> wrote:
> > >
> > > > Great idea, thanks Enrico!
> > > >
> > > > Patrick
> > > >
> > > > On Thu, Mar 19, 2020 at 4:58 AM Enrico Olivelli  >
> > > > wrote:
> > > >
> > > > > Hi folks,
> > > > > after a couple of weeks after the release of 3.6.0 we are seeing a
> > few
> > > > > blocker issues related to the upgrade from 3.5.
> > > > >
> > > > > There is already a good list of issues already ported to 3.6 and a
> > few
> > > > > pending PRs that fix problems reported by users.
> > > > >
> > > > > You can find the list here, I have already did some clean up and
> left
> > > > > comments to "reporters" in order to remove a few issues that are
> > > > > tagged 3.6.1 but they don't have an active contributor working on
> it.
> > > > > I have also created 3.6.2 release in order to ease moving those
> > issues
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.6.1%20ORDER%20BY%20resolution%20DESC
> > > > >
> > > > > My proposal:
> > > > > - commit pending blocker patches related to the upgrade
> > > > 

Jenkins build is back to stable : PreCommit-ZOOKEEPER-github-pr-build-maven #1910

[Apache Jenkins Server]

See 

[jira] [Created] (ZOOKEEPER-3765) Use https only on the website

[Christopher Tubbs (Jira)]

Christopher Tubbs created ZOOKEEPER-3765:


 Summary: Use https only on the website
 Key: ZOOKEEPER-3765
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3765
 Project: ZooKeeper
  Issue Type: Improvement
  Components: documentation
Reporter: Christopher Tubbs
Assignee: Christopher Tubbs


The website should use https wherever possible.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: ZooKeeper 3.6.1...is it time ?

[Christopher]

Apologies, but it's a bit hard for me to explain briefly. Here's an attempt
to be as brief as I can:

Newer JDKs add a `-release` option to cross-compile with strict
compatibility enforced. When this flag is enabled, as my PR does
automatically with the profiles (when it detects building with a newer JDK
or in m2e Eclipse), the compiler identifies the use of a class that is not
strictly compatible with Java 8. My PR removes this not strictly compatible
class. The use of this class should be considered a bug because it will
cause a failure in some JDKs (those without the com.sun class)... a bug
that is caught by the strict compatibility checks of the `-release` flag in
newer JDKs.

The problem with the class is that it only is available on some versions of
Java (those with com.sun internals). It is not only not strictly compatible
with Java 8 ("not guaranteed to work"), it is specifically "guaranteed to
not work" in future Java versions, because it is planned for explicit
removal. It already causes problems in current versions if you have an
application that uses modules and depends on ZooKeeper, because the
unsupported class is hidden away in an internal module.

What you say about ensuring that releases are built with JDK8 is actually
not necessary any longer with the use of the `-release` flag. Newer JDKs
enforce cross-compilation compatibility better. This release flag option
eliminates the need to hold yourself back, doing release builds on an older
end-of-life JDK to retain compatibility. Now, you can build with a newer
JDK (taking advantage of newer Maven plugins, etc.), avoid complex uses of
Maven toolchains, the annoying `-bootclasspath`, or the
maven-enforcer-plugin's animal-sniffer rule. The cross-compilation strict
compatibility is now enforced as a built in feature of newer JDKs.

Sorry I couldn't explain more briefly... it's a very tiny change, but
there's a lot of backstory to communicate why it matters.

Incidentally, you can probably get rid of a few build jobs in Jenkins if
you were to use the maven-enforcer-plugin to *only* support builds on newer
JDKs (but still using the release flag to target Java 8, of course). This
is what Apache Accumulo does for the stuff that we want to be compatible
with Java 8: we require the build to use at least 11, but cross-compile to
8, because some of the Maven plugins we use for quality control checks are
now starting to require Java 11.


On Thu, Mar 19, 2020 at 3:32 PM Enrico Olivelli  wrote:

> Il Gio 19 Mar 2020, 20:11 Christopher  ha scritto:
>
> > I would very much like my pull request in
> > https://issues.apache.org/jira/browse/ZOOKEEPER-3739 to be merged in
> 3.6.1
> > and newer, because it helps ensure newer java APIs don't leak into pull
> > requests/patches when developing stuff to contribute using a newer JDK,
> by
> > leveraging the "release" flag of newer JDKs. However, in order to do so,
> it
> > needs to remove the use of an internal com.sun API which is not supported
> > in newer JDKs. I would like it included, because it makes it easier for
> me
> > (and others using newer JDKs) to contribute.
> >
>
> I usually use jdk13 for my applications and while I work on ZK code.
> What problems are you facing?
>
> It is important to remember to build with jdk8 while making releases. But
> for dev it is not needed.
>
> Maybe we can merge that patch on master but I don't feel it is so important
> at the moment. (With jdk13)
>
> Enrico
>
>
> > The patch is currently pending additional reviewers.
> >
> > On Thu, Mar 19, 2020 at 11:17 AM Patrick Hunt  wrote:
> >
> > > Great idea, thanks Enrico!
> > >
> > > Patrick
> > >
> > > On Thu, Mar 19, 2020 at 4:58 AM Enrico Olivelli 
> > > wrote:
> > >
> > > > Hi folks,
> > > > after a couple of weeks after the release of 3.6.0 we are seeing a
> few
> > > > blocker issues related to the upgrade from 3.5.
> > > >
> > > > There is already a good list of issues already ported to 3.6 and a
> few
> > > > pending PRs that fix problems reported by users.
> > > >
> > > > You can find the list here, I have already did some clean up and left
> > > > comments to "reporters" in order to remove a few issues that are
> > > > tagged 3.6.1 but they don't have an active contributor working on it.
> > > > I have also created 3.6.2 release in order to ease moving those
> issues
> > > >
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.6.1%20ORDER%20BY%20resolution%20DESC
> > > >
> > > > My proposal:
> > > > - commit pending blocker patches related to the upgrade
> > > > - start a release within a couple of weeks, in the beginning of April
> > > >
> > > > I volunteer to do the release, this way I can finish the "new release
> > > > procedure" based on the Maven Release Plugin
> > > >
> > > > Enrico
> > > >
> > >
> >
>

Re: Website code location?

[Christopher]

Ah, okay. Thanks. I recommend putting a README in the svn area to point
people to the current source locations.

On Thu, Mar 19, 2020 at 6:45 PM Tamas Penzes 
wrote:

> Hi Christopher,
>
> The website is in the ZK GitHub repo in the branch
> https://github.com/apache/zookeeper/tree/website
>
> Regards, Tamaas
>
> On Thu, Mar 19, 2020 at 7:44 PM Christopher  wrote:
>
> > Hi,
> >
> > I noticed that ZooKeeper's site is still accessible via http://
> > Given the move by many browsers to start prioritizing, and in some cases,
> > warning, about insecure pages, I think it is best to redirect
> > http://zookeeper.apache.org to https://zookeeper.apache.org
> >
> > I can submit a patch to do this, as I did for Apache Accumulo and Apache
> > Fluo, but I couldn't find the current source code for ZooKeeper's
> website.
> > The SVN directory seems too old (last updated 2 years ago), and I
> couldn't
> > find a GIT repo containing ZK's website.
> >
> > Once I find the website source, I was thinking about proposing some other
> > improvements, too, such as:
> >
> > 1. automated builds from markdown using Jekyll and INFRA's new .asf.yaml
> > publishing mechanism,
> > 2. making a more prominent download button on the main page, and
> > 3. making download links on the releases page dynamically resolve to a
> > nearest mirror (with a drop-down to select a mirror manually), to reduce
> > the number of clicks to download.
> >
> > Thanks,
> > Christopher
> >
>

Build failed in Jenkins: zookeeper-master-maven #715

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 661.47 KB...]
Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

ZooKeeper_branch34_jdk8 - Build # 2106 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_jdk8/2106/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 72.32 KB...]
[junit] Running org.apache.zookeeper.test.RestoreCommittedLogTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
30.137 sec
[junit] Running org.apache.zookeeper.test.SaslAuthDesignatedClientTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.979 sec
[junit] Running org.apache.zookeeper.test.SaslAuthDesignatedServerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.845 sec
[junit] Running org.apache.zookeeper.test.SaslAuthFailDesignatedClientTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.623 sec
[junit] Running org.apache.zookeeper.test.SaslAuthFailNotifyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.792 sec
[junit] Running org.apache.zookeeper.test.SaslAuthFailTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.881 sec
[junit] Running org.apache.zookeeper.test.SaslAuthMissingClientConfigTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.01 sec
[junit] Running org.apache.zookeeper.test.SaslClientTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.112 sec
[junit] Running org.apache.zookeeper.test.SessionInvalidationTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.85 sec
[junit] Running org.apache.zookeeper.test.SessionTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
11.192 sec
[junit] Running org.apache.zookeeper.test.SessionTimeoutTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.336 sec
[junit] Running org.apache.zookeeper.test.StandaloneTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.927 sec
[junit] Running org.apache.zookeeper.test.StatTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.174 sec
[junit] Running org.apache.zookeeper.test.StaticHostProviderTest
[junit] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
2.368 sec
[junit] Running org.apache.zookeeper.test.SyncCallTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.788 sec
[junit] Running org.apache.zookeeper.test.TruncateTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
9.848 sec
[junit] Running org.apache.zookeeper.test.UpgradeTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.152 sec
[junit] Running org.apache.zookeeper.test.WatchedEventTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.133 sec
[junit] Running org.apache.zookeeper.test.WatcherFuncTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1.78 sec
[junit] Running org.apache.zookeeper.test.WatcherTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
29.089 sec
[junit] Running org.apache.zookeeper.test.ZkDatabaseCorruptionTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
10.879 sec
[junit] Running org.apache.zookeeper.test.ZooKeeperQuotaTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.867 sec
[junit] Running org.apache.jute.BinaryInputArchiveTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.123 sec

fail.build.on.test.failure:

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/build.xml:1425: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/build.xml:1428: 
Tests failed!

Total time: 50 minutes 1 second
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



###
## FAILED TESTS (if any) 
##
3 tests failed.
FAILED:  
org.apache.zookeeper.server.quorum.auth.QuorumKerberosAuthTest.testValidCredentials

Error Message:
waiting for server 0 being up

Stack Trace:
junit.framework.AssertionFailedError: waiting for server 0 being up
at 
org.apache.zookeeper.server.quorum.auth.QuorumAuthTestBase.startQuorum(QuorumAuthTestBase.java:75)
at 
org.apache.zookeeper.server.quorum.auth.QuorumKerberosAuthTest.testValidCredentials(QuorumKerberosAuthTest.java:114)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:55)

Re: Website code location?

[Tamas Penzes]

Hi Christopher,

The website is in the ZK GitHub repo in the branch
https://github.com/apache/zookeeper/tree/website

Regards, Tamaas

On Thu, Mar 19, 2020 at 7:44 PM Christopher  wrote:

> Hi,
>
> I noticed that ZooKeeper's site is still accessible via http://
> Given the move by many browsers to start prioritizing, and in some cases,
> warning, about insecure pages, I think it is best to redirect
> http://zookeeper.apache.org to https://zookeeper.apache.org
>
> I can submit a patch to do this, as I did for Apache Accumulo and Apache
> Fluo, but I couldn't find the current source code for ZooKeeper's website.
> The SVN directory seems too old (last updated 2 years ago), and I couldn't
> find a GIT repo containing ZK's website.
>
> Once I find the website source, I was thinking about proposing some other
> improvements, too, such as:
>
> 1. automated builds from markdown using Jekyll and INFRA's new .asf.yaml
> publishing mechanism,
> 2. making a more prominent download button on the main page, and
> 3. making download links on the releases page dynamically resolve to a
> nearest mirror (with a drop-down to select a mirror manually), to reduce
> the number of clicks to download.
>
> Thanks,
> Christopher
>

[jira] [Created] (ZOOKEEPER-3764) Add High Availability Guarantee Into Docs

[David Mollitor (Jira)]

David Mollitor created ZOOKEEPER-3764:
-

 Summary: Add High Availability Guarantee Into Docs
 Key: ZOOKEEPER-3764
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3764
 Project: ZooKeeper
  Issue Type: Improvement
  Components: documentation
Reporter: David Mollitor


{quote}
For a topic with replication factor N, we will tolerate up to N-1 server 
failures without losing any records committed to the log.
* https://kafka.apache.org/documentation/
{quote}

Please add a similar statement to the ZK docs, to include the formula for 
calculating the maximum number of server failures.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Jenkins build is back to normal : zookeeper-master-maven-jdk13 #116

[Apache Jenkins Server]

See 

Re: ZooKeeper 3.6.1...is it time ?

[Enrico Olivelli]

Il Gio 19 Mar 2020, 20:11 Christopher  ha scritto:

> I would very much like my pull request in
> https://issues.apache.org/jira/browse/ZOOKEEPER-3739 to be merged in 3.6.1
> and newer, because it helps ensure newer java APIs don't leak into pull
> requests/patches when developing stuff to contribute using a newer JDK, by
> leveraging the "release" flag of newer JDKs. However, in order to do so, it
> needs to remove the use of an internal com.sun API which is not supported
> in newer JDKs. I would like it included, because it makes it easier for me
> (and others using newer JDKs) to contribute.
>

I usually use jdk13 for my applications and while I work on ZK code.
What problems are you facing?

It is important to remember to build with jdk8 while making releases. But
for dev it is not needed.

Maybe we can merge that patch on master but I don't feel it is so important
at the moment. (With jdk13)

Enrico


> The patch is currently pending additional reviewers.
>
> On Thu, Mar 19, 2020 at 11:17 AM Patrick Hunt  wrote:
>
> > Great idea, thanks Enrico!
> >
> > Patrick
> >
> > On Thu, Mar 19, 2020 at 4:58 AM Enrico Olivelli 
> > wrote:
> >
> > > Hi folks,
> > > after a couple of weeks after the release of 3.6.0 we are seeing a few
> > > blocker issues related to the upgrade from 3.5.
> > >
> > > There is already a good list of issues already ported to 3.6 and a few
> > > pending PRs that fix problems reported by users.
> > >
> > > You can find the list here, I have already did some clean up and left
> > > comments to "reporters" in order to remove a few issues that are
> > > tagged 3.6.1 but they don't have an active contributor working on it.
> > > I have also created 3.6.2 release in order to ease moving those issues
> > >
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.6.1%20ORDER%20BY%20resolution%20DESC
> > >
> > > My proposal:
> > > - commit pending blocker patches related to the upgrade
> > > - start a release within a couple of weeks, in the beginning of April
> > >
> > > I volunteer to do the release, this way I can finish the "new release
> > > procedure" based on the Maven Release Plugin
> > >
> > > Enrico
> > >
> >
>

Re: ZooKeeper 3.6.1...is it time ?

[Christopher]

I would very much like my pull request in
https://issues.apache.org/jira/browse/ZOOKEEPER-3739 to be merged in 3.6.1
and newer, because it helps ensure newer java APIs don't leak into pull
requests/patches when developing stuff to contribute using a newer JDK, by
leveraging the "release" flag of newer JDKs. However, in order to do so, it
needs to remove the use of an internal com.sun API which is not supported
in newer JDKs. I would like it included, because it makes it easier for me
(and others using newer JDKs) to contribute.

The patch is currently pending additional reviewers.

On Thu, Mar 19, 2020 at 11:17 AM Patrick Hunt  wrote:

> Great idea, thanks Enrico!
>
> Patrick
>
> On Thu, Mar 19, 2020 at 4:58 AM Enrico Olivelli 
> wrote:
>
> > Hi folks,
> > after a couple of weeks after the release of 3.6.0 we are seeing a few
> > blocker issues related to the upgrade from 3.5.
> >
> > There is already a good list of issues already ported to 3.6 and a few
> > pending PRs that fix problems reported by users.
> >
> > You can find the list here, I have already did some clean up and left
> > comments to "reporters" in order to remove a few issues that are
> > tagged 3.6.1 but they don't have an active contributor working on it.
> > I have also created 3.6.2 release in order to ease moving those issues
> >
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.6.1%20ORDER%20BY%20resolution%20DESC
> >
> > My proposal:
> > - commit pending blocker patches related to the upgrade
> > - start a release within a couple of weeks, in the beginning of April
> >
> > I volunteer to do the release, this way I can finish the "new release
> > procedure" based on the Maven Release Plugin
> >
> > Enrico
> >
>

Re: [PROPOSAL] Send build notifications to notifications list

[Christopher]

That view only shows 23 of ZK's total jobs. I think that view should also
be deleted in favor of the one at
https://builds.apache.org/view/Z/view/ZooKeeper/
Part of the impetus for creating individual tabs, one for each letter, is
for stability, because when we group letters into groups, people feel the
need to adjust them when one group gets bigger than others. This happened
twice, and broke links. Having the top-level views of a single letter, and
subviews under that creates stable, predictable links to job views.

On Thu, Mar 19, 2020 at 2:38 PM Patrick Hunt  wrote:

> afaik this is the view (at least the one I use):
> https://builds.apache.org/view/S-Z/view/ZooKeeper/
> it's curated to maintain the current/active jobs for the current/active
> branches and smattering of jdks for coverage.
>
> Patrick
>
> On Thu, Mar 19, 2020 at 11:30 AM Christopher  wrote:
>
> > It sounds like there's at least the beginnings of consensus here.
> >
> > So, I took a look at how ZK's jobs are configured in builds.apache.org,
> in
> > order to prepare to help make the change, and saw some stuff that was
> > slightly upsetting (), or at least daunting for whoever makes the
> change:
> >
> > 1. There are 45 Jenkins jobs for ZK. That seems insane to me. Is there
> any
> > old ones that can be removed? I'm not sure which the community finds
> > valuable and which are excess, but all the disabled ones should probably
> be
> > deleted, because they are definitely not in use. It would be best if a
> > committer could identify and delete the ones that aren't needed. That
> will
> > save some time in editing the configs to change the target email.
> >
> > 2. I also noticed there's a top-level view at
> > https://builds.apache.org/view/ZK%20All/ ; several years ago, I tried to
> > get people to do a better job of keeping Jenkins views organized, so I
> > created a new tab for each letter of the Latin alphabet to encourage
> > projects to create subviews under that. ZooKeeper didn't have one, and
> had
> > the top-level view instead. So, I went ahead and created a new view at
> > https://builds.apache.org/view/Z/view/ZooKeeper/ ; I think the top-level
> > view at https://builds.apache.org/view/ZK%20All/should be deleted.
> >
> > Once the extras repos are deleted, I'd be happy to be the one to
> tediously
> > update each job to point to the notifications list, but a moderator might
> > need to approve the Jenkins sender. 
> >
> >
> > On Thu, Mar 19, 2020 at 11:18 AM Szalay-Bekő Máté <
> > szalay.beko.m...@gmail.com> wrote:
> >
> > > I also like it! It will make it easier for new community members to
> joint
> > > to discussions.
> > >
> > > although it also means I will have to setup new filters now for
> > > the notifications@ list ;)
> > >
> > > On Thu, Mar 19, 2020 at 1:52 PM RABI K.C.  wrote:
> > >
> > > > Hi Christopher,
> > > >
> > > > I am +1 on this.
> > > >
> > > > Regards,
> > > > Rabi Kumar K C
> > > >
> > > > On Wed, Mar 18, 2020 at 10:25 PM Christopher 
> > > wrote:
> > > >
> > > > > Hi ZK Devs,
> > > > >
> > > > > I have been trying to watch the ZooKeeper developer list lately, to
> > > > > stay on top of latest issues, and to contribute in whatever small
> way
> > > > > I can. However, I noticed the list gets a lot of spam from
> automated
> > > > > notifications (especially Jenkins).
> > > > >
> > > > > This has the effect of drowning out conversation between actual
> > > > > humans, and can discourage participation, because it requires new
> > > > > subscribers to set up a bunch of filters to suppress these, if they
> > > > > don't want to see them (and they may unintentionally suppress human
> > > > > conversation, if they don't set up their filters perfectly).
> > > > >
> > > > > What do the ZK committers/PMC members think about having Jenkins
> send
> > > > > build notifications to the notifications@ list instead of dev@?
> > > > >
> > > > > Thanks,
> > > > > Christopher
> > > > >
> > > >
> > >
> >
>

Website code location?

[Christopher]

Hi,

I noticed that ZooKeeper's site is still accessible via http://
Given the move by many browsers to start prioritizing, and in some cases,
warning, about insecure pages, I think it is best to redirect
http://zookeeper.apache.org to https://zookeeper.apache.org

I can submit a patch to do this, as I did for Apache Accumulo and Apache
Fluo, but I couldn't find the current source code for ZooKeeper's website.
The SVN directory seems too old (last updated 2 years ago), and I couldn't
find a GIT repo containing ZK's website.

Once I find the website source, I was thinking about proposing some other
improvements, too, such as:

1. automated builds from markdown using Jekyll and INFRA's new .asf.yaml
publishing mechanism,
2. making a more prominent download button on the main page, and
3. making download links on the releases page dynamically resolve to a
nearest mirror (with a drop-down to select a mirror manually), to reduce
the number of clicks to download.

Thanks,
Christopher

Re: [PROPOSAL] Send build notifications to notifications list

[Patrick Hunt]

afaik this is the view (at least the one I use):
https://builds.apache.org/view/S-Z/view/ZooKeeper/
it's curated to maintain the current/active jobs for the current/active
branches and smattering of jdks for coverage.

Patrick

On Thu, Mar 19, 2020 at 11:30 AM Christopher  wrote:

> It sounds like there's at least the beginnings of consensus here.
>
> So, I took a look at how ZK's jobs are configured in builds.apache.org, in
> order to prepare to help make the change, and saw some stuff that was
> slightly upsetting (), or at least daunting for whoever makes the change:
>
> 1. There are 45 Jenkins jobs for ZK. That seems insane to me. Is there any
> old ones that can be removed? I'm not sure which the community finds
> valuable and which are excess, but all the disabled ones should probably be
> deleted, because they are definitely not in use. It would be best if a
> committer could identify and delete the ones that aren't needed. That will
> save some time in editing the configs to change the target email.
>
> 2. I also noticed there's a top-level view at
> https://builds.apache.org/view/ZK%20All/ ; several years ago, I tried to
> get people to do a better job of keeping Jenkins views organized, so I
> created a new tab for each letter of the Latin alphabet to encourage
> projects to create subviews under that. ZooKeeper didn't have one, and had
> the top-level view instead. So, I went ahead and created a new view at
> https://builds.apache.org/view/Z/view/ZooKeeper/ ; I think the top-level
> view at https://builds.apache.org/view/ZK%20All/should be deleted.
>
> Once the extras repos are deleted, I'd be happy to be the one to tediously
> update each job to point to the notifications list, but a moderator might
> need to approve the Jenkins sender. 
>
>
> On Thu, Mar 19, 2020 at 11:18 AM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com> wrote:
>
> > I also like it! It will make it easier for new community members to joint
> > to discussions.
> >
> > although it also means I will have to setup new filters now for
> > the notifications@ list ;)
> >
> > On Thu, Mar 19, 2020 at 1:52 PM RABI K.C.  wrote:
> >
> > > Hi Christopher,
> > >
> > > I am +1 on this.
> > >
> > > Regards,
> > > Rabi Kumar K C
> > >
> > > On Wed, Mar 18, 2020 at 10:25 PM Christopher 
> > wrote:
> > >
> > > > Hi ZK Devs,
> > > >
> > > > I have been trying to watch the ZooKeeper developer list lately, to
> > > > stay on top of latest issues, and to contribute in whatever small way
> > > > I can. However, I noticed the list gets a lot of spam from automated
> > > > notifications (especially Jenkins).
> > > >
> > > > This has the effect of drowning out conversation between actual
> > > > humans, and can discourage participation, because it requires new
> > > > subscribers to set up a bunch of filters to suppress these, if they
> > > > don't want to see them (and they may unintentionally suppress human
> > > > conversation, if they don't set up their filters perfectly).
> > > >
> > > > What do the ZK committers/PMC members think about having Jenkins send
> > > > build notifications to the notifications@ list instead of dev@?
> > > >
> > > > Thanks,
> > > > Christopher
> > > >
> > >
> >
>

Re: [PROPOSAL] Send build notifications to notifications list

[Christopher]

It sounds like there's at least the beginnings of consensus here.

So, I took a look at how ZK's jobs are configured in builds.apache.org, in
order to prepare to help make the change, and saw some stuff that was
slightly upsetting (), or at least daunting for whoever makes the change:

1. There are 45 Jenkins jobs for ZK. That seems insane to me. Is there any
old ones that can be removed? I'm not sure which the community finds
valuable and which are excess, but all the disabled ones should probably be
deleted, because they are definitely not in use. It would be best if a
committer could identify and delete the ones that aren't needed. That will
save some time in editing the configs to change the target email.

2. I also noticed there's a top-level view at
https://builds.apache.org/view/ZK%20All/ ; several years ago, I tried to
get people to do a better job of keeping Jenkins views organized, so I
created a new tab for each letter of the Latin alphabet to encourage
projects to create subviews under that. ZooKeeper didn't have one, and had
the top-level view instead. So, I went ahead and created a new view at
https://builds.apache.org/view/Z/view/ZooKeeper/ ; I think the top-level
view at https://builds.apache.org/view/ZK%20All/should be deleted.

Once the extras repos are deleted, I'd be happy to be the one to tediously
update each job to point to the notifications list, but a moderator might
need to approve the Jenkins sender. 


On Thu, Mar 19, 2020 at 11:18 AM Szalay-Bekő Máté <
szalay.beko.m...@gmail.com> wrote:

> I also like it! It will make it easier for new community members to joint
> to discussions.
>
> although it also means I will have to setup new filters now for
> the notifications@ list ;)
>
> On Thu, Mar 19, 2020 at 1:52 PM RABI K.C.  wrote:
>
> > Hi Christopher,
> >
> > I am +1 on this.
> >
> > Regards,
> > Rabi Kumar K C
> >
> > On Wed, Mar 18, 2020 at 10:25 PM Christopher 
> wrote:
> >
> > > Hi ZK Devs,
> > >
> > > I have been trying to watch the ZooKeeper developer list lately, to
> > > stay on top of latest issues, and to contribute in whatever small way
> > > I can. However, I noticed the list gets a lot of spam from automated
> > > notifications (especially Jenkins).
> > >
> > > This has the effect of drowning out conversation between actual
> > > humans, and can discourage participation, because it requires new
> > > subscribers to set up a bunch of filters to suppress these, if they
> > > don't want to see them (and they may unintentionally suppress human
> > > conversation, if they don't set up their filters perfectly).
> > >
> > > What do the ZK committers/PMC members think about having Jenkins send
> > > build notifications to the notifications@ list instead of dev@?
> > >
> > > Thanks,
> > > Christopher
> > >
> >
>

Jenkins build became unstable: zookeeper-master-maven #714

[Apache Jenkins Server]

See 

Jenkins build became unstable: zookeeper-master-maven-jdk11 #422

[Apache Jenkins Server]

See 

Build failed in Jenkins: zookeeper-master-maven-jdk13 #115

[Apache Jenkins Server]

See 


Changes:

[nkalmar] ZOOKEEPER-3758: Leader reachability check fails with single address


--
[...truncated 530.68 KB...]
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by 
defaultTestReconfigServer::testReconfigFailureWithoutServerSuperuserPasswordConfiguredStarting
 zookeeper ... STARTED
 [exec] Using config: 

 [exec] 
 [exec] Starting zookeeper ... STARTEDZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] 
 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by defaultStarting zookeeper ... STARTED
 [exec] Using config: 

 [exec] 
 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

Build failed in Jenkins: zookeeper-master-maven-jdk12 #421

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 539.17 KB...]
 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Starting zookeeper ... STARTED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

 [exec] Stopping zookeeper ... STOPPED
 [exec] ZooKeeper JMX enabled by default
 [exec] Using config: 

Jenkins build is back to stable : zookeeper-branch36-java8 #97

[Apache Jenkins Server]

See 

Jenkins build became unstable: zookeeper-master-maven-jdk14 #4

[Apache Jenkins Server]

See 

Jenkins build is unstable: zookeeper-master-maven-jdk12 #420

[Apache Jenkins Server]

See 

Re: [PROPOSAL] Send build notifications to notifications list

[Szalay-Bekő Máté]

I also like it! It will make it easier for new community members to joint
to discussions.

although it also means I will have to setup new filters now for
the notifications@ list ;)

On Thu, Mar 19, 2020 at 1:52 PM RABI K.C.  wrote:

> Hi Christopher,
>
> I am +1 on this.
>
> Regards,
> Rabi Kumar K C
>
> On Wed, Mar 18, 2020 at 10:25 PM Christopher  wrote:
>
> > Hi ZK Devs,
> >
> > I have been trying to watch the ZooKeeper developer list lately, to
> > stay on top of latest issues, and to contribute in whatever small way
> > I can. However, I noticed the list gets a lot of spam from automated
> > notifications (especially Jenkins).
> >
> > This has the effect of drowning out conversation between actual
> > humans, and can discourage participation, because it requires new
> > subscribers to set up a bunch of filters to suppress these, if they
> > don't want to see them (and they may unintentionally suppress human
> > conversation, if they don't set up their filters perfectly).
> >
> > What do the ZK committers/PMC members think about having Jenkins send
> > build notifications to the notifications@ list instead of dev@?
> >
> > Thanks,
> > Christopher
> >
>

Re: ZooKeeper 3.6.1...is it time ?

[Patrick Hunt]

Great idea, thanks Enrico!

Patrick

On Thu, Mar 19, 2020 at 4:58 AM Enrico Olivelli  wrote:

> Hi folks,
> after a couple of weeks after the release of 3.6.0 we are seeing a few
> blocker issues related to the upgrade from 3.5.
>
> There is already a good list of issues already ported to 3.6 and a few
> pending PRs that fix problems reported by users.
>
> You can find the list here, I have already did some clean up and left
> comments to "reporters" in order to remove a few issues that are
> tagged 3.6.1 but they don't have an active contributor working on it.
> I have also created 3.6.2 release in order to ease moving those issues
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.6.1%20ORDER%20BY%20resolution%20DESC
>
> My proposal:
> - commit pending blocker patches related to the upgrade
> - start a release within a couple of weeks, in the beginning of April
>
> I volunteer to do the release, this way I can finish the "new release
> procedure" based on the Maven Release Plugin
>
> Enrico
>

Jenkins build became unstable: PreCommit-ZOOKEEPER-github-pr-build-maven #1909

[Apache Jenkins Server]

See 

Jenkins build is unstable: zookeeper-branch36-java8 #96

[Apache Jenkins Server]

See 

Re: [PROPOSAL] Send build notifications to notifications list

[RABI K.C.]

Hi Christopher,

I am +1 on this.

Regards,
Rabi Kumar K C

On Wed, Mar 18, 2020 at 10:25 PM Christopher  wrote:

> Hi ZK Devs,
>
> I have been trying to watch the ZooKeeper developer list lately, to
> stay on top of latest issues, and to contribute in whatever small way
> I can. However, I noticed the list gets a lot of spam from automated
> notifications (especially Jenkins).
>
> This has the effect of drowning out conversation between actual
> humans, and can discourage participation, because it requires new
> subscribers to set up a bunch of filters to suppress these, if they
> don't want to see them (and they may unintentionally suppress human
> conversation, if they don't set up their filters perfectly).
>
> What do the ZK committers/PMC members think about having Jenkins send
> build notifications to the notifications@ list instead of dev@?
>
> Thanks,
> Christopher
>

Re: [PROPOSAL] Send build notifications to notifications list

[Enrico Olivelli]

Christopher,

Il giorno mer 18 mar 2020 alle ore 22:25 Christopher
 ha scritto:
>
> Hi ZK Devs,
>
> I have been trying to watch the ZooKeeper developer list lately, to
> stay on top of latest issues, and to contribute in whatever small way
> I can. However, I noticed the list gets a lot of spam from automated
> notifications (especially Jenkins).
>
> This has the effect of drowning out conversation between actual
> humans, and can discourage participation, because it requires new
> subscribers to set up a bunch of filters to suppress these, if they
> don't want to see them (and they may unintentionally suppress human
> conversation, if they don't set up their filters perfectly).
>
> What do the ZK committers/PMC members think about having Jenkins send
> build notifications to the notifications@ list instead of dev@?

I think it is a very good idea

Enrico

>
> Thanks,
> Christopher

ZooKeeper 3.6.1...is it time ?

[Enrico Olivelli]

Hi folks,
after a couple of weeks after the release of 3.6.0 we are seeing a few
blocker issues related to the upgrade from 3.5.

There is already a good list of issues already ported to 3.6 and a few
pending PRs that fix problems reported by users.

You can find the list here, I have already did some clean up and left
comments to "reporters" in order to remove a few issues that are
tagged 3.6.1 but they don't have an active contributor working on it.
I have also created 3.6.2 release in order to ease moving those issues

https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20AND%20fixVersion%20%3D%203.6.1%20ORDER%20BY%20resolution%20DESC

My proposal:
- commit pending blocker patches related to the upgrade
- start a release within a couple of weeks, in the beginning of April

I volunteer to do the release, this way I can finish the "new release
procedure" based on the Maven Release Plugin

Enrico

Jenkins build is back to stable : zookeeper-master-maven-jdk14 #3

[Apache Jenkins Server]

See