On Fri, 2017-08-25 at 08:59 -0400, Matthew Miller wrote:
On Thu, Aug 24, 2017 at 08:42:17PM -0400, Zach Oglesby wrote:
> Now that we are on the new asciidoc/asciibinder system I was thinking
> about the release notes RPM and the fact that the it was generated by
> publican. Last I check the RPM is still a blocker for releases, and as
> it stands now, we don't have a way to make this with the new source
> My personal preference would be to remove this as a requirement for
> releases, but this needs to be discussed with a larger group of people
> as I don't think we can just say this is not longer a release criteria.
> I am not sure who we need to talk with (FESCo? RelEng?), but before we
> talk to them we need to have a discussion about it here and figure out
> what the docs team would like to see done so that we are talking with
> one voice.
Generally, the release criteria are owned by QA, so the test list would
be the place to take this. We actually had issues with this at the last
minute with the F26 release, and discovered that there was an approved
proposal from 2015 to drop the requirement to have release notes on the
The crition is now "The final branded and generic release notes must be
present in the release repository."
I propose we a) change "in the release repository" to "on the Fedora
Docs website" and b) drop the part about "generic release notes";
since it won't be an RPM, that's not a hardship for remixes.
So yes, the release criteria are owned by QA, but ultimately they're
not written in a vacuum. We don't want to be in the position of
deciding *policy* with the release notes. The flow should rather be
that policies are decided by the appropriate groups, and the release
criteria accurately reflect their decisions. I'd say the "policy" here,
in the past, was "we always want to include the Release Notes in the
media". That's a policy that can change, and if it does, of course the
criterion would be updated appropriately.
In fact the policy already changed, because some media already aren't
built with the @standard package group these days and thus do *not*
include the release notes.
So I'd say we should decide what our new policy really is, then ensure
the release criterion reflects that.
The present state is that the release criterion is OK with release
notes being present or not present, both on media and in the
repository, but requires that if they *are* present, they not be
outdated (i.e. they can't be a leftover package for a previous
release). The wording is "Any release notes included in the release repositories
and/or any release-blocking deliverables must be for the correct release, and approved for
release by the documentation team."
So the question is, what do we actually think is a sensible policy
around this now? The thing that's changed is, obviously, much more
widespread internet connectivity; we can reasonably claim that 'most'
Fedora users don't need the release notes on their media or in the
repositories to read them, they can just go look on the docs site. So
we could argue there's no real need to include the actual release notes
on the media any more; we could maybe just include a standard Firefox
bookmark linking to a release notes landing page, or similar (if we
I have one argument in favour of keeping the actual release notes
together with the distribution itself: future accessibility. In my
experience, the availability of ancillary bits that were *originally*
provided alongside some piece of software in some way is far less
reliable than the availability of the software itself. You can often
find the actual tarball (or whatever) of some random F/OSS release from
2005, or 1995. It's much less likely that you'll find the associated
release announcement (site it was posted on is very likely down), VCS
logs, etc. The case I'm thinking about is when some researcher 30 years
in the future wants to look at Fedora 27, and are interested in how we
described the changes in it. I suspect that they're much more likely to
be able to get a hold of an F27 image, or the entire release tree, than
they are to be able to get a hold of precisely what every
website looked like on the day of F27 release. Maybe
in 30 years Fedora is wound down and docs.fp.o is gone. If the release
notes are in the release itself, our researcher will have them. If they
aren't, maybe they won't...
I'm not sure how significant folks think this kind of concern, is
So anyway, I suggest we decide as a matter of policy - i.e. *intent* -
whether we intend to include release notes in the release in future. I
guess whether the release notes are included on any particular media
should be up to the group responsible for each medium; this is a
precedent we've established by being OK with Workstation not including
them any more.
Once we've decided the intent, we can think about what it makes sense
for the release criteria to say.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net