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 > > docs. > > > > 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 > media (see > https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/thread/XDRUNGFVA36IP6IMBHYWFTQYZYDXKSZW/). > 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. Necro time! 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 don't already). 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 fedoraproject.org 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 though. 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. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx
