Le 25 août 2017 04:47:24 UTC+03:00, Brian Exelbierd bex@pobox.com a écrit :

4. put the content of _package/main into

/usr/share/doc/fedora-release-notes/en-US 5. supply .desktop files to launch the index.html

With coordination, I think we would also be able to ship translations (and release it more often, if package is continuous and not one shot).

But do we really need to do a per release package, can't we includes past release content also? Use cases may be when you upgrade two version in once. Or to know since how many releases a feature was added to Fedora.

Btw, using langpack may help to save space, if this is a concern.

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@lists.fedoraproject.org/t...). 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!

On Thu, Nov 2, 2017, at 01:14 AM, Adam Williamson wrote:

On Wed, 2017-11-01 at 14:11 -0700, Adam Williamson wrote:

...

I'm not sure how significant folks think this kind of concern, is though.

A note on this: I just noticed that the F27 release notes don't seem to> work properly without remote scripts, specifically bootstrap loaded from bootstrapcdn.com and jquery loaded from googleapis.com . I'm not> willing to bet much money that these will still be around in 10, 20 or> 30 years. I'd be rather happier if the release-notes package included> all the javascript and CSS it needs in the package, so the release notes are actually readable offline and in the Far Future.

I'll work on this for the next release. Hopefully today as I saw of new content commits. Thank you.

regards,

bex

-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net> http://www.happyassassin.net _______________________________________________ docs mailing list -- docs@lists.fedoraproject.org To unsubscribe send an email to docs-leave@lists.fedoraproject.org

On Thu, Nov 02, 2017 at 11:05:48AM -0400, Matthew Miller wrote:

On Wed, Nov 01, 2017 at 02:11:39PM -0700, Adam Williamson wrote:

...

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

Yeah, I guess this is a pretty compelling argument. On the other hand,

Oh, look: https://www.xkcd.com/1909/