Release blues

I'm getting used to this. I've even learnt to expect it and prepare myself mentally. It's still true: releasing something is the most depressing job for somebody doing quality assurance.

So we finally have a new flagship desktop version. The long-awaited Opera 9.5 launched with – I hope – all the hype and thunder we could drum up. Literally thousands of bug fixes since the 9.2x versions, a fancy new skin, new features like getters and setters and Dragonfly that will make much of my work much easier – and yet I can think of few other things than the REMAINING bugs that we should have fixed. It's QA release blues time. Happened every time since Opera 6 final or so.

And with a new release comes new problems. The worst current compatibility issue is a problem with the TinyMCE editor, where legacy versions of TinyMCE will re-arrange your sentences in somewhat unpredictable ways when you press enter. (This is caused by TinyMCE detecting Opera to work around a bug in earlier Opera versions – we've now fixed the bug and unfortunately their workaround still runs and messes things up). To put this problem into the right perspective, TinyMCE is the default editor for WordPress, and all admin screens in the millions of WordPress installations out there are now suddenly broken in Opera. Ouch, Sir. What a gotcha!

This is fortunately precisely the sort of things we have browser.js for. There is a fix in already, needs some more tweaking to run in WordPress' admin screen but I'll get that done. So thank God and Lars Erik for browser.js – when I can throw some fixes in after the final launch, release blues isn't quite as bad as it used to be :).

I'm crossing my fingers that the patch will eventually be robust enough to work with most legacy TinyMCE installations out there. Wish me luck – or even better, tell me where it fails ;-o

Advertisements

21 thoughts on “Release blues

  1. Cheer up Hallvord, the bugs will get worked out. 🙂 Go outside and enjoy the outdoors. It is good to get away from computers now and again. I for one am glad for the improved JavaScript and CSS support. Although I really wish that some of the features removed in the UI could be reenabled… Anyway some sites do not work when Opera 9.50 is released. Be happy that you were not a member of the IE7 team :cheers:.

  2. I like Opera 9.5 very very much. It's more stable than ever before, fast and reliable. New releases always bring up new problems, so don't worry too much. This version of Opera is by far the best ever released so far. The whole team did a fine job. :up:

  3. releasing something is the most depressing job for somebody doing quality assurance

    After working in QA for many years, i would have to disagree. I was always proud of the work I had done and the quality of the product that I was testing and putting my stamp on. I think the internal structure of the company may be the issue here. In the places I've worked, things aren't released into final/stable until QA has "signed off" on it. It means they are comfortable with the bugs that are left and they have ran all the regression testing and whatever testing they need. Although the whole process is timeline-driven, QA is virtually the final say on whether something makes it into the end users hands. That's how it has been in my QA experiences. Quality Assurance tells the higher-ups that the build is ready to go public.

  4. 😎 I know that every time I release a X.0 of something, inevitably there will be a X.1 following very soon afterwards! It's just the way things go. :whistle: This time, part of it has to be the fact that it's been so long since the previous official release of Opera, which has allowed plenty of time for stacks of new features and bug fixes to go in. And new bugs! People don't notice all the new stuff that works, but boy do they notice all the things that go wrong! A more frequent release schedule with fewer things going wrong at each step might be better?Edit: Ooops, hit send too soon. I did, of course, want to congratulate the entire Opera dev and QA teams for all the work they've put into this release. I've considered for a while now that a modern web browser must be one of the most complicated pieces of software around, and the thought of working on one scares me silly! :p

  5. Originally posted by Andrew Gregory:

    A more frequent release schedule with fewer things going wrong at each step might be better

    A very good idea indeed. We moved to this paradigm as not to bury QA in stacks of things to test. Smaller releases make a smaller surface area for QA to check. Not a bad idea at all.

  6. d.i.z on the forums has pointed out that the tinymce patch is currently looking for exactly a minor version of zero when the major version is 3. That should be changed to looking for a minor version starting with zero, hmmmm? Drop the second single quote?:

    e.element.text.match(/minorVersion:'0/)
  7. After working in QA for many years, i would have to disagree. I was always proud of the work I had done and the quality of the product that I was testing

    Fearphage, good for you 🙂 Perhaps your software did not have to render several billion web pages though?I'm using internal versions all the time and am quite aware of the ebb and flow of fixes and regressions – at some point the advantages of getting 9.5 out to the masses will outweigh the known bugs and the regressions we might introduce by fixing them might be worse than the issues we have… That the new version is a great improvement over the old is the most important reason for releasing it. I think that was the case with 9.5, though tomorrow's version is always better..Andrew: thanks, I'll get a fix for that out tomorrow.

  8. Originally posted by hallvors:

    Perhaps your software did not have to render several billion web pages though?

    It most certainly did not. Keep in mind that we didn't release bug-free software. one major sore spot for me with this release is that Opera is announcing Dragonfly to the world for public consumption… oh yea, and its the source of a crasher. That was quite unfortunate. I understand releasing with crashers but it seems bad form for them to be linked to your most celebrated features. Just my opinion.Originally posted by hallvors:

    That the new version is a great improvement over the old is the most important reason for releasing it.

    This was true 6 months ago as well. 9.5 brought a lot improvements over 9.27. I agree 100%. Kestrel didn't just not get way better than Merlin. Please understand that I am not attempting to put down the quality of the desktop team and other staff. On the contrary, I would like you (us) to succeed but it disappoints me when things like this release happen. This release is not something I can put in front of people to wow them which is what I wanted. I hate being embarrassed of/by something that I love.Originally posted by hallvors:

    at some point the advantages of getting 9.5 out to the masses will outweigh the known bugs and the regressions we might introduce by fixing them might be worse than the issues we have

    Could you or someone talk about why Opera is so regression-prone? I use lots of unstable/beta/nightly-build software but none of it as chaotic/volatile as Opera in its cycle. From one week to the next, almost anything can be broken. And seemingly, people don't have to work on it for it to be fixed and the broken thing does not have to be related. Like a mail fix and break some javascript functionality. I have a theory that too many people are checking in to one branch. I'm pretty sure you can't talk about this but I'll continue on my tangent. I know kestrel is on a branch but I would assume that other branch off for fixes so you can decide when code changes go in. So while someone is fixing mail they don't stomp someone elses javascript fix that is not the focus for the release. I'm talking about the stable-trunk/always-branch development policy. So every fix and every feature would live in its own branch (not literally 1 branch per fix but basically not making fixes on trunk). This allows you to decide precisely when a fix goes in as well as keep trunk as stable as possible. So only when fixes are fully tested do they go back to trunk. Just my two cents…

  9. TinyMCE will re-arrange your sentences in somewhat unpredictable ways when you press enter

    I experienced that on odnoklassniki.ru (Russian most popular site for classmates).I hope they will manage to upgrade to newest version of TinyMCE or it needs UserJS path from Opera.

  10. Could you or someone talk about why Opera is so regression-prone? I use lots of unstable/beta/nightly-build software but none of it as chaotic/volatile as Opera in its cycle. From one week to the next, almost anything can be broken.

    I generally disagree that we have so many apparently random regressions (but then I may have a somewhat clearer view of what is being worked on and what is going in so maybe I'm biased 😉 ).However, a major part of the problem is that there is no clear line between doing QA on Opera itself and QA on the web. Opera QA has to do both. A lot of volatility – from my point of view – comes from issues appearing on important sites and applications and the teams scrambling to try to resolve them. So QA is trying to handle not one, but TWO moving targets: browser code an the web itself. There are branches and checkin rules and procedures – we have excellent and improving regression test suites – yet all too often we need that new risky fix in or we'll break Some Very Important Site. :awww: The solution is of course to create a CVS branch for The Web, check in everything on WWW and revert the web to last week's version if that one is more stable in Opera 💡 In the longer term more detailed specs, more regression tests, shared testsuites and better alignment between major browsers should stabilize things more. At least software developers are inherently optimistic and always consider the future an improvement 🙂

  11. Originally posted by hallvors:

    I generally disagree that we have so many apparently random regressions (but then I may have a somewhat clearer view of what is being worked on and what is going in so maybe I'm biased)

    Must be nice to be you. From the folks outside, it is completely random. Until the dev process becomes less closed, i assume it will remain just as random to us (outsiders).

  12. Go back at some of the builds and look at the guaranteed incomplete changelog and then look at the known issues list… when the issues are added (not merely remaining from the previous release).Here's a recent example:Build before:

    Known issues:Dragonfly does not work when JavaScript is disabled.

    Chaos ensues:

    Known issues:Dragonfly does not work when JavaScript is disabled.All the search icons are Opera iconsTranslate menu doesn't workPanel dropdown selector doesn't workChangelog:Fixed links in the fraud protection dialogFixed crash when saving mhtml filesFixed random crasher when going back in historyFixed moving videos on youtube when hovering tabsMade form submit work properly in widgetsFixed bug where plugins would continue streaming after closing a tabXHR – Fixed calling of calling abort() from readyState 2 or 3 More fixes to xpathFixed viewing of feeds with slow loading imagesFixed problem with duplication of bookmarks when using Opera LinkFixed issue where the integrated Dragonfly window would be too tallAdded three default speed dial entriesWindows: Fixed the default Save and Open dialog foldersUNIX: Fixed import of mail on when using the QT filechooserUNIX: Improved finding of icons for download dialogUNIX: Fixed filename when saving URL's

    Notice how the changes seemingly have no relation to what got broken. This ofcourse excludes "Dragonfly does not work when JavaScript is disabled" since this was left over from the week before. This is a very common occurence. Seemingly untouched code (based on incomplete changelog) is broken. I'm sure if we had more information it would seem less random but I don't see that changing in the immediate future. It's always "how'd they break A when they were fixing X, Y, and Z?" to us outsiders.Also, I don't think and didn't mean to suggest that your job is easy.

  13. Surely the wide variety of issues and fixes is related to certainty that there is a wide variety of modules and developers all under way at the same time?

  14. Originally posted by Andrew Gregory:

    Surely the wide variety of issues and fixes is related to certainty that there is a wide variety of modules and developers all under way at the same time

    I'm quite aware that the development is not as narrow as the small portion the desktop team makes public. However, should all those changes be in trunk at the same time? The DTT has obviously answered yes but on this we disagree. Moving from the volatile trunk policy would curb regressions but may have some other pitfalls I'm not aware of.@Hallvors: What are some benefits of the current source policy? If you can answer that, I'd like you to answer from your professional QA position as well as how it benefits me, the external end user.

  15. You may or may not have noticed that all the new and surprising regressions you listed there are UI stuff. UI is really outside of my "scope" – I know more or less what is being worked on (and sometimes can push fixes for the bugs I think are important) in the ECMAScript / DOM / JavaScript / Forms core areas, and peek at layout and network development. Those bits cover a fair bit of Opera's core, and the regressions I worry about are those happening here. To be honest I don't even know what procedures they have for branching and checkins for the desktop UI development.Most of the changes in the changelog is in fact core stuff, was changed and tested by core devs and QA, and did not cause regressions.Instability in UI is probably something you can expect because developing and polishing UI features is a large part of Desktop's work and an important motivation for releasing weekly builds and getting feedback. There is going to be ongoing development, which means that regressions are possibly not caused by bug fixes typically listed in the changelog but from feature work. Weekly builds are supposed to be usable for browsing (to test core stuff etc.) but not expected to be "polished". Hence QA won't stop a weekly build because e.g. the translate menu is broken.Does that clarify some things? I guess what you are saying is that "ongoing work" should be listed in the weekly changelogs, not just "bug fixes", IMO a good point that the Desktop team should consider.

  16. Originally posted by hallvors:

    I guess what you are saying is that "ongoing work" should be listed in the weekly changelogs, not just "bug fixes", IMO a good point that the Desktop team should consider.

    Exactomundo! Perhaps you could nudge some people on the desktop team? :yes: I see your point though. Looking back at the older changelogs most of the regressions are not core stuff.

  17. Opera doesn't follow every standard either. That is one of my major repeated complaints. Opera is known to be "the standards nazi". However, on its page of supported standards very few are in complete accordance. Almost all of them have exceptions to the rules. It is generall 1-2 of 30-50. It is unfortunate that Opera doesn't completely support more of the standards. Also opera has proprietary stuff as well like -o-* css stuff. All browsers have proprietary things… some just more than others… and some more useful than others. Check out safari's proprietary css goodness:css reflectionscss gradientscss image masksIt's not all bad. Just different.</partially_unrelated_rant>TinyMCE (like all javascript) relies on standards when they are available but falls back to conventions and proprietary mechanisms as needed.

  18. Opera doesn't follow every standard either. That is one of my major repeated complaints. Opera is known to be "the standards nazi". However, on its page of supported standards very few are in complete accordance. Almost all of them have exceptions to the rules. It is generall 1-2 of 30-50. It is unfortunate that Opera doesn't completely support more of the standards. Also opera has proprietary stuff as well like -o-* css stuff. All browsers have proprietary things… some just more than others… and some more useful than others. Check out safari's proprietary css goodness:css reflectionscss gradientscss image masksIt's not all bad. Just different.</partially_unrelated_rant>TinyMCE (like all javascript) relies on standards when they are available but falls back to conventions and proprietary mechanisms as needed.

  19. Originally posted by Moxiecode Systems:

    Here are a few pointers for you.1) Make your own test editor (Like the Midas demo that Mozilla has).2) Write up some documentation on what is actually implemented.3) Look at the WHATWG papers for guidelines.4) When all else fails do it like Mozilla/Firefox.

    This post is also interesting (although being outdated by now):http://my.opera.com/hallvors/blog/2006/11/17/being-compatible-with-the-dark-matter-ofmy basic rant is: * textarea was designed just to fill multi-line forms (like address and such);* HTTP POST was designed to send just small portions of text, filled in those forms said;* unless there's no well-defined (and implemented in the browsers core) standards on RTE, Flash (and yes, Java was) may be the way to go;* DOM/JS is a cool thing. but prototype.js/*.aculo.us (and alike) and sites like last.fm (just an example) is the awful, hardly bearable resource hogs;* and finally, to make my rant-list short: A browser ain't a platform (never meant to be)! (I just want fast threaded comments 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s