On Tue, 2017-07-04 at 14:23 +0200, Kamil Paral wrote: > On Fri, Jun 30, 2017 at 8:49 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> > wrote: > > > 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. > > > > So: > > > > "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: https://koji.fedoraproject.org/koji/buildinfo?buildID=924590 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). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
