Closed Bug 1042526 Opened 10 years ago Closed 10 years ago

Thunderbird31 release notes almost empty, full bugs list shows TB24 bugs, and wrong support page linked up :(

Categories

(www.mozilla.org Graveyard :: Thunderbird, defect)

Product:
www.mozilla.org Graveyard
Component:
Thunderbird
Version:
Production
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: pascalc, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Proposed set of Thunderbird 31 release notes
46.69 KB, application/pdf
Details
JSPWiki source markup for the PDF (one minor formatting correction made)
4.28 KB, text/plain
Details 
https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/?uri=/thunderbird/releasenotes/&locale=fr&version=31.0&os=Linux&buildid=20140721092545

I upgraded from 24 to 31 a few minutes ago and notices various changes that are not listed in the release notes:
- The compose window has visual changes (fields and icons have changed)
- Web feeds now fetch the favicon of the site

There is also one potential regression, I haven't been able to connect to irc.mozilla.org from Thunderbird.
Version: 17 → 31
OS: Linux → All
Hardware: x86_64 → All
Summary: Release notes almost empty → Thunderbird31 release notes almost empty
The root cause of this is that release notes are being prepared from the relnote keyword, but that keyword is rarely used. It is not practical to sort through 2000 landings each year to determine release notes. Need for relnote needs to be part of the patch review process.
Well, even bugs which did have relnote set don't show up in the current relnotes (e.g., bug 1009585). SeaMonkey manages to prepare decent relnotes having even less resources than Thunderbird, a recent example can be admired in http://www.seamonkey-project.org/releases/seamonkey2.26/ .

The current TB 31.0 relnotes with just three bullet points listed and otherwise a huge (unsorted) list of bugs (including build-system and test fixes, which may not have contributed to the application code at all) are indeed a bit embarrassing.
URL: https://www.mozilla.org/en-US/thunder...
I reduced Magnus' nice query [1] to 344 bugs [2], *skimmed* the bug list, and I come up with these possbilities for release notes. I leave it to others to give a thumbs up or down. I don't present this as a definitive complete list.

https://bugzilla.mozilla.org/show_bug.cgi?id=302748
302748 – HTML+plain-text (multipart) email message with wrong encoding does not upgrade to UTF-8 properly
https://bugzilla.mozilla.org/show_bug.cgi?id=897476
897476 – Hook up web console, style editor and profiler
https://bugzilla.mozilla.org/show_bug.cgi?id=950133
950133 – Re-enable hardware acceleration
https://bugzilla.mozilla.org/show_bug.cgi?id=963731
963731 – Fix small OS X composer issues
https://bugzilla.mozilla.org/show_bug.cgi?id=964364
964364 – Restyle the Quick filter bar
https://bugzilla.mozilla.org/show_bug.cgi?id=964066
964066 – Restyle the Quick filter bar
https://bugzilla.mozilla.org/show_bug.cgi?id=296952
296952 – Improve Phishing Detector to recognize host names of the same domain
https://bugzilla.mozilla.org/show_bug.cgi?id=984978
984978 – Adjust TB's theme for Windows 8 and up
https://bugzilla.mozilla.org/show_bug.cgi?id=768516
768516 – Thunderbird tabs in the title bar on OS X
https://bugzilla.mozilla.org/show_bug.cgi?id=528044
528044 – Global search: "Show/Open as list" results view does not remember columns (should persist column visiblity, e.g. for "location") [faceted search; search all messages]
https://bugzilla.mozilla.org/show_bug.cgi?id=570787
570787 – Global Search: "Open email as list" Results should show location column by default [containing folder, faceted search, Search all messages]
https://bugzilla.mozilla.org/show_bug.cgi?id=457296
457296 – Implement separate whitelist for addresses/domains allowed to load remote images for email
https://bugzilla.mozilla.org/show_bug.cgi?id=960672
960672 – Windows - Update Composer UI
https://bugzilla.mozilla.org/show_bug.cgi?id=601263
601263 – Add options for Thunderbird Mac dock icon.
https://bugzilla.mozilla.org/show_bug.cgi?id=978592
978592 – "Favorite Folders" view shouldn't sort in a hierarchy?


[1] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIXED%20milestone%3A%22Thunderbird%2025%22%2C%22Thunderbird%2026%22%2C%22Thunderbird%2027%22%2C%22Thunderbird%2028%22%2C%22Thunderbird%2029%22%2C%22Thunderbird%2030%22%2C%22Thunderbird%2031%22%20OR%20cf_status_thunderbird_31%3Afixed%20OR%20cf_status_thunderbird_31%3Averified%20AND%20-cf_status_thunderbird_esr24%3Afixed%20AND%20-cf_status_thunderbird_esr24%3Averified%20

[2] https://bugzilla.mozilla.org/buglist.cgi?o5=substring&list_id=10809790&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=enhancement&o9=substring&v10=verified&f13=OP&o2=substring&f23=short_desc&v5=Thunderbird%2028&o15=notsubstring&f12=CP&v9=fixed&v24=build&o4=substring&f14=OP&o20=notsubstring&f24=component&v2=Thunderbird%2025&f21=CP&v4=Thunderbird%2027&f10=cf_status_thunderbird_31&f19=OP&v15=fixed&f22=CP&f1=OP&o7=substring&v6=Thunderbird%2029&o3=substring&f20=cf_status_thunderbird_esr24&f8=target_milestone&f0=OP&j19=OR&v3=Thunderbird%2026&o24=nowordssubstr&f18=OP&f15=cf_status_thunderbird_esr24&resolution=FIXED&j14=OR&o6=substring&f9=cf_status_thunderbird_31&v7=Thunderbird%2030&v20=verified&f4=target_milestone&o23=nowordssubstr&o10=substring&query_format=advanced&v23=crash%20test%20assert%20intermit&j1=OR&f3=target_milestone&f2=target_milestone&f11=CP&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f5=target_milestone&f17=CP&v8=Thunderbird%2031&f6=target_milestone&f7=target_milestone&o8=substring&f16=CP
This looks like a good start. The following bugs have the "relnote" keyword set and were fixed or filed (if not fixed yet) within the 25.0-31.0 time frame (no query as I've just skimmed to the list of relnoted bugs for Thunderbird and MailNews Core):

Fixed:
Bug 533775 (Thunderbird) Order of Local folders and Newsgroups is wrong in favorites view
Bug 558931 (Thunderbird) Composition's recipient autocomplete does not / fails to show all matching address book entries
Bug 586131 (Thunderbird) Quickfilter bar has lost OR functionality using | (Pipe character)

Pending:
Bug 1008855 (MailNews Core) Authentication via NTLM fails in TB30 beta, did work in TB29 beta bc. NTLM v1 is disabled by default on 30
Bug 1009585 (MailNews Core) Ignoring preference mailnews.reply_header_authorwrote;
How about this one? (change in the Advanced preference pane and backend):
Bug 892255 - Remove "Revocation Lists" button from Advanced > Certificates options

Should all front-end UI changes be listed with user-facing preferences added/modified/removed?

And then there are Core changes like this one, hitting TB 31.0 users now:
Bug 861266 - Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default
Bug 711475 - Allow updates to be applied by limited user accounts into high integrity locations
Imo perhaps not all, but many bugs/RFEs currently having [tb31features] in whiteboard [1] should be included.

E.g. this one, which helps a lot to make a good impression by never again forgetting to add those attachments...

Improved: Attachment Reminder is now available and controllable from menu at any time, reliably warns before sending, independent of attachment count, and the reminder status is preserved in saved drafts and templates (Bug 521158).

...and these:

New: The context menu of global search results now has a command to "Open message in containing folder" (Bug 686851)

New: Embedded images are now automatically scaled down to fit the width of your window; click on them to magnify (Bug 534083).

[1] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20%3Athun%2Cmailn%20white%3Atb31feature&list_id=10815430
Wow, I can't believe after all the work which has gone into TB 31 the release notes come out completely f***** up and useless like this:

1) Only 3 bugs listed for a full release after one year of developing - ridiculous!!! And so many important UI improvements which really make a difference not mentioned, big or small.
2) Top bug isn't described well and lacks reference to the other equally important bug (they are complementary twins, but the missing one is the more important one which could subsume the other)
3) Full bugs list referenced from release notes points shows the old list of TB24 bugs - I don't believe this, omg, shame!!!
4) Per bug 1044043, we even wrongly link users to a dead support site, getsatisfaction
5) After we fix this, will there be anything like a press statement or other form of advertising the new version, at least on Mozilla sites??

Can't be worse I think... again - this is ridiculous and unworthy of Thunderbird.

If I had access to these documents, I would fix them myself, but unfortunately I don't and nobody even asked me to look over them in advance.

Please somebody fix this!!!
Severity: normal → blocker
Summary: Thunderbird31 release notes almost empty → Thunderbird31 release notes almost empty, full bugs list shows TB24 bugs, and wrong support page linked up :(
(In reply to Thomas D. from comment #9)
> Wow, I can't believe after all the work which has gone into TB 31 the
> release notes come out completely f***** up and useless like this:

I understand your excitement but your comment adds nothing to our understanding of the issues, which are already well documented.  The notes didn't happen the way they should have. But it's summer and it happened, we've talked about it in status meeting, there are people workign on it and we can move on.


> Severity: normal → blocker

really - by no definition does this meet the standard of "blocker". This doesn't block development work, nor at this point does it block a release, since we're past it.
Severity: blocker → normal
I think an important core change in TB31 for OS X users is Bug 852648. As you can see in the comments from Bug 728385, which was (finally) fixed by Bug 852648.
For Windows users everyday stuff:
Fixed - Bug 414865 - Attachment will lose file extension when renamed in "Save as" dialogue and "hide extension for known file types" is set (default for Windows Explorer)
By the way, what is about "Known issues", for example Bug 933302?
Depends on: 1044043
Depends on: 1042240
(In reply to Nomis101 from comment #13)
> By the way, what is about "Known issues", for example Bug 933302?

Nomis, normally yes, but from an informed perspective, "Known issues" would be a bottomless pit, there's thousands of them of varying severity. Where to start and where to stop?

Bug 933302 (on MAC OS, with high screen resolutions in magnified modes, no visual indication when dragging messages) is bad and user-facing indeed, and even comes with a poor workaround (using low resolution for TB), but why out of all bugs would it qualify to be explicitly mentioned? It only affects MAC OS users (minority), it only affects message-dragging users (no statistics, but probably not a majority either), and it's not even a TB bug; it's in Core, affecting FF as well...

The problem about mentioning just a few "known issue" bugs is creating the impression of a somewhat comprehensive set of the worst bugs we know of, which will not be true. Imo it's better to just point to our bug database, which is transparent and very comprehensive. It's just a shame that due to Mozilla's unfortunate defunding of the project, relevant chunks of paid manpower to address these issues effectively have been lost (and even before that, the manpower was too little compared to the task). But in spite of limited manpower, the community of volunteers has done an amazing job for TB31 to fix lots of bugs and improve Thunderbird with a number of tangible results for the end user - only unfortunately per this bug, so far we've failed to communicate that progress appropriately and timely upon release of TB31, which looks like a major and costly PR failure to me.  More so in view of the above-mentioned delicate handover of responsibilities, hence my indignation at the fact.
http://www.heise.de/newsticker/meldung/Mail-Client-Thunderbird-31-korrigiert-zahlreiche-Fehler-2265768.html

To somewhat prove my point, have a look at this German review from Heise: They can only advertise what we offer them, so they first dwell on those 3 things on the current release notes including deactivation of insecure NTLMv1-Authentication (wth?)...
With the truthful yet benevolent approach they took (even smart enough to link to the full list of fixed bugs for tb31beta and thus title "Mail client Thunderbird 31 fixes lots of problems"), really trying hard to present even the smallest improvement to our advantage, imagine how much better this review could have been with a more reasonable list of user-facing changes, including e.g. the following:

- Improved: Composition's revolutionary incremental *multi-word* search in recipient autocomplete (Bug 558931 *and* Bug 529584)
- New:      Composition's recipient area now autocompletes newsgroup names (Bug 61491)
- Improved: Composition's completely revamped Attachment Reminder feature: Attachment Reminder is now available and controllable from menu at any time, reliably alerts before sending, independent of attachment count, and the reminder status is preserved in saved drafts and templates (Bug 521158).
- New:      Composition's automatical attachment reminder now also triggers for attachment keywords in subject (Bug 944643)
- New:      Composition's new and efficient inline find bar (Ctrl+F) provides streamlined search experience known from Firefox Browser (Bug 530629)
- Improved: Composition's added print preview and optional print button (Bug 251953, Bug 318955)
- Improved: Address book: Search results in contacts side bar and address book's advanced search now allow easy contact management with DEL keyboard shortcut (Bug 343973, Bug 749564)
- New:      Message management: Quick Filter Bar now allows OR searches using "|" (another filter revolution but unfortunately it's lacking documentation...)
- New:      Message management: Messages viewed as list in threaded conversation tabs ("Open in conversation" and the "Open email as list" flavor of global search results) now offer to "Open message in containing folder" from their context menus, allowing users to go back from search results to the original context of the message (Bug 686851) [...and yes, we didn't get to all corners, so the trick e.g. doesn't work on single messages viewed in their own tab yet...]
- Improved: Message management: For certain applicable folder views like "Favorite Folders", user can now choose between "flat" and "hierarchical" folder view (View > Folders > ...; Bug ###? aceman? The hierarchical view is new I think)
- Improved: Message reader: Embedded images in HTML-formatted messages are now conveniently scaled to fit the available viewing width, click to show in original size (Bug 534083)
- Improved: Message reader: Preview of attached images now considers exif orientation (Bug 877520)
- Improved: Show favicon next to RSS/Atom feeds (Bug 745301; and yes, we are a feed reader, too! :))
- and a few more new features/improvements which should go into this list, e.g. the polished design of composition's recipient area, filter stuff (aceman?), etc.

So that already makes a much more healthy and impressive list for TB31 Release Notes...

Above list is more focused on TB31features (improved/new UX), we should add some important bug fixes too:
- security fixes
- UX/feature fixes
The link is still entirely misleading:
https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/buglist.html
Still lists bugs for v.24. That's disturbing.
Sorry for not being able to get to this earlier. As I'm sure I've commented elsewhere the release notes are in svn and available for creating diffs against, the branch we normally work against is staging:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/branches/staging/

If anyone wants to do a patch, that would be most welcome. Note that whilst the list in comment 15 is impressive, it really needs to be the highlights, in a reasonable sized list, that's easy to understand. Some of the Firefox release notes are good for examples.
Component: General → Thunderbird
Product: Thunderbird → www.mozilla.org
Version: 31 → Production
(In reply to Mark Banner (:standard8) from comment #18)
> Sorry for not being able to get to this earlier. As I'm sure I've commented
> elsewhere the release notes are in svn and available for creating diffs
> against, the branch we normally work against is staging:
> 
> http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/branches/staging/
> 
> If anyone wants to do a patch, that would be most welcome. Note that whilst
> the list in comment 15 is impressive, it really needs to be the highlights,
> in a reasonable sized list, that's easy to understand. Some of the Firefox
> release notes are good for examples.

Dave, can you take on making a patch?  
And if not, then draft the proposed list of bugs to highlight and text for end-user consumption, and then someone else can turn into the patch
Flags: needinfo?(dave.koelmeyer)
Depends on: 1053951
Hi Wayne, I wouldn't know where to begin on creating a patch per se, but the latter is certainly doable, so yes.
Flags: needinfo?(dave.koelmeyer)
Hi Folks, getting this underway now – give me a couple of days to have a draft for public consumption good to go.
Also, if someone wishes to PM me privately with the *precise* steps to follow to create a patch (take it from the very top please – I am not a developer), then going forward I'll be happy to include creating the necessary patches for release notes and such.
PDF attached for a proposed set of release notes, composed while keeping in mind Mark's comments in Comment #18, and using the Firefox 31 release notes as a baseline.
Hi Dave,

Thanks for the effort here.

I don't know if you got any response to "if someone wishes to PM me privately with the *precise* steps to follow to create a patch" (which is one reason why asking for this privately might not be the best idea). Doing a little digging myself, a comment in the release notes source leads to this link for instructions:

https://wiki.mozilla.org/Thunderbird/Release_Driving/Rapid_Release_Activities/Release_and_Beta_Copy

What that has you do, AFAICT, is to download a python tool from Standard8's hg repo that is used to generate the HTML for the buglist. That tool will generate the way-too-long list of comment 15 and would need to be reduced to a manageable size.

It really does not make sense for us to reinvent a process here when Standard8 apparently has methods to do this. I think that we should wait for him to return, and then learn from him how to use the tools that are used to generate the patch.
No, python stuff is for the complete list only, so it's not required for the reduced release notes featuring more significant improvements. It's just manual editing of the HTML file. Adding the new HTML file here as attachment would suffice, then someone create a diff or whatever it takes.

 Update the Release Notes page (releasenotes/index.html)

    Edit en-US/thunderbird/<release>/releasenotes/index.html
    Update the variables in the php header
    Update the what's new section
    Update the known issues section (use relnote bugs link on branch tracking page, and add as necessary)
    Check the rest of the text
    Commit the changes
    Check the changes on the staging site
Thanks Thomas D., I decided to reveal my ignorance to try to move this forward. I think you are correct.

So looking further, I think that the file we need to change is here:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/branches/staging/thunderbird/en-US/thunderbird/31.0/releasenotes/index.html?view=co&content-type=text%2Fplain

And the goal is to expand the list that currently has items like the following, with a more complete list:

      <li>
        <span class="tag tag-new">NEW</span>
        <h5>Autocompleting email addresses now matches against any part of the name or email (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=529584">bug 529584</a>)</h5>
      </li>

Is that correct? Is that done by just manually editing the file?
(In reply to Kent James (:rkent) from comment #28)
 
> Is that correct? Is that done by just manually editing the file?

Yes and that's why mark asked for a patch :-)

The file is then commited to trunk and from there to other branches. One branch is the production one and is picked up by the mozilla servers every 1/2 hour to update the content.
I don't know if this svn branch/tree is accessible without an account.
I think I have access to this svn tree if needed for a commit. 

Also, please note that this is part of the very old mozilla.org framework which was later superseded by mozilla.com framework (on svn and in PHP) and 3 years ago was replaced by a new framework called bedrock (Django-based framework). Most of the content was migrated over the years to bedrock and Thunderbird pages are still on the old framework. IMO, It would be good to migrate these pages (one by one) to the current mozilla.org framework and workflow on github where all the webdevs are active so as to benefit from the work done on the site (better maintenance, responsive mode, newer templates, possibility to localize key content more easily and get the tasks in our localizers dashboards, security...).

This is probably something that our volunteers community could help with (and I can occasionnally give a hand).
I have commit access, I'm willing to review and push patches (or files!), but I don't always have the time to do the extensive work.

The migration mentioned in comment 31 is already in progress and is being driven by the webdev team. I don't have timescales yet, but once its up and running, I'll let folks know.
As I was in the release notes area today, I've taken Dave's changes and updated the notes in r131557 and r131558.

https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
FTR:

TB31 release notes are still failing big time, as part of the PR desaster where imho we really failed to sell TB31 in a way that matches the actual great work and progress seen in the product.

https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/

Perhaps someone can explain this to me:
A product whose biggest danger to survival is the wrong public perception that "it's no longer maintained and updated", publishes in their master "release notes" documentation [1] a so-called "complete list of changes" which claims that only 60 bugs/RFEs [2] have been fixed, but in reality, the number of bugs/RFEs fixed for this release was 513 [3] (almost 9 times as many as in the published list). I don't know what you'd call this, but I'd call that a PR desaster, and one which TB at this particular time, out of all applications, cannot afford.

I don't understand how such can happen - we need to implements checks/procedures/written instructions to avoid that in the future.

Please somebody fix this asap! I will reopen bug Bug 1042240 for that unless somebody wants to file a new bug.

I have given up on the short and friendly bug list of the release notes [1] but suffice to say it still falls short in many respects, wording, content, ranking/order, and labelling. E.g., things described as "Improvement" are nevertheless labelled "New" as if they represent new features (there might be edge cases, but "Improved" has always been a useful category of its own...). Trivial theme improvements are labelled as "Fixed" as if they were bugs before. The net result is that on the friendly list, it looks as if the only important bugs we have fixed are indeed 2 cosmetic improvements and 1 feature enhancement. I know we can't list all bugs, but the chosen few should at least be BUGS (not cosmetics or RFEs), and relevant bugs for that matter, and we should list some MORE FIXED BUGS in proportion to the "NEW" and other categories (to avoid creating the impression that we have renovated the entire program but fixed only 2 or 3 bugs which aren't even bugs... it's really the other way round...).

[1] https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/

[2] 60 bugs found: So-called "complete list of changes" as linked on current version of [1]:
https://bugzilla.mozilla.org/buglist.cgi?classification=Client%20Software&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&target_milestone=Thunderbird%2031.0&product=Thunderbird&resolution=FIXED&list_id=11706671

[3] 513 bugs found: The real "complete list of changes", known since Comment 3:
https://bugzilla.mozilla.org/buglist.cgi?bug_status=CLOSED&bug_status=VERIFIED&bug_status=RESOLVED&field0-0-0=target_milestone&field0-0-1=target_milestone&field0-0-2=target_milestone&field0-0-3=target_milestone&field0-0-4=target_milestone&field0-0-5=target_milestone&field0-0-6=target_milestone&field0-0-7=cf_status_thunderbird_31&field0-0-8=cf_status_thunderbird_31&field1-0-0=cf_status_thunderbird_esr24&field2-0-0=cf_status_thunderbird_esr24&list_id=11706727&query_format=advanced&resolution=FIXED&type0-0-0=substring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0-0-4=substring&type0-0-5=substring&type0-0-6=substring&type0-0-7=substring&type0-0-8=substring&type1-0-0=notsubstring&type2-0-0=notsubstring&value0-0-0=Thunderbird%2025&value0-0-1=Thunderbird%2026&value0-0-2=Thunderbird%2027&value0-0-3=Thunderbird%2028&value0-0-4=Thunderbird%2029&value0-0-5=Thunderbird%2030&value0-0-6=Thunderbird%2031&value0-0-7=fixed&value0-0-8=verified&value1-0-0=fixed&value2-0-0=verified&order=bug_id%20DESC&limit=0
Depends on: 1109611
Thomas, I really do not appreciate your tone, nor your attitude. Having started reading your message, I almost ignored it due to the whining and miss-aimed judgement of people.

In future, I suggest asking rather than assuming and complaining.

I also doubt that there's large amount of folks (especially press) looking at the 31.0 release notes now - 31 was several months ago, and they aren't going to be worried about changes.



As to the real issue:

- We've just had our release notes migrated from svn to "Bedrock".
- I took a look back at the last version in svn:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/branches/staging/thunderbird/en-US/thunderbird/31.0/releasenotes/index.html?revision=131558&view=markup

- This does not have the query that is now on the 31.0 release notes.

Hence, I suspect something has happened in the migration. Looking at the new tool for the release notes, there's no query in there. Hence, this is either some form of default query, or something that happened during the migration.

Not easy to pick up when you're doing spot checks.


I've just updated the query on the page to the suggestion that you've given, and that is now live.
(In reply to Mark Banner (:standard8) from comment #35)
> Thomas, I really do not appreciate your tone, nor your attitude. Having
> started reading your message, I almost ignored it due to the whining and
> miss-aimed judgement of people.

Mark, first of all, thanks for fixing the bug described in my comment 35 (bug so rapidly, which is great, and yes, at the end of the day it doesn't really matter if it was you or someone else who introduced or overlooked this flaw (and I'm not suggesting you did, because I don't fully know).

I'm not sure how my comment could contain miss-aimed judgement of *people* because I don't even mention a single name, unless "TB 31 release notes" is now a person. So the only explicit criticism of people might be this:

> [the PR desaster where] *imho* we really failed to sell TB31 in a way that matches the actual great
> work and progress seen in the product.

That's clearly marked as my personal opinion concerning what I believe to be the failure of a collective "we" (obviously including myself) to advertise the progress and qualities of Thunderbird the product appropriately (also notice the praise of "great work and progress"!). The fresh trigger (but not the only reason) for this pointed statement is the fact that after we first served the world with the Bug List of TB 24 acting as Bug List of TB 31, some months down the line there's a live document again which still has the wrong set of bugs, listing only 60 out of 513 bugs we have actually fixed. Regardless of the actual reasons, I really believe we should avoid such miscommunications given the fact that TB is obviously facing an image problem of being wrongly regarded as "dead" after Mozilla withdrew most financial support and manpower.

For more reasons on why I think the release of TB31 was a bad failure *in terms of PR* (failing to appropriately sell the good progress made, so that new and existing users can know and benefit), feel free to contact me.

> In future, I suggest asking rather than assuming and complaining.

I'm not sure where I was "assuming", but I'll admit the migration obviously wasn't on my radar, so I'll stand happily corrected IF there was no human fault involved (while the "systemic fault" would still stand). I "complained" about a real bug which I saw on the release notes until you fixed it some hours ago.

As a long-standing QA and UX member of TB Core Team (official branding from TB summit), I've spent countless volunteer manhours of painstaking, constructive and cooperative work on TB, so I believe I'm entitled to complain now and then where I think things are going wrong. I think everybody including yourself knows that what you call my "complaining" is always paired with a factual description of real issues and suggestions/pointers on the way forward. In this case, I provided the new link (extracted from existing comment), which you have already implemented. - Sorry for venting a bit on the way, no personal offence meant, but without at least occasional complaints about some of the many unbelievable issues and frustrations around TB, I would find it very hard to continue dedicating myself to the project. I've also noticed that clear and sometimes pointed descriptions of issues have often triggered new activity on neglected bugs which has ultimately improved the product. I believe it's well known and on record that whatever I say is always in pursuit of the ultimate goal, to improve TB... 

> I also doubt that there's large amount of folks (especially press) looking
> at the 31.0 release notes now - 31 was several months ago, and they aren't
> going to be worried about changes.

Now that's where *I* get really irritated, but let me ask to avoid getting blamed for "assuming":
Are you suggesting that because the release is over, it doesn't matter so much that the one and only page publicly listing the full progress made between TB 24 and TB 31 fails to list almost 90% of that progress?
Can we foretell which or how many important press people or administrators of big companies might want to re-check on our release notes at any time to assess how we are doing, or if they should continue using TB?
Sorry, but personally, I would avoid speculating about that and much prefer ensuring that at least our official release documentation is as correct as possible at all times.

> As to the real issue:
> [...]
> Hence, I suspect something has happened in the migration. Looking at the new
> tool for the release notes, there's no query in there. Hence, this is either
> some form of default query, or something that happened during the migration.
> 
> Not easy to pick up when you're doing spot checks.

If it's not easy to pick up, we should establish people, or procedures, or documentation that ensure we will get it right next time without disseminating wrong information first. If there's a migration, somebody needs to check and ensure the correctness of resulting documents.

> I've just updated the query on the page to the suggestion that you've given,
> and that is now live.

Thank you, that's much appreciated. Problem solved, because I reported it and you fixed it. Which I think could be regarded as a case of successful cooperation in the best interest of TB the product.
As the person who donated time to take on boiling down the screeds of possible release note bugs and fixes into a customer-facing summary (which involves more effort than I think you might appreciate), it's unclear to me why you're bringing this up over three months after the fact. The correct time to do this would have been at comment 23.
Product: www.mozilla.org → www.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: