Re: Travis notifications for trunk?
> Is everybody OK with sending e-mail notifications for CI failures for > trunk to this list? +1 -- Eric Covener cove...@gmail.com
Re: Travis notifications for trunk?
Le 23/04/2020 à 12:20, Joe Orton a écrit : In the past two weeks we've had three true negative build failures from Travis on trunk - i.e. bugs were introduced and CI caught them - and one false negative (where the gcc 9 build broke because of some change in the Ubuntu repo). So I think we're reaching the point where signal is dominating noise. Is everybody OK with sending e-mail notifications for CI failures for trunk to this list? It's quite likely we will still see occassional false negatives, and can continue to mark as "allowed failure" any build combination which looks unstable, so it doesn't fail the job overall. As with 2.4.x we will only see fail->pass and pass->fail transitions via e-mail notification. Regards, Joe +1. This is just great. Thanks. CJ
mod_systemd suggestion
Hi all, triggered by the new mod_systemd I drafted a patch to enhance the monitoring data it provides during the monitor hook run. Currently it publishes important data, like idle and busy slots and total request count, but also not so useful info like requests/second and bytes/second as a long term average (since start). These two figues tend to become near constant after a longer time of operation. Since the monitor hook of the module always seems to run in the same (parent) process, it is easy to remember the previous request and byte count data and average only over the last monitor hook interval. This should give more meaningful data. And is a change local to mod_systemd. In addition we have a third metric available in the scoreboard, namely the total request duration. From that we can get the average request duration and the average request concurrency. This part also needs a change to the sload structure. Maybe we need a minor MMN bump for that. I scetched a patch under home.apache.org/~rjung/patches/httpd-trunk-mod_systemd-interval-stats.patch Any comments, likes or dislikes? Thanks and regards, Rainer
Errored: apache/httpd#649 (2.4.x - c92568b)
Build Update for apache/httpd - Build: #649 Status: Errored Duration: 13 mins and 22 secs Commit: c92568b (2.4.x) Author: Joe Orton Message: Merge r1876869 from trunk: systemd dependencies are only needed by mod_systemd. They should currently not be needed by httpd directly or any other binary. So no need to add them to HTTPD_LIBS. Submitted by: rjung Reviewed by: rjung, jim, jorton git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1876892 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/httpd/compare/dae6cc10c317...c92568b8385a View the full build log and details: https://travis-ci.org/github/apache/httpd/builds/678602444?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Passed: apache/httpd#648 (2.4.x - 4a2ab53)
Build Update for apache/httpd - Build: #648 Status: Passed Duration: 21 mins and 40 secs Commit: 4a2ab53 (2.4.x) Author: Jim Jagielski Message: Merge r1876540 from trunk: PR64295 cannot override default Virtualhost's mod_reqtimeout of course only body=n can work the headers have to parsed to get the virtualhost. Submitted by: jfclere Reviewed by: jailletc36, rpluem, jim git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1876888 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/httpd/compare/d9d02ac48f25...4a2ab5370fdf View the full build log and details: https://travis-ci.org/github/apache/httpd/builds/678577116?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=69847&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Re: Travis notifications for trunk?
On Thu, Apr 23, 2020 at 1:39 PM Stefan Eissing wrote: > > > Am 23.04.2020 um 12:23 schrieb Ruediger Pluem : > > > > > > > > On 4/23/20 12:20 PM, Joe Orton wrote: > >> In the past two weeks we've had three true negative build failures from > >> Travis on trunk - i.e. bugs were introduced and CI caught them - and one > >> false negative (where the gcc 9 build broke because of some change in > >> the Ubuntu repo). So I think we're reaching the point where signal is > >> dominating noise. > >> > >> Is everybody OK with sending e-mail notifications for CI failures for > >> trunk to this list? It's quite likely we will still see occassional > > > > +1. > > > > +1 +1, thanks a lot to all the people that have worked to make Travis checks better!
Re: Travis notifications for trunk?
> Am 23.04.2020 um 12:23 schrieb Ruediger Pluem : > > > > On 4/23/20 12:20 PM, Joe Orton wrote: >> In the past two weeks we've had three true negative build failures from >> Travis on trunk - i.e. bugs were introduced and CI caught them - and one >> false negative (where the gcc 9 build broke because of some change in >> the Ubuntu repo). So I think we're reaching the point where signal is >> dominating noise. >> >> Is everybody OK with sending e-mail notifications for CI failures for >> trunk to this list? It's quite likely we will still see occassional > > +1. > +1
Re: Travis notifications for trunk?
On 4/23/20 12:20 PM, Joe Orton wrote: > In the past two weeks we've had three true negative build failures from > Travis on trunk - i.e. bugs were introduced and CI caught them - and one > false negative (where the gcc 9 build broke because of some change in > the Ubuntu repo). So I think we're reaching the point where signal is > dominating noise. > > Is everybody OK with sending e-mail notifications for CI failures for > trunk to this list? It's quite likely we will still see occassional +1. Regards Rüdiger
Travis notifications for trunk?
In the past two weeks we've had three true negative build failures from Travis on trunk - i.e. bugs were introduced and CI caught them - and one false negative (where the gcc 9 build broke because of some change in the Ubuntu repo). So I think we're reaching the point where signal is dominating noise. Is everybody OK with sending e-mail notifications for CI failures for trunk to this list? It's quite likely we will still see occassional false negatives, and can continue to mark as "allowed failure" any build combination which looks unstable, so it doesn't fail the job overall. As with 2.4.x we will only see fail->pass and pass->fail transitions via e-mail notification. Regards, Joe
Re: svn commit: r1876870 - in /httpd/httpd/branches/2.4.x: ./ acinclude.m4
On Thu, Apr 23, 2020 at 08:56:23AM -, rj...@apache.org wrote: > URL: http://svn.apache.org/viewvc?rev=1876870&view=rev > Log: > systemd dependencies are only needed by mod_systemd. > They should currently not be needed by httpd directly > or any other binary. So no need to add them to > HTTPD_LIBS. .. > --- httpd/httpd/branches/2.4.x/acinclude.m4 (original) > +++ httpd/httpd/branches/2.4.x/acinclude.m4 Thu Apr 23 08:56:23 2020 > @@ -623,7 +623,6 @@ case $host in >if test "${ac_cv_header_systemd_sd_daemon_h}" = "no" || test -z > "${SYSTEMD_LIBS}"; then > AC_MSG_WARN([Your system does not support systemd.]) >else > -APR_ADDTO(HTTPD_LIBS, [$SYSTEMD_LIBS]) > AC_DEFINE(HAVE_SYSTEMD, 1, [Define if systemd is supported]) >fi > fi I think this is wrong on trunk but right on 2.4.x, as seen in Travis => trunk: FAIL https://travis-ci.org/github/apache/httpd/builds/678511325 2.4.x: PASS https://travis-ci.org/github/apache/httpd/builds/678512386 On trunk, systemd socket activation support is in the core so httpd should be linked against $SYSTEMD_LIBS if built with systemd support. On 2.4.x mod_systemd has been backported but socket activation has not, so this is correct. Also I don't think 2.4.x Unix buildsystem changes are CTR ;) tl;dr: +1 for 2.4.x, -1 for trunk. Regards, Joe