# CI for 5.4 - Thread: https://externals.io/message/55268 - Original archive: https://news-web.php.net/php.internals/55268 - Started by Stas Malyshev on 2011-09-07T01:29:42+00:00 - Messages: 39 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/55268.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #55268 — Stas Malyshev — 2011-09-07T01:29:42+00:00 URL: https://externals.io/message/55268#55268 Hi! Since we started to pay real attention to our unit tests now, I wonder if we could set up some kind of frequently-running CI system that could be used to screen commits and identify breakage early? That'd help with 5.4 process I think. We have http://gcov.php.net/ but it doesn't run with the frequency I'd like and since it says the run takes 44 hours it's kind of understandable. So I wonder if we could have something that just builds it and runs unit tests and we could see it in the same format as on gcov? Ideally after each commit would be nice, but say once an hour or two (even fullest unit tests run should take more than that, I think) would be OK too. If we could have two of them, like Linux & Windows, it'd be even better, but at least one would be nice. What do you think? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #55269 — Laruence — 2011-09-07T01:34:24+00:00 URL: https://externals.io/message/55268#55269 · In reply to: #55268 +1 thanks 2011/9/7 Stas Malyshev : > Hi! > > Since we started to pay real attention to our unit tests now, I wonder if we > could set up some kind of frequently-running CI system that could be used to > screen commits and identify breakage early? That'd help with 5.4 process I > think. > We have http://gcov.php.net/ but it doesn't run with the frequency I'd like > and since it says the run takes 44 hours it's kind of understandable. So I > wonder if we could have something that just builds it and runs unit tests > and we could see it in the same format as on gcov? Ideally after each commit > would be nice, but say once an hour or two (even fullest unit tests run > should take more than that, I think) would be OK too. If we could have two > of them, like Linux & Windows, it'd be even better, but at least one would > be nice. > What do you think? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #55270 — Ferenc Kovacs — 2011-09-07T01:53:24+00:00 URL: https://externals.io/message/55268#55270 · In reply to: #55268 > Hi! > > Since we started to pay real attention to our unit tests now, I wonder if we > could set up some kind of frequently-running CI system that could be used to > screen commits and identify breakage early? That'd help with 5.4 process I > think. > We have http://gcov.php.net/ but it doesn't run with the frequency I'd like > and since it says the run takes 44 hours it's kind of understandable. So I > wonder if we could have something that just builds it and runs unit tests > and we could see it in the same format as on gcov? Ideally after each commit > would be nice, but say once an hour or two (even fullest unit tests run > should take more than that, I think) would be OK too. If we could have two > of them, like Linux & Windows, it'd be even better, but at least one would > be nice. > What do you think? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > Hi, I also support the idea. I would suggest setting up a jenkins(ex-hudson) cluster, it is the leading CI product on the market (and a really successful open source project), and it is really well-known in the php community as well, and because I have used for my other projects in the past(not just for php, but for some C apps also). Jenkins supports having multiple slave instances running on different platforms, nicely bound together, so you only access the master instance through your browser, but the builds itself can be off-loaded to the slaves ( https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds ). I would be happy to help setting it up. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #55272 — Pierre Joye — 2011-09-07T06:08:42+00:00 URL: https://externals.io/message/55268#55272 · In reply to: #55268 hi Stas, A new box is being setup with numerous VMs (Dan is on it). Each of of them will cover one supported platform (debian, rh, bsd, win) and will run the builds and tests using rmtools in controlled environment, like what I began to do with windows a while back already. Build and tests log will be available more than daily (will see how fast the tests can be run, but 3-4x daily if necessary should be possible). Code coverage won't be available for all run tho', as it slow down the process and it is not necessary on each revision or change :) Cheers, > Hi! > > Since we started to pay real attention to our unit tests now, I wonder if we > could set up some kind of frequently-running CI system that could be used to > screen commits and identify breakage early? That'd help with 5.4 process I > think. > We have http://gcov.php.net/ but it doesn't run with the frequency I'd like > and since it says the run takes 44 hours it's kind of understandable. So I > wonder if we could have something that just builds it and runs unit tests > and we could see it in the same format as on gcov? Ideally after each commit > would be nice, but say once an hour or two (even fullest unit tests run > should take more than that, I think) would be OK too. If we could have two > of them, like Linux & Windows, it'd be even better, but at least one would > be nice. > What do you think? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55277 — Hannes Magnusson — 2011-09-07T09:29:01+00:00 URL: https://externals.io/message/55268#55277 · In reply to: #55270 > > > […] > > Hi, I also support the idea. > I would suggest setting up a jenkins(ex-hudson) cluster, it is the > leading CI product on the market (and a really successful open source > project), and it is really well-known in the php community as well, > and because I have used for my other projects in the past(not just for > php, but for some C apps also). > Jenkins supports having multiple slave instances running on different > platforms, nicely bound together, so you only access the master > instance through your browser, but the builds itself can be off-loaded > to the slaves ( > https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds ). > I would be happy to help setting it up. We have wanted to setup some buildbots and testing environments for years now, and I think we even have several boxes still laying around for that purposes. If you think you can handle the initial installation, go for it. I'll see if I can hunt down the credentials somewhere. -Hannes --- ## #56015 — Ferenc Kovacs — 2011-11-03T00:46:29+00:00 URL: https://externals.io/message/55268#56015 · In reply to: #55277 On Wed, Sep 7, 2011 at 11:29 AM, Hannes Magnusson < hannes.magnusson@gmail.com> wrote: > > > […] > wrote: > > […] > if we > > […] > used to > > […] > process I > > […] > like > > […] > So I > > […] > tests > > […] > commit > > […] > two > > […] > would > > […] > > We have wanted to setup some buildbots and testing environments for > years now, and I think we even have several boxes still laying around > for that purposes. > If you think you can handle the initial installation, go for it. > I'll see if I can hunt down the credentials somewhere. > > -Hannes > Hi. We ended up creating a Proof-of-concept Jenkins installation using the server which was originally planned( https://wiki.php.net/internals/buildbot ) to be used for the buildbot setup(obviously Hannes managed to get the credentials \o/), and created an RFC based on the current setup and the ways that it could be extended: https://wiki.php.net/rfc/jenkins Basically it continuously(when the are changes in SVN since the last build) builds our supported branches, runs the phpt testsuite(nicely integrated the test results with jenkins), and also executes the Symfony2 phpunit testsuite for each branch. I think that using Jenkins would be really useful, as it is takes care of the "hard" part of the CI process(distributed build support, integration with every QA tool out there), and the php community is pretty much familiar with it (at least those who are knew what the CI acronym means) plus it is easy to integrate the userland testsuites, as many of those projects already using Jenkins or phpunit, which is nicely integrated with Jenkins, thanks to Sebastian. We knew that Pierre and Dan is working on a distributed build/test environment also, so we are well aware the fact that our work is maybe redundant, or could end up as wasted, but we thought that it still worth the effort. Please check out the RFC, and if you have any question or opinion on the matter, feel free to discuss in this thread. Oh, and of course check out http://ci.qa.php.net/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56034 — Ferenc Kovacs — 2011-11-03T17:04:27+00:00 URL: https://externals.io/message/55268#56034 · In reply to: #56015 > > > On Wed, Sep 7, 2011 at 11:29 AM, Hannes Magnusson < > hannes.magnusson@gmail.com> wrote: > > > […] > > Hi. > > We ended up creating a Proof-of-concept Jenkins installation using the > server which was originally planned( > https://wiki.php.net/internals/buildbot ) > to be used for the buildbot setup(obviously Hannes managed to get the > credentials \o/), and created an RFC based on the current setup and the > ways that it could be extended: > https://wiki.php.net/rfc/jenkins > Basically it continuously(when the are changes in SVN since the last > build) builds our supported branches, runs the phpt testsuite(nicely > integrated the test results with jenkins), and also executes the Symfony2 > phpunit testsuite for each branch. > I think that using Jenkins would be really useful, as it is takes care of > the "hard" part of the CI process(distributed build support, integration > with every QA tool out there), and the php community is pretty much > familiar with it (at least those who are knew what the CI acronym means) > plus it is easy to integrate the userland testsuites, as many of those > projects already using Jenkins or phpunit, which is nicely integrated with > Jenkins, thanks to Sebastian. > > We knew that Pierre and Dan is working on a distributed build/test > environment also, so we are well aware the fact that our work is maybe > redundant, or could end up as wasted, but we thought that it still worth > the effort. > > Please check out the RFC, and if you have any question or opinion on the > matter, feel free to discuss in this thread. > Oh, and of course check out http://ci.qa.php.net/ > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > A little update, I finished the master.php.net integration, so now you should be able to login using your svn credentials. ps: you can access the site using https, but it will use a self signed cert, this can be fixed in the future, but unfortunately our *.php.netwildcard cert won't work for ci.qa.php.net :( -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56035 — Klaus Silveira — 2011-11-03T17:10:39+00:00 URL: https://externals.io/message/55268#56035 · In reply to: #56034 What are the current obstacles in a possible Jenkins implementation for the PHP codebase? -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com --- ## #56039 — Ferenc Kovacs — 2011-11-03T18:01:42+00:00 URL: https://externals.io/message/55268#56039 · In reply to: #56035 On Thu, Nov 3, 2011 at 6:10 PM, Klaus Silveira wrote: > What are the current obstacles in a possible Jenkins implementation for > the PHP codebase? > > > -- > Klaus Silveira > (011) 8564-2492 > www.klaussilveira.com > Sorry, I don't really follow you. As I mentioned in my previous email and the RFC, the php-src(all of the supported branches: 5.3, 5.4 and trunk) is already integrated into Jenkins. I also listed the current problems/limitations in https://wiki.php.net/rfc/jenkins#current_problems and there were other obstacles (extending the run-tests.php to generate a test result format supported by Jenkins), but most of them were solved (except those in the current_problems section). Of course there are ways to improve the current setup, I listed those ideas at https://wiki.php.net/rfc/jenkins#future_plans -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56041 — Stefan Marr — 2011-11-03T18:43:44+00:00 URL: https://externals.io/message/55268#56041 · In reply to: #56039 Hi Ferenc: > Of course there are ways to improve the current setup, I listed those ideas > at https://wiki.php.net/rfc/jenkins#future_plans Very nice. I don't know Jenkins, but would it be possible to mail the author of a change in case it breaks something? I just had such a case, where my local setup was insufficient to catch it. Thanks a lot Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 --- ## #56042 — Klaus Silveira — 2011-11-03T18:47:55+00:00 URL: https://externals.io/message/55268#56042 · In reply to: #56041 Yes, it is. But not only email notifications are possible, other interesting integrations are possible. For example, Jabber. https://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Jabber+Plugin > Hi Ferenc: > > > > > […] > ideas > > […] > > Very nice. > I don't know Jenkins, but would it be possible to mail the author of a > change in case it breaks something? I just had such a case, where my local > setup was insufficient to catch it. > > Thanks a lot > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- > > > > -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com --- ## #56045 — Ferenc Kovacs — 2011-11-03T19:15:39+00:00 URL: https://externals.io/message/55268#56045 · In reply to: #56041 > Hi Ferenc: > > > > > […] > ideas > > […] > > Very nice. > I don't know Jenkins, but would it be possible to mail the author of a > change in case it breaks something? I just had such a case, where my local > setup was insufficient to catch it. > > Thanks a lot > Stefan > > It is, and as I mentioned in the RFC the email notification can be enabled when needed, I didn't wanted to do that before introducing the RFC. There is a slight problem however: if we don't build each and every revision (which can happen, if two commit happens before the build starts, which can happen more easily if another build is in progress for that job, because then jenkins will just queue the build, not execute it right away for obvious reasons), so there is a slight chance for "blaming" the wrong person. The usual setup is that you have a mailing list/alias which always gets a mail about the build results (which can also be customized in detail, when to mail, etc.) and optionally you can notify the person whose commit break the build. As Klaus pointed out, there are other possibilities for notification, currently we were using the irc plugin, so if you hang around on #php.qa on efnet, you could see the build results or ask phpcibot about the status of the builds, However I just noticed that there is no way to restrict who can start builds through the irc bot(see https://issues.jenkins-ci.org/browse/JENKINS-5931), so I turned it off. 20:13 -!- phpcibot [~PircBotX@80.82.121.132] has quit [Remote host closed the connection] :( -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56046 — Stefan Marr — 2011-11-03T19:33:06+00:00 URL: https://externals.io/message/55268#56046 · In reply to: #56045 Hi: > The usual setup is that you have a mailing list/alias which always gets a mail about the build results (which can also be customized in detail, when to mail, etc.) and optionally you can notify the person whose commit break the build. If I get a personal notification via mail, if I break something, that kind of guarantees my attention. Using IRC is to distracting, so that is not an option for me. Sorry. If I am the only one who would use it, then don't bother. But if I can simply opt-in for it somewhere, that would be great. Thanks to people like Antony, obviously stupid bugs get caught pretty fast. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 --- ## #56047 — Klaus Silveira — 2011-11-03T19:41:15+00:00 URL: https://externals.io/message/55268#56047 · In reply to: #56046 That's kind of a general setup, Stefan. Sending an email to the commiter that broke the build with details of the build process, as well sending an email to a mailing list. I'll be looking into this Jenkins issue (JENKINS-5931). Maybe having an access control based on IRC operators and voices? > Hi: > > > > > […] > a mail about the build results (which can also be customized in detail, > when to mail, etc.) and optionally you can notify the person whose commit > break the build. > > If I get a personal notification via mail, if I break something, that kind > of guarantees my attention. Using IRC is to distracting, so that is not an > option for me. Sorry. > > If I am the only one who would use it, then don't bother. But if I can > simply opt-in for it somewhere, that would be great. > > Thanks to people like Antony, obviously stupid bugs get caught pretty fast. > > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com --- ## #56048 — Ferenc Kovacs — 2011-11-03T19:43:34+00:00 URL: https://externals.io/message/55268#56048 · In reply to: #56046 > Hi: > > > > > […] > a mail about the build results (which can also be customized in detail, > when to mail, etc.) and optionally you can notify the person whose commit > break the build. > > If I get a personal notification via mail, if I break something, that kind > of guarantees my attention. Using IRC is to distracting, so that is not an > option for me. Sorry. > > agree, this is why this option is present. > If I am the only one who would use it, then don't bother. But if I can > simply opt-in for it somewhere, that would be great. > I think it would be useful, I just wanted to mention the only downside that I can think of. Of course if everybody else would be against the idea, you could still subscribe to the mailing list where the general report goes, and filter the messages to only receive those mail to your inbox which reports a build which was triggered by you (if I remember correctly, by default the email would contain who started the build, either through SCM or manually). -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56049 — Ferenc Kovacs — 2011-11-03T19:49:55+00:00 URL: https://externals.io/message/55268#56049 · In reply to: #56047 On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira wrote: > That's kind of a general setup, Stefan. Sending an email to the commiter > that broke the build with details of the build process, as well sending an > email to a mailing list. > > I'll be looking into this Jenkins issue (JENKINS-5931). Maybe having an > access control based on IRC operators and voices? > yeah, using voices would work, but then that would mean that it is only a read only channel for most people, which imo would be a bad move. I mean it would be really nice, if people could drop by to our qa related irc room and start talking about that pesky build failure. another solution would be to set up a custom irc bot, independently from jenkins, which could fetch the build results through the mailing list or rss and send it to the channel. of course extending the jenkins irc bot is also a possibility, the easiest way would be having a configuration option for disabling the whole control stuff, as we don't really need the interactivity there, you can use the web interface for that. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56051 — Felipe Pena — 2011-11-03T21:22:03+00:00 URL: https://externals.io/message/55268#56051 · In reply to: #56049 2011/11/3 Ferenc Kovacs : > On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira wrote: > > > […] > > yeah, using voices would work, but then that would mean that it is only a > read only channel for most people, which imo would be a bad move. > I mean it would be really nice, if people could drop by to our qa related > irc room and start talking about that pesky build failure. > another solution would be to set up a custom irc bot, independently from > jenkins, which could fetch the build results through the mailing list or > rss and send it to the channel. > of course extending the jenkins irc bot is also a possibility, the easiest > way would be having a configuration option for disabling the whole control > stuff, as we don't really need the interactivity there, you can use the web > interface for that. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > Nice work with this Jenkins stuff! The system seems pretty useful. I like the idea to have a mailing list for build result notification, as well as send mail to the build breaker. -- Regards, Felipe Pena --- ## #56052 — Klaus Silveira — 2011-11-03T21:25:56+00:00 URL: https://externals.io/message/55268#56052 · In reply to: #56051 Yes, it's a wonderful setup. Great work, Ferenc! :D This does give a nice motivation to write more tests and increase the code coverage, doesn't it? > 2011/11/3 Ferenc Kovacs : > > […] > contato@klaussilveira.com>wrote: > > […] > an > > […] > easiest > > […] > control > > […] > web > > […] > > Nice work with this Jenkins stuff! The system seems pretty useful. > I like the idea to have a mailing list for build result notification, > as well as send mail to the build breaker. > > -- > Regards, > Felipe Pena > > -- > > > > -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com --- ## #56053 — Ferenc Kovacs — 2011-11-03T21:26:36+00:00 URL: https://externals.io/message/55268#56053 · In reply to: #56051 > 2011/11/3 Ferenc Kovacs : > > […] > contato@klaussilveira.com>wrote: > > […] > an > > […] > easiest > > […] > control > > […] > web > > […] > > Nice work with this Jenkins stuff! The system seems pretty useful. > I like the idea to have a mailing list for build result notification, > as well as send mail to the build breaker. Thanks for the feedback. We could set up the email notification any time, we would just have to agree where to send (internals, php-qa, creating a dedicated mailing list?) and when to send (as I added to the RFC, having failing tests can be a problem from the notification POV). We have to find a good middle way, else we will either miss the notifications, or we will be overwhelmed, so people will just ignore it. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56054 — Ferenc Kovacs — 2011-11-03T21:29:39+00:00 URL: https://externals.io/message/55268#56054 · In reply to: #56052 On Thu, Nov 3, 2011 at 10:25 PM, Klaus Silveira wrote: > Yes, it's a wonderful setup. Great work, Ferenc! :D > > This does give a nice motivation to write more tests and increase the code > coverage, doesn't it? > Yes, and first of all, to fix the currently failing tests. We also had a discussion with Hannes, that the build machines could also be used for hunting down bugs, for which the developer doesn't have an environment to test and reproduce the problem. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56056 — Rasmus Lerdorf — 2011-11-03T22:33:38+00:00 URL: https://externals.io/message/55268#56056 · In reply to: #56053 > We could set up the email notification any time, we would just have to > agree where to send (internals, php-qa, creating a dedicated mailing list?) > and when to send (as I added to the RFC, having failing tests can be a > problem from the notification POV). > We have to find a good middle way, else we will either miss the > notifications, or we will be overwhelmed, so people will just ignore it. Ideally they should go to internals if you can get them to be non-noisy. As long as it only reports a test status change from the previous run, hopefully that wouldn't create much noise. -Rasmus --- ## #56057 — Ferenc Kovacs — 2011-11-03T22:47:07+00:00 URL: https://externals.io/message/55268#56057 · In reply to: #56056 > > > […] > list?) > > […] > > Ideally they should go to internals if you can get them to be non-noisy. > true > > As long as it only reports a test status change from the previous run, > hopefully that wouldn't create much noise. yeah, and that is a little bit of a problem, because as I mentioned by default the jenkins way is that your tests passes: http://jenkins.361315.n4.nabble.com/Test-failure-baseline-td386476.html so we have three option as far as I can see: A, it will report every test failure, but we fix all of our tests so we are cool. (my preference) B, same as A, but until we fix all of the tests, we mark the failing test as XFAIL, which won't be counted as failed test (I'm against it, as time taught us that we are lazy, and XFAILs will be kept that way. :/) C, Somebody(me) do some scripting, and our currently failing tests won't fail the build, only make it unstable, but any other test failure will fail the build. I think I didn't explained in the RFC, because currently we don't use it, but in jenkins there is a third result type for a build apart success and failure: unstable. Most plugins support this, as does the email notification plugin also, so this should also work. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56058 — Rasmus Lerdorf — 2011-11-03T22:58:47+00:00 URL: https://externals.io/message/55268#56058 · In reply to: #56057 > A, it will report every test failure, but we fix all of our tests so we > are cool. (my preference) But even if we do that, when a test does fail, it may take a couple of days to fix it. It would be nice if we didn't get an internals email for every commit that triggers a build during that time. So even in this ideal case I think the notification mechanism needs to be smarter. -Rasmus --- ## #56059 — Ferenc Kovacs — 2011-11-03T23:12:16+00:00 URL: https://externals.io/message/55268#56059 · In reply to: #56058 > > > […] > > But even if we do that, when a test does fail, it may take a couple of > days to fix it. It would be nice if we didn't get an internals email for > every commit that triggers a build during that time. So even in this > ideal case I think the notification mechanism needs to be smarter. > > -Rasmus > using the email-ext plugin: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin one can bind email notification on the following events: - Failure - Unstable - Still-Failing - Success - Fixed - Still-Unstable - (Before-Build) So we could configure to only send emails on Failure and Fixed(I ignored the Unstable on purpose for the sake of simplicity, of course we also use this for option C). That way we would only see the notification on the first error, and the next mail would be when we finally fixed it. This is still suboptimal, as we wouldn't get email notifications about the other test failures introduced between the first failure and the fix, but I think that having a failed build would mean that somebody/everybody is working on fixing the build, so those test failures would also be spotted(on the web interface) and fixed (without that, the build won't succeed). I almost forget to mention, but the email notification also supports defining different recipients for each event, so for example the commiters could still get the notification for each of their commits/builds until the build is back to normal, that way the list wouldn't be spammed, but some active contributors would be still continuously bugged. How does it sounds to you? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56061 — Ferenc Kovacs — 2011-11-03T23:21:28+00:00 URL: https://externals.io/message/55268#56061 > Hi: > > > > > […] > defining different recipients for each event, so for example the commiters > could still get the notification for each of their commits/builds until the > build is back to normal, that way the list wouldn't be spammed, but some > active contributors would be still continuously bugged. > > Does that meant that the committer could get an unconditional email with > the result of his/her commit? > > Sounds very reasonable to me. > > yep. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- Next page: https://externals.io/message/55268.md?page=2