Josh Lucas wrote: > >> 1) Be stateful. A success is only news if the build previously failed, and >> vice versa. This should enable this script to scale quite a bit further. >> This will also increase the value of the newsfeed - it will also convey >> exactly when something was first noted to be broken and projects which are >> perenially broken will cease to be new news. > > Hmm.. I don't quite understand what you mean. In a sense, know what > happened last time and do 'something' if that value has changed ?
Let me explain in programmers terms. Picture a queue of 16 items. Prior to scanning the gump log, read in a list of the "last known status" for each project. When reading the gump log, discard (i.e., don't put into the RSS feed) every item that does not involve a change in state. Add the remainder to queue. Does this help? RSS is typically for "news-y" things, right? Things that just got broken (or fixed) will be "top news" and things that have been in a given state for quite some time will drop lower on the list. >> 2) Optionally use the naglist to tailor on a per project basis things like >> contactperson. > > well, the rss feed just displays it once, in its header so I don't think > it would work with the naglist.. Nevermind. ;-) - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
