Closed Bug 186190 Opened 17 years ago Closed 16 years ago
.mozilla .org upgrade meta-bug
bugzilla.mozilla.org could use an upgrade to catch regressions and bug fixes since the last upgrade in November and to keep it close to the tip. I'd like to do this around the middle of January, say Friday, January 17. Ideally Bugzilla would do a developer's release around that time and we could do a joint stability freeze beforehand.
Nominations/things to get on the radar: Bug 186994 - Unable to accept a new bug that has been assigned. (patch; awaiting clarification from bbaetz) Bug 183017 - Only numbers displayed when bar chart contains too many products (patch; awaiting more data from Joel) Bug 172434 - Useful link on the bugzilla page to ease download of NEWEST version (patch; awaiting Myk's review) Gerv
Also: Bug 129366 - Allow unprivileged users to file bugs into Mozilla security groups Gerv
The upgrade isn't going to happen this week. Rescheduling for Friday, February 7, 6:00PM PST (UTC-08:00). Nominations: Bug 186994 - yes, significant functional problem Bug 183017 - no, relatively rare problem with available workaround Bug 172434 - no, minor, but I do plan to review this before the upgrade Bug 129366 - yes, important for mozilla.org
Unless it goes away, Bug 188161 "I don't have permissions to edit a bug even I'm assigned to it"
And can't you do what 129366 does just by setting permissions in 2.17.3 ???
Joel may have a point there :-) Let's upgrade, and we can post-patch later if we can't make the new groups system do what we want. Gerv
IS this still up for next week?
It could be, if we can get some fixes in by then.
Hmm, this didn't happen, obviously.
clearing the ETA - it's obviously wrong :)
Whiteboard: [ETA: Friday, April 11, 6:00PM PST (UTC-08:00)]
This will be happening sometime after the server move.
Depends on: 215201
Whiteboard: Tentatively scheduled for Thursday December 4, 2003
Reminder to those watching this bug... to the best of my knowledge, we're still on for the current proposed upgrade date (listed in the status whiteboard), which is now is 3 days. If anyone has low-risk bugs that they really want to see in before the upgrade, now is the time to get them reviewed and pushed in. Any major/show-stopper or high-risk bugs should be proposed here for consideration as blockers to this bug (Please don't place them on the dependency list yourself, that will be up to Myk to decide).
I'm on a push to get a lot of new charts fixes in, but that's clearly marked as "still in beta" so I don't consider those risky :-) Gerv
I'm looking at Gerv's stuff, it's almost there. Okay, I've got: - Bug 227213, which fixes some s and chomp issues in token emails and pages - Bug 226754, which cleans up the logout mechanics and unregresses erasing logincookie database entries which I broke with bug 226324. I've been doing some sweeps through the code to see if I find anything else obviously needing fixing.
regarding bug 129336 (which resulted in a local hack to bmo, and was closed on the Bugzilla product in deference to the group controls rewrite), here's the changes that need to be done on bmo after the upgrade to restore this functionality using the new system: Each product that we want users to be able to do this for will need to be configured separately. For webtools-security that would be: Webtools Bugzilla For mozilla-security that would probably be just about everything else. For each product: 1) go to Group Controls 2) for the appropriate security group, set the following: Member- Other- Entry Control Control CanEdit [ ] [Shown] [Shown] [ ] The effect of this is that anyone can enter a bug in the security group, but once it's there, you have to be in the group to remove it. This is essentially the same as how it is now with our local hack. Because this only shows the group description, the descriptions on both of the security groups will also need to be modified to use as close to the wording on our hack as possible so that people know what to do with the checkbox. Thanks to this new system, it will also be possible to *prevent* people from putting Webtools bugs into the Mozilla security group and vice-versa. Before we enforce that however, we should probably audit bugs to make sure we don't currently have any in the wrong group, because changing that policy will enforce that policy retroactively on all existing bugs on the new system.
Doesn't the product group change code prevent you from changing the availability unless the groups will match the new restrictions? If it doesn't, then its a sanitycheck.
no, the groups code changes the bug restrictions to match the new policy for the product. i.e. if you make a group Mandatory/Mandatory, it'll update every bug in that product and add that group to it, and if you make it NA/NA then it'll go through and remove that group from every bug in the product. Which is why we want to audit for misplaced groups first so we don't accidently open any bugs. Although I think it'll prompt you first before doing it, and tell you how many bugs need to be changed, but offer to do it for you. But I'm not positive. Joel?
The "Edit group controls" page shows bug counts, but there is no "confirm" page.
ah, that's right, we have bug counts on that screen, so we'll know before we click anyway :)
I came down with a severe case of the flu yesterday, and while I might be better by Thursday evening, I won't be able to do enough preparation beforehand, so we need to reschedule. The following Thursday could work, but anything later than that and it'll have to wait until after the holidays, since we won't have enough time to recover from regressions.
Whiteboard: Tentatively scheduled for Thursday December 4, 2003 → Tentatively scheduled for Thursday December 11, 2003
We need to push this off to next month, as I don't have the time before the holidays to give it the attention it requires.
Whiteboard: Tentatively scheduled for Thursday December 11, 2003 → Tentatively scheduled for Thursday January 23, 2004
Whiteboard: Tentatively scheduled for Thursday January 23, 2004 → Tentatively scheduled for Thursday January 22, 2004
The new plan is to upgrade at noon PST (GMT-08:00) on Sunday, January 25, 2004. That'll give us extra time that day to fix regressions and prepare the installation for Monday's activity. Also, we're planning a developer's release (2.17.7) for Monday, December 19 to expose the latest bits to the larger development community and shake out any regressions before the upgrade. It's also about time (2.17.6 was released over two months ago).
Whiteboard: Tentatively scheduled for Thursday January 22, 2004 → tentatively scheduled for noon PST (GMT-08:00) Sunday, January 25, 2004
You mean January 19. :) /me grumbles about copy/pasting it to the mailing list and not catching that
Bug 231927 (alias: bmo-regressions) will be for tracking regressions after the upgrade. Removing bug 171553 (request tracker bugs) from the list of blockers; they won't all be fixed by the time we upgrade.
No longer depends on: rt-clean-up
QA Contact: myk → justdave
Whiteboard: tentatively scheduled for noon PST (GMT-08:00) Sunday, January 25, 2004 → scheduled for noon PST (GMT-08:00) Sunday, January 25, 2004
This isn't a regression, but doing a "Find a Bug" search for "crash secure SSL flash" (the example given) gives: http://mecha.mozilla.org/bzupgrade/buglist.cgi?query_format=specific&bug_status=__open__&product=&content=crash+secure+SSL+flash The first bug on this list is bug 185662 - "In SMTP prefs, make it clear what "use secure connection (SSL)" really means". It doesn't contain the words "flash" or "crash" at all. Perhaps it would be less embarrassing to pick another example before the page goes live ;-) Gerv
>The first bug on this list is bug 185662 - "In SMTP prefs, make it clear what >"use secure connection (SSL)" really means". It doesn't contain the words >"flash" or "crash" at all. That's actually not a bad example of how the search works, since the point is not to show you bugs that match all your search words but to show you the most relevant bugs based on the prevalence of one or more of your search words. >Perhaps it would be less embarrassing to pick another example before the page >goes live ;-) I don't see why it would be embarrassing, but it makes some sense to pick a sample search that returns relevant bugs near the top of the list, so I've changed this to "flash crash mouse" for "a browser crash when you mouse over a Flash animation." I could swear the original search returned relevant results when I checked this code in many months ago. Perhaps the data changes rapidly enough that we'll have to revisit this sample query regularly.
Yeah, that was my main issue with the full text stuff. I jujst want us all to agree not to preserve teh identical behavious in the future, when we get something better :)
I noticed when untwisting the Bugzilla chart data the other day that there's an anomaly in it where the machine got set to the wrong date. Looking at the charting data on mecha/bzupgrade/, it's possible that there are still some anomalies in it of this type. Would it be possible to cast an eye over it pre-migration, and remove or correct the date on any spurious values? Gerv
this was done. :)
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.