On Jul 7, 2011, at 2:06 AM, Christopher Forsythe wrote: > > > On Thu, Jul 7, 2011 at 3:36 AM, Dylan Ryan <[email protected]> wrote: > > On Jul 7, 2011, at 12:55 AM, Christopher Forsythe wrote: > >> >> >> On Thu, Jul 7, 2011 at 2:16 AM, Dylan Ryan <[email protected]> wrote: >> Just my 2 cents. I also more or less only use growl because of growl-mail. >> Sure it's nice to get other notifications, but without growl-mail, I'd >> rather not have one more app running even if it is a very minor resource >> user. i.e. Growl Mail is the only thing that KEEPS me using Growl. Other >> things are nice but I can live without. >> >> GrowlMail source is freely available, you may maintain it on your own. > > I know, but I'd rather keep it "official" for more people to be able to find. > I could make my own and host it (probably on dropbox since that's the > easiest), but very few people would find it. Though if I did and you could > link to it, that'd work too. I just don't want to maintain it online if the > majority of growl users have no easy way to find it. I'd maintain it for > myself regardless since I use it, but doing testing for other than my > configuration is something I'd only do if I know more than a handful of > people can find it. > >> >> >> What kind of work goes into maintaining growl-mail? I'd be willing to donate >> my time to keeping it up to date, but I am not the greatest coder in the >> world (though I learn quickly). Every time a new OS update comes out, I >> install it day 1, and I've always just manually added the new bundle-id to >> the old version of GrowlMail's .plist and it has always worked for me on >> both 32 and 64-bit intel machines, so (at least so far) no major changes >> have been *necessary* that I've seen. If it's just adding the new IDs and >> (possibly many) minor internal changes (and rebuilds), I can do that no >> problem (I have access to a 64-bit intel MBP that I always keep up-to-date, >> a 32-bit intel MBP that I can either keep up-to-date or lag a version if >> needed, and PPC machines on Tiger as well, so I can test on a fairly wide >> spectrum of hardware and software). >> >> Can you give us more info on what the changes it typically requires are? >> >> Check the release notes and tickets, those are the best things to look at. >> > > I did. For system updates forcing growlmail updates, all I see are scattered > 1- or 2-line changes in the changelogs that look like they take all of 2 > minutes (plus build/upload time) and could be trivially automated so that > it's just a matter of running a "fixGrowlMail" script and having a bundle > ready. Add in some (also easily automated) testing on a variety of systems, > and I am not seeing anything that would take more than an hour tops per minor > system update, with possibly more considerable changes for major system > updates. > > There's a lot of problems with just mental state switching between Growl and > GrowlMail. Part of the problem is that since this is all not really supported > by Apple, we feel it's necessary to test the plugin for quite a while before > providing an update. There's a certain responsibility there.
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 :) > > Since you say that it is the most time-consuming part of maintenance, I am > assuming there must be a lot more than this, but I am not seeing it with a > cursory glance at the 'logs. It doesn't help that over half the links on the > growlmail changelog go to a non-public repo > (http://growl.info/hg/growl-development/) so I have to delete the > -development from the URL to see them. > > > That's offline temporarily until 10.7 comes out to avoid nda violations. Makes sense. But some of the links point to the (stable) hg and some to the dev. Would be better just to point them all to stable since I was able to delete -development and get to what looks like the right changesets in every case. > > > Looking at the open growlmail tickets, they all look either minor or else > things that I can certainly try my hand at. (I might start chipping away at > them shortly, just to see if my expectations match reality) > > Basically, from what I can see, the known required maintenance (at system > updates) looks minimal, and for the most part, growlmail works now. So, I can > certainly handle trivial maintenance duties, and can try to tackle other > bugs. Of course, it's possible I'm being horribly naive about it, but the > bare minimum job of keeping it working as well as it works now is something I > can (and will) definitely do. > >> If I think I can handle it, I'll take full responsibility for getting things >> done promptly and keeping it alive for as long as I can. (In all likelihood, >> I'll just be building my own versions from source if it dies anyway, so I >> may as well help the project out instead of being selfish about it). >> >> >> The problem is that then GrowlMail becomes the only thing we ship that is >> still a distraction. In four months say you don't want to do this anymore, >> then we have to kill it yet again. > > Not likely to be a problem. Barring any catastrophes, I'm willing to maintain > it forever, if only because I use it and will want it fixed for me. Now, > granted, I could get hit by a bus tomorrow, but other than that, I'll be > keeping it running at least for myself for as long as I can anyway. If I can > keep it going for everyone who uses it and keep it readily > available/findable, I'm more than willing to do so. > >> >> I am less interested in handling Growl-Safari, as I personally do not use it >> much and given what you just said, it sounds beyond my ability. Though as >> long as it isn't a major headache, I can handle minor changes to it (that >> is, I am willing to keep it alive for as long as my skill allows me to, if >> people are interested). >> >> >> >> I'd say take on what you like. >> >> We haven't sent the official email about the details of GrowlMail being >> retired yet, please wait for that first. > > Fair enough. Just putting it out there that I'm willing to take it on, along > with all the support burden. > >> >> Chris >> >> >> Dylan >> >> >> On Jul 7, 2011, at 12:03 AM, Peter Hosey wrote: >> >>> On Jul 7, 2011, at 00:00:09, ravedog wrote: >>>> What is the logic behind killing GrowlMail and Growl Safari other than >>>> they are plugins for Apple apps. DO you have to kill them to gain entrance >>>> into the store? >>> >>> Growl could get into the store regardless of whether we kill GrowlMail and >>> GrowlSafari. >>> >>> GrowlMail has been a terrible support burden, as much work to maintain as >>> all of our other products combined. GrowlSafari is fragile internally, so >>> while it hasn't caused us many headaches *yet*, it's only a matter of time. >>> >>> So, we're killing both of them. This will free up the time we'll need to >>> make all the necessary changes to Growl and leave us plenty of time in the >>> future to maintain all of our surviving products. >>> >>>> Also, will it still be fully AppleScriptable and have the same dictionary? >>> >>> That's the plan. >>> >>> -- >>> 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. >>> >> >> >> -- >> 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. >> >> >> -- >> 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. > > > -- > 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. > > > -- > 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. -- 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.
