On Tue, 2017-07-04 at 14:23 +0200, Kamil Paral wrote:
On Fri, Jun 30, 2017 at 8:49 PM, Matthew Miller
> On Fri, Jun 30, 2017 at 02:12:16PM -0400, Matthew Miller wrote:
> > Oh, sorry -- I read too quickly and I'm doing too many things at once.
> > I'd like to consider dropping packaged release notes entirely -- but if
> > we have them, the should be the right version.
> "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."
> Or something like that. Or we could just take the decision to drop
> packaging them entirely and not bother to mention it.
It's not my place to decide whether we want to ship packaged release notes
or not. But I think the world has changed and almost no one now cares about
packaged release notes. The internet is today in your pocket and the notes
are likely to be outdated the day we release them. So if I were to decide
this, I'd be inclined to remove this criterion completely.
Of course, Adam's or Matthew's proposal does no harm, so +1 to any of
those, if you want to go forward with it.
So this just came up in the blocker review meeting, and I realized I
never closed this off with a further change to the criteria :/
So some follow-up thoughts: just removing the criterion entirely leaves
the problem of *including outdated release notes* unaddressed. To put
this in practical terms, as of right now, the F27 repositories and some
F27 media contain release notes for Fedora 25:
This is pretty obviously bad. That's why I want us to encode the
principle that Matt and I basically agreed - "anything that *DOES*
include release notes, has to include up-to-date ones".
Another thought I had, about whether there's any point to including
release notes in the repos/media at all: I think there actually *is*
quite a strong benefit to this. Consider some person in, say, 2050 who
needs, for some reason, to poke around in Fedora 27. I'd suggest it's
more likely they'll be able to find the Fedora 27 release notes if
they're a part of the release itself than if they were only published
on some website. In general, we're quite good at archiving entire
'pieces of software', but we're not necessarily good at archiving the
ephemera that accompany them but aren't *part* of them.
I've had this exact thing happen to me, in fact, when I've needed to
look at old software or old versions of software from the 90s and early
2000s. It's often the case that you can't really see the website that
existed when the software came out, perhaps with a release
announcement. You very likely won't be able to find any kind of SCM
commit log for the software. But whatever documentation was actually
included *in the deliverables of the software itself*, you can read.
Just food for thought, anyway.
For now I think I'll update the criteria with some hybrid of mine and
Matt's proposals, basically in line with Matt's intent (don't hard
require that the release notes be included anywhere, but require that
anywhere they *are* included, they be up to date).
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net