the result of the change will be: 1, the email alarm may able to build, but we removed the origin records.config 2, the custom alarm script still need your own work 3, documents still lack, and more documents to be add on the change
back to the real problem here, what we want to solve in TS-2143 then? for the feature point of view, is that a good idea to get big change in UI( config file change) while you can not get a better one? I don't think we are improving the alarm feature. in our new release processes: • A best-effort to keep compatibility should be made; don't break compatibility for no good reason. • Commits that breaks compatibility are not allowed on master. Such changes gets committed instead on a next-incompatible-rev branch (call it 5.0.x). I think there is NO GOOD REASON for breaking the alarm feature, if is not a improvement on the feature. I think we can find out some compatible way to get the codes clean and don't break the feature. 在 2013-8-23，上午2:36，James Peach <jpe...@apache.org> 写道： > On Aug 22, 2013, at 9:35 AM, Leif Hedstrom <zw...@apache.org> wrote: > >> On Aug 22, 2013, at 10:11 AM, James Peach <jpe...@apache.org> wrote: >> >>> On Aug 21, 2013, at 5:51 PM, 永豪 <yong...@taobao.com> wrote: >>> >>>> things I'd like to keep: >>>> 1, feature should be outlined, and should keep revolution in a user >>>> friendly way >>>> 2, provide basic system 'it just work' >>>> 3, user interface changing should get more review before we can release >>>> into public >>> >>> Yes, I strongly agree with all 3 of these points, though I don't think this >>> particular commit is too problematic, particularly since we never actually >>> installed the example_alarm_bin.sh script :) >>> >>> I looked at the alarm documentation and there's a few things that we can >>> improve: >>> >>> - the docs still reference example_alarm_bin.sh though it no longer >>> exists >>> - the docs reference proxy.config.alarm_email, though it's no longer >>> clear what this is for >> >> Yeah, proxy.config.alarm_email is no longer used, and unless we back out >> this commit, we should remove it. >> >> So, I'm asking now for consensus, with two options: >> >> 1) We restore the old behavior, which passed the email address on the >> command line to the alarm script. I'd still argue that this old behavior >> simply did not "just work", it basically "just failed miserably". +1, it just work on the ATS point of view. if that may fill the filesystem with emails, it is the problem with email system. I think I have filed a mail to ask your guys about including the example_alarm_bin.sh in the 'make install' :( http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201204.mbox/%3C1334756466.21031.5.camel@zym6400%3E >> 2) We keep the commit, but also remove proxy.config.alarm_email (cause it's >> unused right now). > > +1 > >> The improvements James points out are great, lets file an RFE on those. For >> example, there's nothing right now preventing someone from contributing a >> much better alarms.sh script. Or several of them, for different use cases, >> and something that actually does work. >> >> Please voice your opinions asap, I'd like to get this resolved by tomorrow >> (Friday) morning. > > Let's not revert, let's improve. > > I will commit a change to add a new configuration option > proxy.config.alarm.arguments that contains a string of arguments that get > passed to the the alarm script. The final invoked command will be: > > "%s/%s %s %s %s", proxy.config.alarm.abs_path, proxy.config.alarm.bin, > proxy.config.alarm.arguments, description, alarm > > Then I will commit a variation of the original emailing script as a default. > IMHO this supports the original use case, actually works out of the box for > clean installations, and makes sense for sites that don't want this to be > emailed. > > J
signature.asc
Description: Message signed with OpenPGP using GPGMail
