docs June 2015

docs@lists.stg.fedoraproject.org

13 participants
39 discussions

Orphaning FreeIPA guide
by Martin Kosek 11 Aug '16

11 Aug '16

Hello all, FreeIPA project is already for some time without sufficient resources to revive and maintain our former long upstream user guide. We did not find enough manpower either in FreeIPA developer nor our users community, so we decided to stop maintaining it. Detailed justification including links to mail threads in: http://www.freeipa.org/page/Upstream_User_Guide I would like to avoid leaving any loose ends on Fedora Documentation project side, do you have any recommendation for us? I already closed respective Bugzillas and upstream Trac tickets with explanation. Should we also orphan the guide in https://fedoraproject.org/wiki/Docs_Project_meetings#Guides or on any other locations? For starters, I think we should close the "freeipa-guide" component of "Fedora Documentation" as nobody from our team would be responding there. Thanks for any advise. -- Martin Kosek <mkosek(a)redhat.com> Supervisor, Software Engineering - Identity Management Team Red Hat Inc.

5 10

introduction - Ryan
by Ryan Gough 27 May '16

27 May '16

Hi Everyone, I'm looking at getting involved in the project as I have been a long time user of Fedora (e.g. since Core 1) and would like to start contributing. My name is Ryan, I'm from Western Australia (GMT+8). I am an IT technician and have been using linux as a hobby since 2k4 (using RH9). I have also had the opportunity to work with RHEL in my job during a project as well as having worked with a couple of other distros. In my line of work I have often needed to produce documentation to a professional standard and I feel I can contribute this way currently. I believe I should be able to contribute 4 hours a week at this point in time. Regards, Ryan irc: _terminal_ FAS: t3rm1n4l

2 2

[fedora-badges] #259: Fedora Cookbook Contributions
by fedora-badges 28 Feb '16

28 Feb '16

#259: Fedora Cookbook Contributions -------------------------------------+------------------------------------- Reporter: | Owner: immanetize | Status: new Type: | Keywords: New badge idea | Has a description: 0 Priority: | Artwork status: None minor | External requirements: Has a name: | Triaged (triagers only): 0 1 | Concept approved (reviewers only): | 0 | Badge definition status: | Full, needs review | Manually awarded: | 0 | -------------------------------------+------------------------------------- What the badge should be granted for: Contributing "recipes" to the Fedora Cookbook: 1 submission: Cookbook I: Commis - "You had a recipe published in the Fedora Cookbook. Appetizing!" 5 submissions: Cookbook II: Tournant - "You have published 5 recipes in the Fedora Cookbook. Tasty!" 15 submissions: Cookbook III: Grillardin - "You have published 15 recipes in the Fedora Cookbook. Delicious!" 30 submissions: Cookbook IV: Saucier - "You have published 30 recipes in the Fedora Cookbook. Scrumptious!" 50 submissions: Cookbook V: Sous Chef - "You have published 50 recipes in the Fedora Cookbook. Delectable!" 100 submissions: Cookbook VI: Chef de cuisine - "You have published 100 recipes in the Fedora Cookbook. Decadent!" 150 submissions: Cookbook VII: Gourmand - "You have published 150 recipes in the Fedora Cookbook. Beefy!" Badge names borrowed from http://en.wikipedia.org/wiki/Brigade_de_cuisine , suggestions for improvement on names and patter are welcome. Some dining-related artwork would be greatly appreciated. Submissions are reviewed and committed manually, so the badges will have to be manually awarded as well. Anyone in docs-writers should be able to award these badges. -- Ticket URL: <https://fedorahosted.org/fedora-badges/ticket/259> fedora-badges <https://badges.fedoraproject.org> A place to collect and debate badge ideas for the Fedora Badges app

1 10

[Bug 1008149] New: Contraficting info about the need of shared storage for storing guest images to be migrated
by Red Hat Bugzilla 05 Nov '15

05 Nov '15

https://bugzilla.redhat.com/show_bug.cgi?id=1008149 Bug ID: 1008149 Summary: Contraficting info about the need of shared storage for storing guest images to be migrated Product: Fedora Documentation Version: devel Component: virtualization-getting-started-guide Assignee: dayleparker(a)redhat.com Reporter: jrodrigosm(a)yahoo.es QA Contact: docs-qa(a)lists.fedoraproject.org CC: dayleparker(a)redhat.com, docs(a)lists.fedoraproject.org Hi, In the Fedora 19 "Virtualization Getting Started Guide", section 2.2 ("What is migration?"), URL http://docs.fedoraproject.org/en-US/Fedora/19/html/Virtualization_Getting_S… In the paragraph right before the 2.2.1 title, it is stated that "In Fedora 19, shared storage is not necessary for storing guest images to be migrated. With live storage migration [...]". But in the last paragraph of the page, right before the note, it is stated that "Shared, networked storage must be used for storing guest images to be migrated. Without shared storage, migration is not possible." These two statements seem contradictory to me. I just started learning about virtualization, so I am unable to propose an alternative. But I do think some clarification is needed. Thanks, Rodrigo -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=QwkGtwKvp5&a=cc_unsubscribe

1 3

Fedora Docs Workflow and Publishing Improvement Project
by Brian Exelbierd 14 Jul '15

14 Jul '15

I talked with randomuser about strategy moving forward. I have written up our conversation in an interview style. The primary goal is to start some conversation around these topics. Therefore: YOUR HOMEWORK: Send an email back with the questions this raised for you Our ulterior motive is to further inform our presentation at Flock. --- To understand where we are going, we have to know where that is. *What is the goal of the docs group and docs.fedoraproject.org?* The docs group as having two basic, related goals: assisting developers, and assisting users. Our current strategy does a reasonably thorough job of assisting users, but we don't do as well with assisting developers, or new docs contributors, for that matter. There's lots of new crazy code out there, and the large book strategy has a lot of inertia and can feel stifling when it comes to new additions and rapidly changing areas. *How do we fix this?* The high-level solution is to enable developers and experienced users to write about whatever they like to do. We would use a workflow that leverages the Docs Team's greatest strength, experience. People can work with seasoned writers to produce very high-quality work. The biggest problem Docs contributors have is finding something to do, so that workflow should provide a pipeline of requests working through clearly defined steps. a request could be from a user ie https://bugzilla.redhat.com/show_bug.cgi?id=1229560 or from a developer, ie the API reference discussion, or internally generated by the docs team as a need for an upcoming release. The focus of this process should be on the quality of content and the efficacy of addressing a specifically defined topic. Someone shouldn't have to worry too much about markup or tools unless they've specifically opted to work in a markup or with the tools. This goes beyond just telling people, "You can write whatever you want however you want and get help with the publishing." That's not enough. The scope of our books is really too big to facilitate focused topical writing. The cookbook is evidence of that; Randomuser has offered cookbook assistance to many people and few take the bait. The new strategy is to build publishing/site generation tooling that supports varied content. This way contributors can range from independently capable writers, to SMEs looking to share but not learn the specifics of publishing, to requesters, to those wanting to write but needing assistance to get there. Ideally, we reach a point where each specialty group/SIG has a set of articles covering their interests, in a format that they're able to maintain. The only real example of that we have is the Amateur Radio Guide. And this is is basically single-handedly maintained by jjmcd, despite there being many other Fedora contributors doing radio stuff. This isn't ideal, but it is working for today. Rather than try to fix a working process, let's try to get more folks on-board, for example the Astronomy SIG. *How are we going to implement the solution?* Implementation is a challenge. There are two aspects, **Community** and **Tooling**. On the community side, We don't have a well conceived plan (other than sharing and organic growth - which is slow and not guaranteed). This is critical as tools are not valuable if no one uses them. We can't grow our docs if maintenance consumes all of the folks involved. With regards to tooling, we have lots of bright people and lots of ideas around tooling. Tooling is solvable and being worked on. You can contribute to and follow the progress at https://github.com/immanetize/anerist . But beforewarned, it could be be better described. *How do you envision the workflow for a new content change/addition?* The system consists of a bunch of restricted commit repos containing large guides, collections of ReST articles, whatever. When a change is committed to a repo the tooling will see the commit and attempt to generate html from the affected files. If that succeeds, (and hopefully if it passes some validation tests, the strings in Zanata (Internationalization Tool) will be automatically updated to make the work available for translation immediately. The tooling will also extract some metadata from the document (title, subtitle, abstract, categorical information, etc.) and ultimately use that to generate a stage version of the docs site for verification before publication. An individual contribution comes in via a pull request workflow. This could be via a pagure.io solution or via a traditional git clone solution. Pagure.io has the benefit of bringing the fork/edit/PR process into a web-based format perfect for many contributors and for drive-by contributors. The merge starts the process just mentioned. Ideally we can support acls on a per branch and repository basis. This way a SIG, for example, could have control of their specific documentation by merging PRs. Members of the docs-writers group would have global commit capability. The branch structure can resemble many popular open source projects with a master that is clean and release branches for future maintenance. The system is branch-aware, so everything from 'master' goes to a draft area, things in f$n gets labeled as appropriate for f$n. *What are our big blockers today?* 1. Community Outreach and Growth Plan. 2. Website redesign for docs.fedoraproject.org - it is stalled on some decisions around older docs, etc. 3. Publishing is stalled on both design and the need to integrate legacy tools such as publican in a new paradigm with other formats that use other tools. These need to all roll to a common docs listing/Table of Contents.

4 4

F23 Accepted Changes
by Pete Travis 29 Jun '15

29 Jun '15

Fedora developers are busy preparing for the Fedora 23 Release. At this point in the release cycle, major changes are planned using a scheme called a "Change". Changes are either "Self-Contained", where the impact is limited to the proposed packages and coordination with other developers or Fedora teams is minimal, or "System Wide", which affects a number of interrelated packages and requires coordination from other teams such as QA or release engineering. For both types, the Fedora Docs team will follow the development and implementation of each Change and summarize it for the Release Notes. Volunteer writers 'own' each change by taking the Docs Contact designation in the Change tracking bug, and coordinating documentation with the Change owners. Writing these up is a relatively straightforward, well defined task that's ideally suited for new Docs contributors. The proposals are discussed at length on the devel(a)lists.fedoraproject.org mailing list and in FESCo meetings. Some topics might be unfamiliar to you, but don't let that be a roadblock - the writing is targeting uninitiated readers, so your perspective is in a good place. Without further editorializing, I present the list of approved Changes so far. Please take the opportunity to get started early! Fedora 23 Accepted System Wide Changes Proposals These changes have been accepted by the Fedora Engineering Steering Committee <https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee> for the Fedora 23 Release as System Wide Changes. <https://fedoraproject.org/wiki/Category:SystemWideChange> Harden All Packages <https://fedoraproject.org/wiki/Changes/Harden_All_Packages> Hardening is the process of securing a system/application by reducing its unnecessary functions, or restricting access. In Fedora 22 and before, it was up to the package maintainer to add %global _hardened_build 1 to their spec file to ensure their program was hardened. Beginning with Fedora 23 this will now become the defaults for all packages. You can compare the security by running the following as root: Owners - Owner: Till Maas | Moez Roy | Florian Weimer - Release notes owner: Tracking - Last updated: 2015-02-12 - Tracking bug: #1215939 <https://bugzilla.redhat.com/show_bug.cgi?id=1215939> - Original tracking bug: #1199775 <https://bugzilla.redhat.com/show_bug.cgi?id=1199775> - Status: Change accepted Mono 4 <https://fedoraproject.org/wiki/Changes/Mono_4> Update the Mono stack in Fedora from 2.10 to 4.* Owners - Owner: Claudio Rodrigo Pereyra Diaz - Release notes owner: Tracking - Last updated: April 29, 2015 - Tracking bug: #1221559 <https://bugzilla.redhat.com/show_bug.cgi?id=1221559> - Status: Change accepted Disable SSL3 and RC4 by default <https://fedoraproject.org/wiki/Changes/RemoveSSL3andRc4> This change will disable by default the SSL 3.0 protocol and the RC4 cipher in components which use the system wide crypto policy. That is, gnutls and openssl libraries, and all the applications based on them. Owners - Owner: Nikos Mavrogiannopoulos - Release notes owner: Tracking - Last updated: 2015-04-28 - Tracking bug: #1220679 <https://bugzilla.redhat.com/show_bug.cgi?id=1220679> - Status: Change accepted Perl 5.22 <https://fedoraproject.org/wiki/Changes/perl5.22> A new perl 5.22 version brings a lot of changes done over a year of development. Perl 5.22 should be released 5/20/2015. See 5.21.11 perldelta for more details about preparing release. Owners - Owner: Petr Písař - Release notes owner: Tracking - Last updated: 2015-04-28 - Tracking bug: #1220680 <https://bugzilla.redhat.com/show_bug.cgi?id=1220680> - Status: Change accepted Default Local DNS Resolver <https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver> To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. Owners - Owner: P J P | Pavel Šimerda | Tomas Hozza | Petr Špaček - Release notes owner: Tracking - Last updated: 2015-05-28 - Tracking bug: #1182488 <https://bugzilla.redhat.com/show_bug.cgi?id=1182488> - Status: Change accepted Fedora 23 Boost 1.59 Uplift <https://fedoraproject.org/wiki/Changes/F23Boost159> This change brings Boost 1.58.0 or later to Fedora 23. We generally aim to ship 1.59.0, as that seems likely to make it (hence the Change name), but 1.58.0 is out and available now. Owners - Owner: Jon Wakely - Release notes owner: Tracking - Last updated: 2015-06-07 - Tracking bug: #1229030 <https://bugzilla.redhat.com/show_bug.cgi?id=1229030> - Status: Change accepted Fedora 23 Accepted Self Contained Changes Proposals These changes have been accepted by the Fedora Engineering Steering Committee <https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee> for the Fedora 23 Release as Self Contained Changes. Cinnamon Spin <https://fedoraproject.org/wiki/Changes/Cinnamon_Spin> A Fedora Spin using the Cinnamon desktop environment. - Owner: Dan Book - Last updated: 2015-05-06 - Completed: no <https://bugzilla.redhat.com/show_bug.cgi?id=1225865> System Firmware Updates <https://fedoraproject.org/wiki/Changes/SystemFirmwareUpdates> This change is to add the ability to perform firmware updates on UEFI machines. - Owner: Richard Hughes - Last updated: 2015-06-03 - Completed: no <https://bugzilla.redhat.com/show_bug.cgi?id=1230554> Cockpit GUI for Domain Controller Role <https://fedoraproject.org/wiki/Changes/Cockpit_Domain_Controller_GUI> Provide a graphical mechanism for deploying a FreeIPA Domain Controller on Fedora Server through the Cockpit administrative console. - Owner: Stephen Gallagher, Stef Walter - Last updated: 2015-06-18 - Completed: no <https://bugzilla.redhat.com/show_bug.cgi?id=1233098> Containerized Server Roles <https://fedoraproject.org/wiki/Changes/Containerized_Server_Roles> Enhance rolekit to be able to deploy Server Roles using the Nulecule Container Specification. - Owner: Stephen Gallagher - Last updated: 2015-06-18 - Completed: no <https://bugzilla.redhat.com/show_bug.cgi?id=1233099> Frappe Framework <https://fedoraproject.org/wiki/Changes/frappe-framework> A full-stack web framework based on Python and Javascript to help you build powerful business apps and nifty extensions. - Owner: Eduardo Mayorga , William Moreno - Last updated: 2015-06-18 - Completed: no <https://bugzilla.redhat.com/show_bug.cgi?id=1233101> Category:ChangeAcceptedF23 <https://fedoraproject.org/wiki/Category:ChangeAcceptedF23> and Category:SelfContainedChange <https://fedoraproject.org/wiki/Category:SelfContainedChange> -- Pete

2 1

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by Pete Travis 28 Jun '15

28 Jun '15

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2015-06-29 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: An hour of docs folks talking about what they are working on and what they'd like to work on. More information available at: [https://fedoraproject.org/wiki/Docs_Project_meetings](https://fedoraproject… Source: https://apps.fedoraproject.org/calendar/meeting/371/

1 0

Re: Virt getting started guide chapters (Glen Rundblom)
by Laura Novich 24 Jun '15

24 Jun '15

Hi Glen, Thank you for the great idea about Docker and Container virtualization. Yes we need to document it, but at the moment I would like to finish editing/auditing our current TOC. I am not convinced that containers should be in the same guide as virtualization Getting Started as it will make this guide bigger than it needs to be. I would love to discuss with you a manual on Containers/Docker so please drop in on my Office Hours on Wed @ 1300UTC Best Regards, Laura ==================== >I like the idea of a 'why to use virtualization'. This will be very handy >if we do put docker in that guide. >I'd like to see docker documented, the question I have (being a total noob >for containers) - would someone looking for docker go to a virtualization >guide?? >Sandra >On Fri, Jun 19, 2015 at 8:10 AM, Glen Rundblom <glen(a)rundblom.com> wrote: >> Hello, >> I was looking over the wiki page outline for the virtualization getting >> started guide, and thought two things: >> >> 1. Do we need a chapter (3) on why someone should use virtualization >> 2. I think we should include a chapter about Docker >> >> I was thinking about Docker because to overcome the publican problems in >> Fedora22 I built a Fedora21 image with publican so I can build the guides. >> It occurred to me that it probably should be in the guide as well. >> >> Respectfully, >> -Glen >> > -- > docs mailing list > docs(a)lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/docs

3 2

Initial commit and push for the Libvirt Application Development Guide Using Python
by David Ashley 24 Jun '15

24 Jun '15

All - I have made the initial commit and push for the Libvirt Application Development Guide Using Python document. You can pull it with git clone git://git.fedorahosted.org/git/docs/libvirt_application_development_guide_u… This is a straight up version of the docs I got from the libvirt team with some style changes that put them more in line with Fedora docs. Mainly I removed two chapters that will not be covered in this guide and modified a lot of the IDs and LINKEND links to be better references. The main content is unmodified. I will now begin the conversion process from a C guide to a Python guide. It will involve replacing all the C examples with Python examples and modifying the text to match that replacement. There are lots of blank spaces to be filled in that the libvirt team never got around to. After converting the existing stuff I will see what I can do about filling in those spaces. As always, if you have a interest in this guide feel free to jump in and help at any time. David Ashley

1 0

[Fedocal] Reminder meeting : Docs Office Hours ( Americas )
by Pete Travis 24 Jun '15

24 Jun '15

Dear all, You are kindly invited to the meeting: Docs Office Hours ( Americas ) on 2015-06-25 from 12:00:00 to 13:00:00 US/Mountain The meeting will be about: Office hours for Fedora Docs contributors. Stop in to #fedora-docs for help with writing documentation or just to schmooze with the Docs community. Bring your own cake. Source: https://apps.fedoraproject.org/calendar/meeting/434/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs June 2015