docs June 2017

docs@lists.stg.fedoraproject.org

13 participants
23 discussions

Fedora 26 Final Release Readiness Meeting on Thursday, July 6th @ 19:00 UTC
by Jan Kurik 30 Jun '17

30 Jun '17

Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 26 Final Release Readiness Meeting meeting. The meeting is going to be held on Thursday, July 6th, 2017 at 19:00 UTC. Please check the [1] link for your time zone. We will meet to make sure we are coordinated and ready for the Final release of Fedora 26. Please note that this meeting is going to be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but it is by purpose to open this meeting to the teams and to raise awareness, so hopefully more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. For more information please check the [2] link. As I will not be available for this meeting, Jaroslav Reznik <jreznik> will be the moderator. Please contact Jaroslav in case of a need for additional information. [1] https://apps.fedoraproject.org/calendar/meeting/6285/ [2] https://fedoraproject.org/wiki/Release_Readiness_Meetings Thank you for your support, Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F26 Release Notes help needed
by Petr Bokoc 29 Jun '17

29 Jun '17

Hi everyone, let's revive this a little bit. We're going to have to produce some release notes for Fedora 26. I've seen a few people on the list in the past mention they'd like to help, and writing these is probably the best way to start with that. Note: There seems to be some confusion among newcomers: the Docs Project doesn't maintain the Wiki, we take care (well, occasionally...) of docs.fedoraproject.org. The guides published there are currently written in DocBook XML[0], stored in Git repositories on Pagure[1], and published using publican[2]. We have some vague-ish plans to replace most of that with something more modern and accessible to newcomers, since docbook really isn't user friendly, but that's not going to happen for F26, so for this release we'll have to stick with our current tools. Luckily, Release Notes in particular can be done in a way that avoids DocBook, Git, and Publican altogether; they're short bits of text I or someone else with experience can mark up and commit for you - you just need find the right information and write them. The only thing you will need is a Pagure account - which is actually your FAS account. If you don't have one yet, make one[3], make sure to sign the CLA (Contributor License Agreement), log in to FAS, and apply to join the "docs" group; I'll approve you once I see your application. That should give you permissions to comment on Pagure issues, which is where I'd like you to save what you write for release notes unless we agree on some other approach. Also, I'm pretty sure gaining membership in a group will allow you to edit the wiki, if you're interested in that - wheee! If anyone has any questions, contact me on this mail or in #fedora-docs on IRC; my time zone is CEST (UTC+2) and I'm online mostly during afternoons on workdays. ===HOW DO I ACTUALLY CONTRIBUTE?=== Lately our main focus was covering Accepted Changes in our release notes, since that's an easy and expansive source of information about changes in each release. I took the liberty of opening an Issue on Pagure for every change; you can see them here: https://pagure.io/release-notes/issues Contributors should: * go through the list and find something to write about that isn't assigned to anyone yet (the rightmost column), open the issue and the link to Wiki inside it * on the wiki page, you'll find three important pieces of info: 1) a tracker bug in Bugzilla, 2) change owner(s) and 3) a short, hopefully coherent description of the change. 1) the tracker bug is somewhat useful when trying to determine if the change actually made it into the release. Don't count on it really being there, in theory changes that are postponed or canceled should be deleted from the wiki or at least marked somehow, but they often aren't. Therefore, check the bug's status: if it's on ON_QA, VERIFIED, RELEASE_PENDING or CLOSED-CURRENTRELEASE, it's safe to assume it did make it in. If it has a status like NEW, ASSIGNED, or MODIFIED, contact the owner before you start writing and ask them if the change made it to F26. If it didn't, we shouldn't be writing about it. 2) the change owners are people you should contact a) to check if the change still applies if required (see above), and b) when you write a draft release note so they can check it for technical accuracy. 3) the description should give you some information so you can get started on your draft. * once you have something you believe to be publishable, go back to the Issue on pagure and save your text as a comment there. Some additional notes: * the current issue list (or the changeset wiki page) is by no means exhaustive. You're very welcome to add more release notes for things like changes in widely used components from kernel to firefox to freeciv. Just make sure you're writing about a component version that will be available in Fedora 26 upon release, not a previous version, *not the latest upstream version*. It's common for Fedora to come out with something like Firefox X, but on its website you can already download version X+1 at the same time. We're writing this about Fedora, so keep that in mind. The previous sentence also means that we shouldn't be covering any third-party repos, proprietary drivers, etc. - Fedora only. * there often are upstream release notes that are much more exhaustive than what we would write, so use them. I'm talking about changes like "upgrade Boost to 1.63" - Boost version 1.63 already has its own release notes, and this change just means Fedora is using that version. In that case, you can just write as much, maybe provide a short list of the most important changes, and then link to Boost's website for the full version, like we usually do[4]. * the current release date is July 11, so please, make sure you're done two days before so I have time to convert everything. If you can't make it, please send me an e-mail and drop (unassign) any issues you can't do in time. There's no shame in backing out, we all have other things to do, but please make sure someone can still pick it up. ===BUT PETR, HOW ARE WE GOING TO PUBLISH? WE STILL NEED THAT ANCIENT PUBLICAN VERSION THAT ONLY RUNS ON A FEDORA RELEASE THAT CAN'T PUSH TO PAGURE!=== Yeah, but we should be able to publish by building the website in the VM like we used to until now, and then mounting the VM's storage on a more modern system that can push and doing the last step that way. Good luck everyone, and again, ping or e-mail me if you have any questions. Petr --- [0] http://tdg.docbook.org/tdg/4.5/docbook.html [1] https://pagure.io/group/fedora-docs [2] https://jfearn.fedorapeople.org/en-US/Publican/ [3] https://admin.fedoraproject.org/accounts/ [4] https://docs.fedoraproject.org/en-US/Fedora/25/html/Release_Notes/sect-Rele…

2 3

Doc Meeting Minutes - 26 June 2017
by Brian Exelbierd 26 Jun '17

26 Jun '17

Hi, The docs meeting today was talking about our test AsciiBinder/AsciiDoc site. Meeting ended Mon Jun 26 14:58:28 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . <zodbot> Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2017-06-26/fedora_docs.201… <zodbot> Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2017-06-26/fedora_docs.201… <zodbot> Log: https://meetbot.fedoraproject.org/fedora-meeting/2017-06-26/fedora_docs.201…

1 0

Self Introduction: Adam Tozer
by Adam 26 Jun '17

26 Jun '17

Hi, my name is Adam Tozer and I would very much like to spend some time contributing to Fedora Documentation. I work in the Technology field, I spend most of my working hours documenting. I have been working in IT for about 20 years, my computer skills are boss. My writing is usually concise, unambiguous, and clear. My networking knowledge is strong and mathematics is one of my hobbies. I think I am a good match for the Docs project because unlike most people I enjoy documenting and I am reasonably good at writing documentation. I intend to start off contributing 4 hours per week. I would like a mentor and I would like to start documenting "How to Modify IPTables" requested by "Sparks". My timezone is Australian Eastern Standard, UTC/GMT +10. My; GPG key ID: 0xAE9FEA8C Fingerprint: F74D BE77 BF06 32B0 24AF AF38 4A27 7F08 AE9F EA8C Thank you for viewing my self introduction, Adam.

2 1

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by immanetize＠fedoraproject.org 25 Jun '17

25 Jun '17

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2017-06-26 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

Question about pdating translations in Spanish
by Luis Ángel Gonzo 24 Jun '17

24 Jun '17

Hello everyone, I've just made some of the missing translations in Spanish and updated others with some improvements located in Fedora Installation Guide> F25> Document(es) Shall I notify someone in particular to push this translations and publish them? Thanks in advance, Luis

1 0

Fedora 25/26 hardware requirements in Release Notes outdated?
by Florian H. 18 Jun '17

18 Jun '17

Hi, I came across the Release Notes for Fedora 25 [1], and I think the system requirements are not adequate anymore. It says that the figures "are a recommended minimum for the default installation." Considering the default installation is a Fedora Workstation featuring the Gnome Desktop, 1 GB of RAM is not enough to have a pleasant experience. In my personal opinion, 2 GB is the absolute minimum for Gnome, still likely to result in a lot of swapping. In addition to the minimum requirements, we could introduce a section with recommended specs. Also, we could drop a sentence in regards to the less demanding Fedora spins. Cheers, Florian [1]: https://docs.fedoraproject.org/en-US/Fedora/25/html/Release_Notes/sect-Rele…

3 3

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by immanetize＠fedoraproject.org 18 Jun '17

18 Jun '17

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2017-06-19 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

[Fedocal] Reminder meeting : Fedora Docs Weekly Meeting
by immanetize＠fedoraproject.org 11 Jun '17

11 Jun '17

Dear all, You are kindly invited to the meeting: Fedora Docs Weekly Meeting on 2017-06-12 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

release notes in unicornland
by Matthew Miller 05 Jun '17

05 Jun '17

So, occasionally someone from a large software company where I happen to be employed comes and asks me things like "So, what's changed in Fedora since version 20"? We have the ChangeSet pages, and we have release notes (largely, I think, based on those, at least recently). But, Changes are usually only filed when we as Fedora decide to make a change on purpose, or when there is an upstream change which requires coordination to land. The vast majority of user-impacting change comes through from upstream without particular note. Some of these don't even come in at release time, or into Rawhide only for the next release — sometimes they come in as updates. It'd be nice to be able to refer users — and it's end-users, too, not just the company requests — to a more complete log of user-facing changes. (Things like: command lines moved around, new features, deprecated functionality, removed functionality, etc.) With our theretical new docs system, is there a way we can do this? I'd like something which would be really easy for packagers, and ideally be integrated with (or replace?) the RPM changelog and the Bodhi update text. Ideas? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

2 2

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 2017