On Thu, Jul 7, 2011 at 6:11 AM, Dylan Ryan <[email protected]> wrote:
> [...] > I know, but I see it slightly differently. From my perspective, *if* there > is a widespread problem with just adding the new UUIDs, odds are I'll notice > it quickly after making a change. That is, extensive testing isn't necessary > for a widespread problem, cursory testing will almost certainly find it. And > if there is a highly specific problem, odds are no amount of testing I can > do will find it because I probably don't have access to the right > combination of hardware and software to trigger it anyway. That is, > extensive testing isn't helpful because odds are I do not have the right > equipment to trigger it, so why waste time trying to do the impossible? So > rather than testing for a week knowing that odds are I won't find anything, > to me it seems more logical to update the UUIDs, do a quick "does this > work?" check on as much hardware as I can, then release it as a "potentially > unstable" version an hour or two after a system update. Anyone who can't > wait can use it and provide the large testing platform that I don't have > access to, but the vast majority of people will likely find that it works > because it passed the "works on my hardware so probably works in most > places" test. This seems better than waiting a week or more to test, not > finding anything, releasing a "this *is* stable" version, and having the > same people that would have caught the problem in the "potentially unstable" > version catch it anyway and report it. It cuts a week or more off the wait > time for people willing to take a risk (makes people happy), means less > problems on versions that are expected to be stable (makes people happy), > etc. > > Granted, for general software, that is probably the *worst* possible > method you could think of for pushing updates, but for such a small bundle > that does just one thing (and does it well), it seems that it would be > generally helpful. There aren't a lot of features to test, so a fairly basic > "Does it work?" type check is close to exhaustive. Especially given the > track record. As I said, as far as I have seen, I've never had a problem > simply adding the UUIDs, so that has a track record of working (or I am > lucky and have a blessed hardware/software combo that just happens to always > work). Obviously, anything could change at any time, but I still think an > unstable branch that updates fast and *should* work but might not, and a > stable branch that almost always does work but takes time to update (think > Chrome, etc) leads to getting updates out quicker, and if an unstable branch > breaks for some people for a few days, well, that's why it's called > unstable. > > Hopefully that makes sense :) > Does anyone know and feel free to comment whether, aside from UUIDs, the current GrowlMail works (at least to the quick "does this work" standard) with the 10.7 GM that's available to paid-up devs? In other words, it's one thing if it probably has a couple years life left in it at a minimum. But it it would need a lot more for 10.7 (and remember, Mail _is_ said to be changing, so I wouldn't care to bet on a guess either way), then maybe some alternative would be better. Either way, clickback with AppleScript would be great, if possible. And for those of us challenged by anything as "friendly" as AppleScript (give me C++ anytime over that!), some sample rules to approximate GrowlMail behavior corresponding to different preference settings would be a big help, particularly if having someone else keep GrowlMail alive turns out not to be as straightforward as adding UUIDs, running some quick checks, and repackaging it. -- You received this message because you are subscribed to the Google Groups "Growl Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.
