I've opened a PR against comps.xml to drop the release notes from the @standard comps group: https://pagure.io/fedora-comps/pull-request/182

Discussed at 2017-10-26 Fedora 27 Final go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-10-26/f27-final-and-server-beta-go-no-go-meeting.2017-10-26-17.00.html . Accepted as a release blocker as a violation of the cited criterion.

Some more here: we actually discussed changing the criterion again on test@ in June - https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/GWBCZC7WKPCZBC5YDOMDEEDVGGXHYHHB/

We broadly agreed to something like Matthew Miller's proposal:

"If branded or generic release notes exist in the release repository, they must up-to-date for the current version. If they are shipped on media, they must match."

i.e. we don't strictly require the release notes to be part of the release *at all*, but if they are included in the repos or in release-blocking media, they must be up to date notes for the correct release.

On that basis, this is accepted as a regular blocker and *not* a zero-day blocker, because at present, some release-blocking media include fedora-release-notes-25.01-3.fc27 , which obviously is not correct for Fedora 27.

Acceptable resolutions here would include:

* Removing the release notes package entirely from the media and repositories
* Removing the release notes package from all release-blocking media (which must happen before the RC compose), updating the package in the repositories (which could happen between RC compose and release, i.e. as a 0DayBlocker)
* Keeping the package on media, updating it before the RC compose

IIRC, in F26 we actually included docs packages that were just a file that pointed to docs.fedoraproject.org.  I'd like to see this considered to be an acceptable solution here.

I think I'd consider that acceptable under the revised criteria (either the current or the proposed further revision), so long as we were sure the pointed-to URL would be valid and contain appropriate content on release day.

(In reply to Adam Williamson from comment #4)
> I think I'd consider that acceptable under the revised criteria (either the
> current or the proposed further revision), so long as we were sure the
> pointed-to URL would be valid and contain appropriate content on release day.

Do you need docs to own building the package or do we just provide you with a durable URL?

In practice at present you own building the package; you're the maintainers, and its 'source' is your Pagure project.

See project admins here: https://src.fedoraproject.org/rpms/fedora-release-notes

Honestly, at this point, I suggest we go for 

* Removing the release notes package entirely from the media and repositories

Looks like it's in the "standard" comps group. This PR would remove that:

https://pagure.io/fedora-comps/pull-request/182

and a quick repoquery suggests that nothing requires it. Let's get that PR approved for comps, and then retire the package.

Brian said he was aiming to get a package build done today. I don't really mind which path we go for (well, I actually have a mild preference for keeping the release notes in the distribution, but not to the point that I want to delay releases for it), but we need to do *something* today in order to do an RC compose.

Well, neither Brian nor Pete seems to be around to do a package build, so we're going with Matt's plan. I have merged the PR and run 'fedpkg retire' on the f27 branch of the package. Let's consider that as putting this bug in ON_QA state, and we can run a compose and verify that it doesn't include any release notes.

Adam, I didn't realize this was a "right now" problem as opposed to something that could be solved in the next day.

I worked today with Igor and we (mostly he) was able to get a package built.  The current spec is correctly loaded here:

https://src.fedoraproject.org/rpms/fedora-release-notes

The package contains both an actual copy of the Release Notes that are completed as of this moment and links to the docs site for updates and other information.

Can we please consider unretiring this package and using this newly built one?  Now that we have this, we should be able to produce updates as the Release Notes change.  The content is produced via the new documentation build system, which has been a blocker in the past.

See: https://pagure.io/releng/issue/7122

Also, I need to get commit rights to the package as a maintainer so I can help keep this updated for the future. I'll make that request assuming this package is going to be unretired.

fedora-release-notes-27.01-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f1d9edde16

"Can we please consider unretiring this package and using this newly built one?"

At this point, we could only get it into the media by slipping the release. I expect we can probably unretire the package and get it back in as a post-release update, if we don't do that.

fedora-release-notes-27.01-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f1d9edde16

Correction: the first attempt to build an RC compose failed. mboddu reverted the comps change and pulled the package into the second attempt, which is running now. So it should be included in that.

Verified that the appropriate package is in the RC-1.2 compose, and its contents seem correct.

fedora-release-notes-27.01-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.