186190 - bugzilla.mozilla.org upgrade meta-bug

Status: RESOLVED FIXED

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

Description

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 1

[Gervase Markham [:gerv]]

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

Comment 2

[Gervase Markham [:gerv]]

Also:

Bug 129366 - Allow unprivileged users to file bugs into Mozilla security groups

Gerv

Comment 3

[Myk Melez [:myk] [@mykmelez]]

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

Comment 4

[Joel Peshkin]

Unless it goes away, 
Bug 188161 "I don't have permissions to edit a bug even I'm assigned to it" 

Comment 5

[Joel Peshkin]

And can't you do what 129366 does just by setting permissions in 2.17.3 ???

Comment 6

[Gervase Markham [:gerv]]

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

Comment 7

[Bradley Baetz (:bbaetz)]

IS this still up for next week?

Comment 8

[Myk Melez [:myk] [@mykmelez]]

It could be, if we can get some fixes in by then.

Comment 9

[Bradley Baetz (:bbaetz)]

Hmm, this didn't happen, obviously.

Comment 10

[Dave Miller [:justdave]]

clearing the ETA - it's obviously wrong :)

Comment 11

[Dave Miller [:justdave]]

This will be happening sometime after the server move.

Comment 12

[Dave Miller [:justdave]]

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).

Comment 13

[Gervase Markham [:gerv]]

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

Comment 14

[Christian Reis]

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.

Comment 15

[Dave Miller [:justdave]]

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.

Comment 16

[Bradley Baetz (:bbaetz)]

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.

Comment 17

[Dave Miller [:justdave]]

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?

Comment 18

[Joel Peshkin]

The "Edit group controls" page shows bug counts, but there is no "confirm" page.

Comment 19

[Dave Miller [:justdave]]

ah, that's right, we have bug counts on that screen, so we'll know before we
click anyway :)

Comment 20

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 21

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 22

[Myk Melez [:myk] [@mykmelez]]

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).

Comment 23

[Dave Miller [:justdave]]

You mean January 19. :)

/me grumbles about copy/pasting it to the mailing list and not catching that

Comment 24

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 25

[Gervase Markham [:gerv]]

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

Comment 26

[Myk Melez [:myk] [@mykmelez]]

>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.

Comment 27

[Bradley Baetz (:bbaetz)]

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 :)

Comment 28

[Gervase Markham [:gerv]]

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 

Comment 29

[Dave Miller [:justdave]]

this was done. :)