http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13323 (sorry for not responding all day, I wasn't feeling well.) Boris said downthread what I think about this -- "never", without qualification, should not be used for this option. "No thanks" seems much better to me; it reads as declining *this upgrade offer* rather than *this and all future upgrades*. I get (good-natured) extra grief about the upgrade offers because one of the users in this particular minority boat is my girlfriend, but I'm not really objecting to the policy, only the presentation. "We don't do major upgrade offers often but it's our collective opinion that the vast majority of users really are better off upgrading; this will ultimately mean you don't need to keep FF2 around either; and on a technical level, separating security updates from major upgrades would add more moving parts to a release process that's already too complex" is a perfectly sensible policy decision. But "The button says 'never' and I expected that to mean I would never see a major update offer again on this insta Zack Weinberg 2008-12-05T02:06:36 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13322 http://konigsberg.mozilla.org/crash-stats.html please incorporate. Ideally w/ same origin you could prefill the id and sig fields as they load. On 12/5/08, morgamic <morgamic< at >gmail.com> wrote: timeless 2008-12-05T01:37:00 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13321 We are evaluating use cases and workflow for our crash reporting system and would like your feedback on how to improve the crash reporting UI: http://blog.mozilla.com/webdev/2008/12/04/socorro-wireframes/ Please take some time to view Neil's post and let us know what you think. Thanks, Mike morgamic 2008-12-04T22:18:51 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13320 I'd really like to see the occurrences tracked in the associated bug and think the discussion should also happen there. Why create a new process when we already have one? We'd still need a simple way to find the bug associated with the orange as Benjamin mentions. Robert Robert Strong 2008-12-04T20:45:45 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13319 Potentially if the sheriffs newsgroup is ever created then we could create a thread in there for each known issue and track when it happens and what might solve it. Dave Townsend 2008-12-04T20:36:35 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13318 Given that the people in question do Web development, perhaps you could tell them that they ought to tolerate this slight annoyance in order to not have to keep their copy of Firefox 2 around as long, since if we get users off of it they won't have to test against it? -David L. David Baron 2008-12-04T20:12:40 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13317 Part of the point was to have a mapping of "failure text" -> bug number... that particular week there were five separate oranges; some of them had bugzilla bugs, but I couldn't find them. The details of the compedium are up in the air, but I think we need some way of mapping failure text -> bug number and tracking when that particular form of failure started and stopped appearing. --BDS Benjamin Smedberg 2008-12-04T20:00:50 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13316 Do we want to do this or something similar now that November is over? It didn't appear to get updated for all oranges so perhaps it might be better to change this somewhat. In the past I've posted recurrence in the bug for the orange which might be a better way to keep track of how often they are occurring. Cheers, Robert Robert Strong 2008-12-04T19:50:04 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13315 The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=324121 The button text changed from "Never" to "No Thanks" -Robert Robert Strong 2008-12-04T19:45:36 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13314 The group of users that want to keep around multiple versions of the same browser is obviously a very small percentage, but if we add a visible option, then everyone will have to read it and think about it. It is important to consider that any additional UI comes with a cost, not just in terms of more complicated code, but in creating a more bloated and complex experience for the majority of mainstream users. Something less direct, like an about:config pref would probably be a better level to address the needs of these users without the costs of adding UI. As a side comment, the mention of "free" in this thread's subject line and beltzner's blog is indeed funny, but that got me wondering how many users actually turn down a major update that they would otherwise enjoy using because they don't want to have to pay for it. If they didn't initially put Firefox on the computer, they don't really have any reason to know that it is free. I think we added the word "Free" to the downlo Alex Faaborg 2008-12-04T18:19:20 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13313 Yes, known issue, and I think fixed (by Rob Strong, based on text I gave him) in Firefox 3.1. Can't find the bug right now, but if I didn't fix it, I will. cheers, mike Mike Beltzner 2008-12-04T18:02:36 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13312 I think part of the issue here is that the button says "Never" whereas it means "Not until the next version is available" or something along those lines... I know that if I click a button labeled "Never" when asked whether I want to do X and then later I'm asked whether I want to do X, even if it's months later, I feel that the software doing the asking is buggy. Looking at the dialog image linked in your blog post, it's not at all obvious that "Never" means "Never upgrade to Firefox 3.0.1 but check with me again for a later dot-release of Firefox 3". The only mention of 3.0.1 is the small text at the top, right? Everything else is generic Firefox 3. It feels like a bit of wordsmithing should be able to help here, but it'd have to be highly competent wordsmithing. I haven't been able to think of a short yet more informative button label yet, for example. :( -Boris Boris Zbarsky 2008-12-04T17:57:49 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13311 That doesn't address: -Sam Samuel Sidler 2008-12-04T17:53:38 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13310 That's a surprising thing to hear, since at the time of the last major upgrade offer, there had been no previous major upgrade offer (other than several years ago, when we upgraded from Firefox 1.5 to Firefox 2). The cost of declining an upgrade is really not that high, especially when they happen at four month intervals. As Benjamin pointed out, they can turn off the updater altogether, but then they don't get their minor updates. I disagree that there should be a UI facing option to differentiate between minor and major updates. This doesn't feel like the sort of thing we need to spend time on. Instead, we should be careful to offer major updates infrequently and only when we have good reason, remembering that it is an imposition on the user. Which, for the record, we do. cheers, mike Mike Beltzner 2008-12-04T17:49:57 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13309 You could of course disable app update altoghther. --BDS Benjamin Smedberg 2008-12-04T17:38:26 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13308 Well, there is, but not a pretty one: saying never stores a pref like app.update.never.3.0.4, so to have never mean never for any versions, you would need to add prefs for any version you thought might ever be offered. Phil Ringnalda 2008-12-04T17:23:19 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13307 The UI means "never upgrade to this version" and they're specifically upgrading to Firefox 3.0.n, where n is the version we decide. We could probably improve the UI, of course. (File a bug with your suggestions!) These users are in the minority. For the Firefox 1.5->2.0 migration we only offered 2 major updates. That's not "forever". This time around we have 3 planned. Our goal is to get users off of Firefox 2 as soon as possible. This actually *helps* web developers. The more users on Firefox 3, the less they have to debug Firefox 2 web development issues. I'm, personally, okay with this small set of users suffering minor annoyances every few months while we work to upgrade the millions of regular users who are using software that will soon be at its end-of- life. I don't think there is a way to do that and I'm not sure it's common enough that we'd want to add such a feature, certainly not to the UI. Doing so would discourage other users from upgrading. The minority who don't w Samuel Sidler 2008-12-04T17:09:56 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13306 Saw this go by on planet mozilla: ... I heard from a bunch of people (mostly they do web development) around the time of the previous major upgrade offer; they said that when they clicked the "never" button on the major upgrade offer before *that* one, they expected it to mean "never", not "in several weeks or months". These people typically already have Firefox 3, but need to keep v2 around to test their websites with. They expect to need it indefinitely. They don't want to have to re-decline upgrades at four-month intervals forever. When 3.1 comes out they'll probably want to keep 2 *and* 3.0 around indefinitely. I'm sure there's *some* way to opt out of major upgrades permanently while keeping security updates active (they do want those). But it would be nice if it were there in the UI. zw _______________________________________________ dev-planning mailing list dev-planning< at >lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning Zack Weinberg 2008-12-04T16:56:43 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13305 The Monday and Tuesday ones were the ones that came to mind but there were others previously as you noted. It also can help the sheriff when they have to investigate oddities. For example, bug 443979 which changed the Mac OS X TP3 RSS and TP3 Mem-PB graphs or when there are changes to the graphs (for the better or worse) due to closing for a merge. Cheers, Robert Robert Strong 2008-12-04T08:01:10 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13304 Do you have dates to hand? The ones I can remember recently are: - Tuesday AM: buildbot maintenance, announced in dev.planning - Monday AM: branching, buildbot maintenance - Saturday: closed for regression hunting Before that the tree was closed for metering and various regression hunting and pre-freeze TraceMonkey merges occasionally, and I doubt any of those got logged. AIUI, the TreeClosures page is meant to be, like the Orange Compendium, a way to figure out if there's maintenance or systems improvement that needs to be done. cheers, mike Mike Beltzner 2008-12-04T07:49:59 http://permalink.gmane.org/gmane.comp.mozilla.devel.seamonkey/13303 I've seen several tree closures over the last few weeks with some of them having nothing to do with the branching yet the tree closures page hasn't had a tree closure note added since 11/12. I personally find this info useful at times and would like to see it maintained but if it isn't going to be maintained I would prefer that it be removed. Cheers, Robert Robert Strong 2008-12-04T07:38:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.devel.seamonkey