docs August 2020

docs@lists.fedoraproject.org

5 participants
3 discussions

Updating docs for Btrfs by default
by Chris Murphy 05 Sep '20

05 Sep '20

Hi, This doc is in need of updating for the Btrfs by default feature approved for Fedora 33: https://docs.fedoraproject.org/en-US/fedora/f32/install-guide/install/Insta… https://fedoraproject.org/wiki/Changes/BtrfsByDefault I can fork https://pagure.io/fedora-docs/install-guide and submit PR's. But I don't think that method is interactive, i.e. it's pretty much accept the PR or reject it, correct? Any other ideas? I've identified these specific areas: - Automatic partitioning - should say Btrfs instead of LVM https://docs.fedoraproject.org/en-US/fedora/f32/install-guide/install/Insta… - Some partition types - notably the /boot and /usr directories and the BIOS Boot and EFI partitions - can not be placed on Btrfs subvolumes. Use standard physical volumes for them (or an LVM logical volume for /usr). See Installing_Using_Anaconda.adoc#sect-installation-gui-manual-partitioning-recommended for more information. - Ext4 is the default and recommended file system used by Fedora Workstation and Cloud. - Advice on Partitions - Recommended Partitioning Scheme (recommendations, sizes all need updates) https://docs.fedoraproject.org/en-US/fedora/f32/install-guide/install/Insta… - Manual partitioning should say Btrfs instead of LVM https://docs.fedoraproject.org/en-US/fedora/f32/install-guide/install/Insta… - Silverblue https://docs.fedoraproject.org/en-US/fedora-silverblue/installation/ https://docs.fedoraproject.org/en-US/fedora-silverblue/technical-informatio… - swap - based on your system parameters - unrelated to btrfs, but needs updating for swaponzram feature https://fedoraproject.org/wiki/Changes/SwapOnZRAM Original list and discussion appears here: https://pagure.io/fedora-workstation/issue/158#comment-672898 Thanks, -- Chris Murphy

3 5

Major changes to Documentation Contributor's Guide needs review
by Justin W. Flory (he/him) 29 Aug '20

29 Aug '20

Hi Docs Team, I am requesting review on two new Pull Requests to the documentation-contributors-guide repo: https://pagure.io/fedora-docs/documentation-contributors-guide/pull-request… https://pagure.io/fedora-docs/documentation-contributors-guide/pull-request… #18 adds a new module explaining AsciiDoc in a uniquely Fedora context. I listed some outside resources on asciidoctor.org for writing in AsciiDoc, listed some frequent AsciiDoc xref snippets with some examples in a Fedora context, and also added an explainer for how to do reusable attributes. Is it perfect? No. But it is a lot better than what we had, and I think it will help a lot of new writers with Fedora Docs, because this docs repo is easier to find in the docs.fp.o repo from other Docs Team repos. https://docs.fedoraproject.org/en-US/mindshare/ #19 is related to something that happened recently. It is a new page that explains how front-end developers and UX designers can participate with or improve the Fedora Docs UI. For now, there is little content in the "For designers:" sub-menu in the nav, but it is my hope in starting one now, it will be easier to iterate on when Real Designers™ (a.k.a. not me) want to contribute. :) I am excited about both, but #18 especially. It would be great to see these get published to help new Fedora Docs writers. It would be great if someone could review starting Monday, 31 August. Thanks all. Have a nice weekend! -- Cheers, Justin W. Flory (he/him) https://jwf.io TZ=America/New_York

1 0

Using branch names instead of branched yaml files for building docs.fp.o?
by Ben Cotton 24 Aug '20

24 Aug '20

Hi docs team, mattdm recently suggested we should rename the default branch of council-docs from "master" to something else[1]. I suggested "prod" because I have ulterior motives. Right now, we have separate branches for building the production and staging docs.fp.o. This makes staging useful for testing changes to the build system itself, but not for content. Granted, people can (and should) test content changes locally before pushing, but for changes that span across repos or for sharing rendered changes with someone else for review, that becomes more challenging. Would it be possible to configure things such that docs.stg.fp.o build from the repos' 'stg' branches and the main docs sites build from the 'prod' branches? This way, every docs repo that gets included by Antora can have stage and production content for "free". Then, for example, if I made a big structural change to the Council docs, I could do that on the stage branch so that it would be built and visible to anyone I wanted to share it with, but the production content would be untouched until we were ready to merge. Would it be as simple as changing line 6 on site.yml to be 'prod' on the prod branch and 'stg' on the stage branch? (Or better, could we pull it from some environment variable/file/whatever?) Assuming this is both technically possible and also desirable, would it be possible to have the production docs site support both "master" and "prod" as branch names to provide a migration window. Or would we have to migrate to this model by updating the site.yml on a per-repo basis? [1] https://pagure.io/Fedora-Council/council-docs/issue/86 [2] https://pagure.io/fedora-docs/docs-fp-o/blob/prod/f/site.yml#_6 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs August 2020