Attempt at more detailed changelogs for desktop snapshots

For the upcoming desktop snapshot, we are trying out a more detailed changelog than we usually do. I looked through the internal changelogs since the previous snapshot, and tried to include as many changes as possible, and I have included the bug ID whenever possible.

One problem with this is "information overload", so we will have to figure out a way to organize it properly, and highlight things that may be important to most people, or that we want more focus on for that build.

Another problem is that the raw changelogs contain a lot of sensitive information, things that aren't even relevant to public builds, and so on. It takes some time to weed out these things.

But if this works out, we may be able to get a better process in place for more detailed changelogs in future snapshots.

Advertisements

23 thoughts on “Attempt at more detailed changelogs for desktop snapshots

  1. Originally posted by haavard:

    One problem with this is "information overload"

    Perhaps it would be information overload for my mom or dad but the majority of people frequenting the desktopteam blog are not normal people. Most of the inviduals seem to be rather capable and technical people. Perhaps you have not seen all the people (including myself) complaining about the one-wayness of the communication between Opera and ourselves? I think you would find yourself hard pressed to information overload those dedicated to the testing process. I actually double dog dare you to information overload us! I bet you can't do it!

  2. Great! If the work for changelog in progress, the build must be (almost) ready. Can't wait!!!

  3. Putting together the changelog is an on-going process because there are new changes all the time. It will be worked on until the snapshot build is actually ready (at which point work on the changelog for the next snapshot starts).

  4. @fearphage "the majority of people frequenting the desktopteam blog are not normal people"Right :)Doesn't mean they are capable of sifting the (for them) useful information from a large pile, which is why it will be a challenge for Haavard to present it in a useful way. Think of all the people who don't even read the warnings and complain about known issues in the comments :)BTW, I'm sure the bug numbers that will get included will often be not the ones you know about. When things move to the Core project, they get a new number, many reported bugs are duplicates where the report that gets fixed is one that was reported internally earlier, etc. But given his sources and the format Haavard is working on, it is just as easy to leave those numbers in anyway.

  5. :up:You can use a standard list style.Most prominent changes put on top of the list and make them bold. If some changes are dangerous color them in red also.

  6. Originally posted by Rijk:

    Think of all the people who don't even read the warnings and complain about known issues in the comments

    Based on the number of unique users I see in the blog comments, the number of people who don't/can't read are negligible. Don't (always) penalize the intelligent to aid the ignorant. And because you will probably ask/think it: Yes, i consider withholding information a penalty.Keep in mind that I greatly appreciate what you are doing and the strides you are making. However I have an end goal that the lazy/ignorant people are now impeding which is an unfortunate roadblock.

  7. Mark G writes:

    The more info the better. BUG ID references are good, because as a submitter, I can see when you have fixed it, and confirm the fix is good.Looking forward to a new 10. alpha and lots of info to read 🙂

  8. :hat: Can't wait! I can handle the overload, I mean we're using snapshot builds that should only be used by those who know what they are doing on a computer anyway. ;)Thanks for the update!

  9. Nice to hear, Haavard…and it doesn't sound trivial.As many have mentioned already, info overload needn't be a concern. Some of us crave more details, so we can better focus useful feedback for you. :)To simplify it, I may suggest you consider organizing the changelog by component or maybe by user sophistication (i.e., intermediate technical, advanced technical, developer). All the v10-alpha testers like to focus on their favorite parts of Opera or browser components, I think, so this may let them realize and test the changes they appreciate most, etc…Keep up the good work! :up:

  10. @kamaleshI agree with sophistication levels for organizing data, but honestly…I love Trillian Astra's method of posting the changelog. They always post it as an attached text file that doesn't waste space and has all the information needed.I feel like that would be the best of both worlds, because there is no need to organize since those who care to check can glance through what they wish, but those who could care less can ignore the changelog link!Example:http://blog.ceruleanstudios.com/?p=434http://blog.ceruleanstudios.com/wp-content/uploads/2009/04/cl-04-21-2009.txt

  11. Builds are not usually released on Fridays, but an exception can be made for builds that are not pushed through auto-update.

  12. Thanks Haavard for the more detailed changelogs with the recent Opera snapshots. They definitely give everyone better knowledge of what has been fixed with each snapshot and to possibly spot any regressions.A suggested improvement would be to update the Known Issues with some of the common/broad problems found and reported in the comments. This would at least provide some small interaction between the Desktop Team and testing users. And maybe someone on the Desktop Team could add a short comment to notify that a reported problem has been added to the Known Issues.

Comments are closed.