[Needs Testing] Patch for Bug# 243078-Native Theme Rendering

Post by **BenBasson** » October 15th, 2005, 4:24 pm

tongle wrote:Patches landing very late...sound familiar Thumper?

There's been enough mud-slinging about the menu changes, can we all please just let it go?

Thumper · Post by **Thumper** » October 16th, 2005, 4:00 am

tongle wrote:Patches landing very late...sound familiar Thumper?

Not to reignite this, but are you aware that the whole reason for the late landing was that it looked beyond hope that it would be fixed properly in time? It was deliberate. If I'd opened that bug any earlier it would have been rejected.

- Chris

mw22 · Post by **mw22** » October 16th, 2005, 12:25 pm

Thumper wrote:
tongle wrote:Patches landing very late...sound familiar Thumper?

Not to reignite this, but are you aware that the whole reason for the late landing was that it looked beyond hope that it would be fixed properly in time? It was deliberate. If I'd opened that bug any earlier it would have been rejected.

- Chris

No, we weren't aware, and that's part of the problem, perhaps. If this was known beforehand, that a wallpaper patch would be used as an alternative for the native menu rendering bug, maybe twpol/James or another volunteer would give it a try earlier in the cycle, and we wouldn't have this uncomfortable situation (a wallpaper patch on the branch, with an extension that fixes it and a patched trunk build).

Thumper · Post by **Thumper** » October 16th, 2005, 2:31 pm

The bug I opened nearly three months ago contains all of this information. Silver's blog pretty clearly states that 303806 was his motivation for getting it fixed properly. I've whined about this particular issue since I registered on this forum. The only people whose opinions concern me about the timing of my own intervention are drivers.

Silver's patch wasn't even backed out because the intrepid "volunteers" on here did amazing work to identify problems with it (most people here and on Bugzilla were either only marginally useful or outright obstructive in identifying legitimate problems with that particular patch). It was backed out because of concerns raised on the bug relating to the code itself. If nobody on MozillaZine had noticed that bug at all the net result would probably have been quicker resolution of the issues involved.

Assigning blame is going to do nothing other than drive down morale. People shouldn't be at each other's throats for this.

- Chris

mw22 · Post by **mw22** » October 16th, 2005, 4:57 pm

Thumper wrote:Assigning blame is going to do nothing other than drive down morale. People shouldn't be at each other's throats for this.

Agreed.
So I think it would be best that these kind of situations don't happen too often.

Thumper · Post by **Thumper** » October 16th, 2005, 5:32 pm

I can't view your posting history because you chose a two-letter user name, so I'm not sure how to treat this. Do you mean the checking in of code in accordance with standard Mozilla development practices or the public petitioning and attempts by casual forum users to tell contributors what to do?

- Chris

campcove · Post by **campcove** » October 16th, 2005, 6:56 pm

Thumper- You can't have it both ways, you can't want credit for encouraging silver to work on native rendering without also accepting some of the blame for taking actions that made it more likely for the wallpaper patch to be applied. Also, some people (in the long run, time will tell if they outweigh those displeased) are pleased with 303806- if you want any of the credit for pleasing them, you have to accept some of the blame for displeasing the others. That is only fair.

On the other hand, people should recognize that the decision was not made exclusively by you, outside of a process. Because of your relation to the change many assume you have some influence at the top and are directing the ship in some way, which I presume is not true.

And it is true the bugzilla is not the place for debate, but that doesn't mean there shouldn't be some process where feedback can be given when people feel the ship is heading in the wrong direction. Maybe a website with polls on current mozilla issues could be a useful, instead of distracting, way for people to speak up. And maybe a warning could be put in place before posting on bugzilla that advocacy/debate comments are not allowed, along with a process for 1. comments to be posted by default without emailing people, and only sending a flurry of emails if it is actually intended and 2. a way for moderators to delete all non-helpful comments in a bug.

This issue has raised more commotion than any in a long time, and now that the main parts of the final decision have been made, there could be helpful things to be learned by looking back. Is there a way that angering people could have been avoided, by discovering earlier in the release cycle that native rendering was important to meet the goals desired, and encouraging work on it? Once it was too late for that, was there a better way to calm people by clearly explaining who made the decision and how and why it was made, and providing convincing evidence of what percentage of users would be positively and negatively affected? Was there a better way to give both sides a forum to express their feeling without interfering with build threads and bug comments and other discussions of technical details?

And, probably most importantly, is there a way to reform bugzilla to reduce non-technical or debate comments, and reduce the developers unhappy about bugs getting sidetracked?

Elfguy · Post by **Elfguy** » October 17th, 2005, 5:07 am

supergirl260 wrote:it will probly get into the firefox 1.5.1 version though

I won't make any 1.5.x unless work continues on the branch. Unless I'm mistaken, trunk is the code that will only appear in 2.0?

Thumper · Post by **Thumper** » October 17th, 2005, 6:16 am

campcove wrote:if you want any of the credit for pleasing them

If you go look, I haven't added my name to the contributors section of any of the modified CSS. I don't want "credit" for this. I want it fixed properly.

- Chris

mw22 · Post by **mw22** » October 17th, 2005, 7:26 am

Thumper wrote:I can't view your posting history because you chose a two-letter user name, so I'm not sure how to treat this. Do you mean the checking in of code in accordance with standard Mozilla development practices or the public petitioning and attempts by casual forum users to tell contributors what to do?

- Chris

No, I meant the situation where there is a wallpaper patch on the branch and a fully developed patch on the trunk that probably only needs some time to fix the regressions.

Thumper · Post by **Thumper** » October 17th, 2005, 7:45 am

The issues raised on that patch are structural problems, not minor niggles. Convincing yourself that the problem here is drivers not letting it bake isn't productive.

- Chris

mw22 · Post by **mw22** » October 17th, 2005, 7:51 am

Thumper wrote:The issues raised on that patch are structural issues, not minor niggles.

Are you sure? The regressions caused by the patch don't seem that bad, a few of them already have some simple patches.

campcove · Post by **campcove** » October 17th, 2005, 10:02 am

Ok, thanks to Alfred Kayser it has been pointed out that bug 312527 is the bug for the compromise of leaving the decorative stuff changed for Luna, but reducing the spacing in the bookmarks. This makes some classic users happy (like me, my only complaints were the big bookmarks menu and context menu), and is an improvement for some Luna users as well. In an attachment with screenshots in comment 6, Alfred Kayser argues that this change makes Firefox look more like IE under Luna (if you want to argue that isn't true, make your own screenshots that prove it). This is NOT a backout, and like any other bug is NOT the place for argument or any comments other than technical ones or about possible side-effects- if you want to argue for a backout, do it somewhere else. What it is, is a compromise that should make the browser more useful for many people, and harm few. Most people who find the browser hard to read change to a lower resolution screen that makes everything bigger, because they need to for the rest of the programs they use.

Please vote for this, especially if you are one of the Luna users who feel that the menus got too big, or one of the classic users who doesn't care about the decoration but can't tolerate the bigger menus.

In addition to changing the bookmark menu, I believe this bug would also make the context menus smaller making them require less mouse movement to get to faraway items. If not, that point can be raised in another bug.

Remember- no random comments or debate in bugzilla. According to many developers, you are only killing the bugs that you care about by posting in them.

https://bugzilla.mozilla.org/show_bug.cgi?id=312527

Thumper · Post by **Thumper** » October 17th, 2005, 10:35 am

Don't bother voting. Voting never gets things fixed. Advocating that random people vote for bugs is likely to get voting removed from Mozilla's Bugzilla installation altogether at some point.

It's being looked at, it's a trivial change and there's a patch with a guaranteed zero regressions. The best thing to do is cross your fingers.

- Chris

campcove · Post by **campcove** » October 17th, 2005, 11:05 am

Please take your disdain for the will of the people elsewhere, it is not welcome here.