Closed Bug 186190 Opened 17 years ago Closed 16 years ago

bugzilla.mozilla.org upgrade meta-bug

Categories

(mozilla.org Graveyard :: Server Operations, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: myk, Assigned: myk)

References

()

Details

(Whiteboard: scheduled for noon PST (GMT-08:00) Sunday, January 25, 2004)

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
Status: NEW → ASSIGNED
Depends on: 129366, 186994
Whiteboard: [ETA: Friday, February 7, 6:00PM PST (UTC-08:00)]
Alias: bmo-upgrade
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
Depends on: 174942, 180642
No longer depends on: 186994
Whiteboard: [ETA: Friday, February 7, 6:00PM PST (UTC-08:00)] → [ETA: Friday, April 11, 6:00PM PST (UTC-08:00)]
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.
Blocks: 201717
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
Blocks: 203019
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
Alias: bmo-upgrade
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.