Closed Bug 176570 Opened 22 years ago Closed 22 years ago

upgrade b.m.o with new version of Bugzilla

Categories

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

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: myk, Assigned: myk)

References

Details

(Whiteboard: current ETA: Friday, November 8, 6:00pm PST) 

b.m.o should be upgraded with a new version of Bugzilla that includes the
Request Tracker enhancement and other enhancements/bug fixes.
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: current ETA: Friday, November 8, 6:00pm PDT
Adding a number of bugs which I think could do with being fixed. These are a
mixture of perf bugs, regression fixes and very useful tweaks.

Feel free to disagree with my selection :-)

Gerv
Depends on: 127200, 170464, 173571, 173573, 174298, 176599
Depends on: rt-clean-up
These all look worthy, although some aren't blockers for the release.  I'll
leave them on the list for now but drop them if they don't get resolved in time.

Note: to nominate a bug to block this upgrade, post a comment in this bug about
it; don't add bugs to the blockers list.  I'll read the comments and add the
bugs as needed.  This way I can distinguish between nominated and accepted bugs.
No longer depends on: 170464
I nominate bug 85600 - Target Milestones are misordered in the "Search for bugs"
query page, making target milestones very hard to select.
nominating bug 83245 "Preference to disable duplicate e-mail notification". It
wastes a lot of bandwidth form Mozilla and spams people's mailboxes.
Theres not much point in nominating bugs which don't have patches attached, and
aren't likely to by the end of the week, unless they're major regression bugs.
The regressions should have the 'regression' keyword on them, anyway.

On that note, bug 175838 definately needs to be fixed, since being able to
reopen bugs is sort of nice....
85600, 83245: worthy, but no patches or activity, and not blockers

175838: major regression; needs to be fixed
Alias: bmo-upgrade
Depends on: 175838
OK... bug 147275 is a pretty important one on the 2.178 track and this is the
right time to land it.  dkl has already tested it out, I have been testing it,
and justdave is trying it on syndicomm.

Waddya think myk?

b.m.o doesn't use product groups, so I don't see how that bug would really
affect it either way.
Myk: b.m.o doesn't use product groups, but it does use security groups, and
among other things, bug 147275 provides the ability to allow anyone to place a
bug into the security group when filing the bug, whether they're in the security
group or not.  This is a feature b.m.o has long sought-after, I believe.

It's per-product, also, so people will only be given the option of
"Security-Sensitive" in Browser, MailNews, etc, and only be given the option of
"Webtools Security-Sensitive" in the Webtools and Bugzilla products, if set up
correctly.
I would be against landing bug 147275 before November 8th. At some point, we
have to _stop_ adding big changes, and stabilise :-) The only part of that patch
that b.m.o. actually needs is implemented by a three-line custom patch I have
prepared in another bug. Given that a checkin that size will inevitably
(nobody's perfect) cause regressions, I don't think it's too bad to make it wait
for a week.

Gerv
WRT comment 10:
  The fact of the matter is that bug 147275 is absolutely critical to the
imminent deployments of 2 major contributing companies (dkl's and my own).  The
argument that a key item like that should rot while BMO makes do with a
site-specific hack is really counter to the whole reason why anyone outside the
browser development contributes at all.
  A number of the new items in 2.17 include some risk of regressions.  Because
we are all working on the same project, we focus on providing a
near-instantaneous turnaround for any regressions that are discovered.  As soon
as we start pushing key developers off onto their own forks, that stops happening.

>  The fact of the matter is that bug 147275 is absolutely critical to the
> imminent deployments of 2 major contributing companies (dkl's and my own).  The
> argument that a key item like that should rot 

I am not saying that it should rot. Stabilisation means just that - no big
changes - and so when we move out of that period in nine days time, you won't
have a merge job to do. 

Dave says in bug 147275 that "it's going to take me an entire day
to test it thoroughly." I am concerned that if the patch is of that order, then
we should not be checking it in a week before we upgrade b.m.o. We have been
bitten before by last-minute checkins which break b.m.o. - and given the number
of people who use it, we can't afford that.

The last time you made major changes to the groups system, you issued a similar
ultimatum: "We need this now, or else we have to fork." In that instance, people
bent over backwards to spend a great deal of time reviewing your patch and
helping it to get in to meet your deadlines. Now, I am suggesting that, during
this short period of time when we are attempting to stabilise the tip for
b.m.o., you exhibit a similar flexibility and consideration. 

> while BMO makes do with a site-specific hack is really counter to the whole 
> reason why anyone outside the browser development contributes at all.

That's overstating it just a bit. Said hack is all that b.m.o. needs. Checking
in the patch in bug 147275 in order to get that feature is using a very large
sledgehammer to crack a very small nut. 

But, when it comes down to it, this call is Myk's. If he's happy for the patch
to go in now, I will stop objecting. If he would like you to wait, I don't think
that this is an unreasonable request.

Gerv

If you read justdave's comment carefully, he indicated that the new flexibility
will take an entire day to test.  The fact of the matter is that the potential
regression issue is much narrower.  A site that converts and leaves the settings
in the converted form and continues to let the automatic generation of product
and non-product groups relies on a much narrower set of this.

Also, I would not interpret my statement that you are forcing dkl and me to sit
on  forks as an ultimatum.  That is where we are today.  I am asking the team to
make a point of keeping it possible for us to get off these forks in a timely
fashion.

Actually, here's the ticket....

Rather than saying that all development should stop because BMO is moving to the
tip, BMO's stabilization will happen on a branch just like any other release
branch, right?

Sometime ahead of Nov 8, (I think I recall myk mentioning Nov 1) a branch should
go off as the BMO_2_17_branch.  Then, the changes on that branch can be ONLY
those wanted for BMO and the rest of the development can proceed.

It seems reasonable not to land huge patches prior to that branch peeling off
(Nov 1).  It is not reasonable to turn the tip into that specialized, albeit
important, branch.


joel: We're not making a stable release, jsut a snapshot. Your patch is rather
large, and tthere is potential for it to break stuff. If it gets in before we
freeze, thats great, but otehrwise one more week won't matter.

We shouldn't have a branch, since we'd just be backporting everything then.
Well, myk said he wanted to pull the snapshot a few days ahead, so let's open up
the tree at that point.  I presume there will be a tag where the snapshot was
taken so that the option of controlling a branch remains in case it is needed later.

Note that we don't seem to be talking about a week, we are talking about
something already in effect, so let's get BMO happy and unlock the tree with
minimal disruption.

Assuming that bugfixes should be tracked under this as well, I nominate bug
177435 and bug 177436.  (myk?)

I don't recall ever having said I wanted a snapshot.  What I want is for the
tree to freeze for a week before b.m.o upgrades and the developer's release is
cut.  I'm not completely opposed to this getting in before the freeze, but I'm
certainly opposed to it landing afterwards, and I'm pretty concerned about its
potential for regressions.

>Assuming that bugfixes should be tracked under this as well, I nominate bug
>177435 and bug 177436.  (myk?)

Yeah, those are important.  Added.
Depends on: 177435, 177436
Depends on: bz-replication
Depends on: 174942
We need to make report.cgi use the shadow database for performance reasons.

Also, two bugs which I added in those bugs instead of here, and which you may
not know about for that reason:

bug 174942: patch viewer for diffing patches against the repository or each other
bug 124589: MySQL replication to replace buggy home-grown shadowdb synchronization
Depends on: 178019
Adding low-risk, high-value bug 62729 to the list.
Depends on: 62729
Adding performance bug 114696.  There's a full plate already, and I'll remove it
later if it looks like we can't get it in, but it seems like something that
could make a really big difference for b.m.o, so I'll do what I can to take it.
Depends on: 114696
Adding bug 156548, which is ready to go, low risk, and high-benefit.
Depends on: 156548
reminder for myk: before the upgrade, you need to mail people in the various
groups, letting them know that to to search for closed bugs, instead of
searching on 'groupset' 'is' 2, people need to use 'group' 'is' 'foo', where foo
is a name you have to tell us :)

This is due to the groups change, where groups are no longer represented as bitsets.
Adding bustage and warning bugs.
Depends on: 178772, 178776
Time to make hard decisions and remove the following bugs from the list of blockers:

bug 114696 - isn't ready and doesn't appear to provide any performance gain for
MySQL-based bugzillas

bug 124589 - complicated and should really be shepherded by its author, who is
unavailable until after the upgrade

bug 174942 - haven't found time to review it, but I'm going to stage it on b.m.o
after the upgrade for testing, feedback, and use

Bugs that remain (and need either patches or reviews) include:

bug 171475 Flag UI is confusing.
bug 171480 Request queue output for non requestee-specific request is ugly.
bug 171505 Disabled flags should still be visible in the UI.
bug 172518 make request tracker use generic user matching code.
bug 173917 Empty request does not produce an error message..
bug 174731 Spurious flags are set by default.
bug 173573 Sort important products to top of list on query page.
bug 174298 Sort important products to the top and box them in on enter bug page.
bug 176599 Improve performance of duplicates.cgi.
bug 178772 doeditparams.cgi failed with malformed headers.
bug 178776 warning in duplicates report.
No longer depends on: 114696, bz-replication, 174942
Whiteboard: current ETA: Friday, November 8, 6:00pm PDT → current ETA: Friday, November 8, 6:00pm PST
Upgrading Bugzilla depends on bug 178782 (upgrading Perl modules on that
machine) being fixed.
Depends on: 178782
Bug 178794 (a one-character fix to a table name) needs to go in.  The patch is
ready and extremely clear-cut and safe.

Adding bustage bug 178794.
Depends on: 178794
Adding bustage bugs: bug 178800, which is a taint error, and bug 178801 which is
a syntax error that causes a server error.
Depends on: 178800, 178801
Any chance of getting bug 158353 in with the rest of the changes?
There are a number of bugs whose patches are specific to b.m.o., and which may
(or may not, depending on Myk) get applied directly to b.m.o. after or during
the upgrade. That is one of those. Others include bug 129366 and bug 158726.

Gerv
More bugs Myk might like to take:

bug 170464 Make it possible to select all OSes from Guided bug entry format
           (requested by b.m.o. contributors who use those OSes; important if we
            switch to that format by default)
bug 71794  processmail shouldn't bother checking deps unless state changes  
           (I suspect that this could be a big perf win)
bug 116819 Attach and Reassign in one fell swoop 
           (This should be a process improvement, resulting in more correctly-
            assigned bugs)
bug 178436 imagemaps "coords" in wrong order 
           (regression, or long-standing bug; affects Moz but not IE)

The top three need review, the bottom one also needs a patch.

Gerv
Depends on: 178828
No longer depends on: 178828
Sorry, ignore any emails about a completely irrelivant bug, Kinda entered the
wrong bug number in the blocks field without checking
Bug 178841 needs to block this.


I think bug 178960 should block this one.
bug 158353 - yes, will do in conjunction with the upgrade
bug 129366 - yes, will do in conjunction with the upgrade
bug 158726 - no; page.cgi comes with the upgrade, and there's no patch on the
bug, and it's not our worst problem, but I'll reconsider if a patch appears
bug 170464 - no.  i'd like to get this in, but it's lower priority than other stuff
bug 71794 - yes, great fix
bug 116819 - no.  it's a great enhancement, and i want it, but i don't think
there's time
bug 178436 - no.  dependency graphs don't even work on b.m.o at the moment, and
almost no one ever complains, so this isn't a priority
bug 178841 - yes; security hole
bug 178960 - no; trivial; but also fixed
Depends on: 71794, 129366, StopMorons!, 178841
Bug 164003 Button "Add another boolean chart" appears twice after clicking "And"

This is highly confusing, and the fix is simple. Needs review.

Gerv
Adding bug 164003 - low-risk UI fix
Depends on: 164003
Adding bug 114696, a significant performance boost.
Depends on: 114696
The upgrade is done.  Remaining issues are being mopped up in bug 179176.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
No longer depends on: 129366, rt-clean-up, 173573
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.