1014701 - Release notes for Firefox 29.0.1 list "Various Security Fixes" but no advisories assigned to 29.0.1.

Status: RESOLVED WONTFIX

(www.mozilla.org :: Pages & Content, defect)

Description

[u498376]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

Steps to reproduce:

1. Goto http://www.mozilla.org/en-US/firefox/29.0.1/releasenotes/
2. Scroll to bottom of the What’s New section
3. Notice the Various security fixes item
4. Click on the link for security fixes
5. Notice no section for 29.0.1, and all items for 29 are the same as when 29.0.0 was released
6. Search bugzilla and found no security issues publicly listed for 29.0.1



Actual results:

Firefox 29.0.1 states it has security fixes since 29.0.0 however none can be found listed for it.


Expected results:

If there are security issues addressed in 29.0.1 since 29.0.0 then they should be listed on the Security Advisories for Firefox page else if there are no security issues addressed in 29.0.1 since 29.0.0 then the 29.0.1 release notes should be updated to have the "Various Security Fixes" item removed from it.

Comment 1

[Tyler Downer [He/Him]]

In the notes, only the items that say Fixed and 29.0.1 are what has changed in 29.0.1, everything else changed in 29.0.1

Comment 2

[Tyler Downer [He/Him]]

everything else changed in 29.0* sorry, typed too fast

Comment 3

[u498376]

Release notes need to be accurate for the specific version listed, they should not include anything a previous version already listed in their release. So there may be other errors in the 29.0.1 release notes if other items on it are copied mistakenly from 29.0.0 RTM.

Comment 4

[u498376]

For clarity the URL specifically shows version as does the page's date information

So nothing from http://www.mozilla.org/en-US/firefox/29.0/releasenotes/ should be duplicated on http://www.mozilla.org/en-US/firefox/29.0.1/releasenotes/

Comment 5

[Kohei Yoshino]

I also have thought such a duplication is confusing...

Comment 6

[Tyler Downer [He/Him]]

I believe the reason for this is our updating process. We only update about 20million users to the release at first. Then we evaluate feedback to see if we need a dot release. If we don't, all is good and we give 100% of users the release. If we do need a dot release, then we deploy that release to the users that have already updated and those that haven't. Giving those updating from say, 29.0 the 29.0.1 notes would be fine, but those users updating for any other version, getting the 29.0.1 notes only would be a sub-par experience. So we just combine all notes for the release into one page so all users who update can see all the changes in that release.

Comment 7

[u498376]

@Tyler That is not how release typically work. Release notes are only the changes/notes applicable to the exact version mentioned. 

So if someone wants to see what was in 29.0 they look at those notes, if they want to see what is in 29.0.1 they look in those notes. You are calling 29.0.1 a security release when it wasn't. So in ENTERPRISES like mind and many others you are forcing us to deploy 29.0.1 because you said he has security updates. When in fact there were no security updates for it since 29.0 which we already deployed when it came out. However under our IT requirements and for other companies we are now forced to release 29.0.1 due to your release notes calling it a security release and our requirements require we deploy all security releases within a specific time period of their release. Non-security releases do not need to be deployed unless a fix or feature we require is in it.

So your release notes are not ENTERPRISE friendly, and are not following how just about every release notes I ever read on any platform are managed.  

If you want to make sure people who jump right from 27.0 to 29.0.1 know more then add a link stating that this is a cumulative update that includes all changes from 29.0 and provide a link to 29.0.

Comment 8

[u498376]

@tyler, ment ...not how release notes typically work...

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Tyler is correct, when we release 29.0.1 that is the first update to 29 for 90% of our users on previous versions.  The notes for a dot release (in the manner which we do them) is to have the notes from the main version with top-of-the-fold notes that are specific to the drivers of the dot release.  In this case 29.0.1 was not a security-driven release so the "various security fixes" are part of the 29.0 main notes.

Regarding comment 7, Firefox is not an enterprise product and is not developed to support enterprise deployments.  If that is desired, we do have https://www.mozilla.org/firefox/organizations/

Comment 10

[u498376]

I didn't say Tyler wasn't correct in why you guys do what you do. I am only saying its not the best way to do it.

You claim not to support enterprises how enterprises still use your products, and we are bring valid complaints to ways you do things. You can ignore them or not. For the record we have bother Firefox rapid release and ESR in our enterprise and we have issues with ESR one of which is being addressed in another bug.

The changes being requested are not unreasonable. If you want to list changes from previous versions that are by default brought forward and included in this specific version I am not saying not to, I am only asking that you then separate them and label them accordingly and accurately, or to provide a link to the other release notes for the additional items. Again none of this is unreasonable, none of this should be difficult to do. So I am not sure why there is some resistance to this request.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

What I'm trying to say is that, while this might be a way to do release notes it is not our current model and this bug is not going to be fixed.  We are working on getting release notes information into an RSS feed that can be more easily consumed (and if that helps enterprise deployments, that is wonderful), but we're not currently prioritizing a revamp of how we structure the release notes and the current method does distinguish what is new to the dot release version so your request in comment 10 is already met.

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

I've filed bug 1015425 to track these requests (and other ideas) for a revamp of notes, once resources are available to look into this further.

Comment 13

[Robert Kaiser]

FWIW, http://www.mozilla.org/security/known-vulnerabilities/firefox.html has a detailed list of all security advisories fixed in different versions (29.0.1 doesn't show up because it didn't fix any security issues over 29).

Comment 14

[u498376]

@Robert I am aware of the security advisories, as my STRs show going there, and that is the reason for the bug is that your release notes clear state there are security issues for 29.0.1 and your security advisories page does not list any.

@Lukas thanks for create another bug to track the request of as an enhancement as it is a serious issue with inaccuracies in your release notes and felt like it was being kicked to the side like it didn't matter because it does matter. Thanks.

Comment 15

[Robert Kaiser]

(In reply to Rodney Foley from comment #14)
> @Robert I am aware of the security advisories, as my STRs show going there,
> and that is the reason for the bug is that your release notes clear state
> there are security issues for 29.0.1 and your security advisories page does
> not list any.

So the only actual issue is that it's not labeled clearly enough that the release notes are for 29.* and not just 29.0.1?

Comment 16

[u498376]

@robert, yes as stated in comment #10 it is that it is not labeled clearly. 

To try to make it more clear as it may not have been in that commen. 

If you want to include them included them and separate/label them based on the version the note was released in.  That would be running release notes for a major version which is common. You could have a 29.0.1 section/label for its changes and then a 29.0.0 section/label for the changes made in that version. This would provide clear separation of what was released in what version with in the major version release history. That would solve this issue. It may even be easier to implement in your current process, based on comments in this thread, since all the data is still there just sectioned or labeled accurately.