b.m.o should be upgraded with a new version of Bugzilla that includes the Request Tracker enhancement and other enhancements/bug fixes.

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

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.

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

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.

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

Adding low-risk, high-value bug 62729 to the list.

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.

Adding bug 156548, which is ready to go, low risk, and high-benefit.

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.

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.

Upgrading Bugzilla depends on bug 178782 (upgrading Perl modules on that machine) being fixed.

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.

Adding bustage bugs: bug 178800, which is a taint error, and bug 178801 which is a syntax error that causes a server error.

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

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

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

Adding bug 114696, a significant performance boost.

The upgrade is done. Remaining issues are being mopped up in bug 179176.