docs October 2007

docs@lists.stg.fedoraproject.org

32 participants
60 discussions

free formats, CodecBuddy, and how you can help
by Karsten Wade 16 Oct '07

16 Oct '07

As part of our ongoing campaign in Fedora to support and promote free/open formats for media, Fedora 8 has a new feature called 'codeina' that is part of the GStreamer package. There is a proposed patch to codeina to change certain default behavior, The effect is, when a user attempts to play a format that is not supported due to a codec being non-free or otherwise patent encumbered, a dialog window pops up. This window informs the user of what is happening and links off to a webpage for more information: https://bugzilla.redhat.com/attachment.cgi?id=221531 (Note - the typo 'availabe' has been fixed. You may be able to get changes to this dialog into the patch if you act quickly.) The dialog has a link to fedoraproject.org/codecbuddy, which redirects to a wiki page. Your help is needed in crafting this message the users see: http://fedoraproject.org/wiki/CodecBuddy That webpage can have: * More information * Links to more information (such as the ForbiddenItems page) * Links to where one can legally purchase codecs (through Fluendo) All of this replaces the default codeina behavior, which is to take the user directly to Fluendo's online shop. The Fedora Board felt that it is OK to offer such options as part of a full story, but not as a default action without context as to *why* this is happening. The codeina maintainer would like to see the webpage/wiki page updated before accepting the patch. If you are interested, just jump in and start editing the CodecBuddy page. Hopefully someone with more information about the Fluendo portions can help with that. thx - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41

3 3

FDSCo Meeting 2007-10-14 Summary
by John Babich 14 Oct '07

14 Oct '07

A non-quorum meeting was held with John Babich (jmbuser) and Bart Couvreur (couf) attending. Ignacio Vazquez-Abrams (ivazquez) and Ville-Pekka Vainio (vpv) also participated. Two agenda items were discussed (both suggested by the Fedora Marketing team in the previous day's meeting). 1. Marketing team proposal to republish, on docs.fp.o, FedoraUnity.org docs for creating re-spins. See http://www.redhat.com/archives/fedora-docs-list/2007-October/msg00058.html for details. Note: docs.fp.o is the abbreviation for docs.fedoraproject.org. <jmbuser> To be practical, I guess we need a "table of contents" and start with revisor and add the others [live-CD tools & pungi] as time permits - links to what exists today <couf> jmbuser: I'll see what I can do <couf> I'll try to get kanarip and daMaestro on board and it could go fast then 2. Publishing howto's to docs.fp.o: increase visibility of the site and might have positive influence on our contributor flow-in John and Bart briefly reviewed Marc Wiriadisastra's (Strikeforce) site and agreed that this would be a good addition to docs.fp.o. The main concern is that the how-tos need to meet the "legal" guidelines for a Fedora Project site - i.e., not include forbidden items. These items could remain on an unofficial website if desired. This would be a great project for a beginner with a little bit of guidance. Ville-Pekka joined in to clarify that his summer project was concerning man and info pages, not how-tos. He is busy at the moment, but will ask for assistance on the mailing list to publish his work, once he has the time available. Best regards, John Babich Member, Fedora Docs Project

2 1

FDSCo Meeting 2007-10-14 IRC Log
by John Babich 14 Oct '07

14 Oct '07

<couf> jmbuser: welcome back * jmbuser had my required disconnect - now let's have the meeting <jmbuser> quaid: ping <couf> jmbuser: it seems it's just us :-/ <jmbuser> couf: Shall we have a meeting? <couf> jmbuser: well we don't have quorum, so if you want to discuss something go ahead, otherwise we might have to cancel <jmbuser> Let's wait and see if anyone shows up - 1 more minute <jmbuser> couf: still there? <couf> jmbuser: yep <jmbuser> couf: Is it worthwhile having a 2 -person meeting? <ivazquez> Sometimes. But it's not really worth scheduling unless both people are exceptionally busy. <couf> jmbuser: not really <couf> ivazquez: true <jmbuser> ivazquez: Are you here for the meeting? - welcome <ivazquez> Mostly just to eavesdrop. <jmbuser> couf: ok - we can have a brief meeting then - agreed? <couf> jmbuser: sure <jmbuser> Ok, if you don't mind, I'll start with the agenda: * jmbuser asks for patience with his slow internet connection <jmbuser> See http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings <jmbuser> Agenda item 1 - Proposed by Marketing team in their meeting yesterday. <couf> heh both topics can be linked to yesterday's marketing meeting <jmbuser> couf: true <jmbuser> Here's no.1 : * <jmbuser> Marketing team proposal to republish, on docs.fp.o, FedoraUnity.org docs for creating re-spins. See http://www.redhat.com/archives/fedora-docs-list/2007-October/msg00058.html for details. <jmbuser> couf: Thoughts, opinions? <couf> well it's definitly a good idea, the only drawback here is that does docs are 100% about revisor, neglecting pungi and livecd-tools <couf> note: this is an opinion with just briefly looking at the docs * couf tries to get kanarip in here <jmbuser> couf: Do we make that clear and try and get someone to fill the gaps on pungi especially? Livecd-tools at least has a fairly good page or two,,, <couf> jmbuser: it's a distinction we really need to make <jmbuser> couf: Without discriminating among the 3, are we promoting all 3 at the same time? <jmbuser> Is there a preferred method or whatever works for whomever? <couf> from a user-perspective revisor is the best way to go, developper/sysadmin would probably like pungi <couf> revisor builds on top of pungi/livecd so it's basicly the same principles <jmbuser> Is wevisor (web-based revisor) usable today - and therefore an option? <couf> well there is a proof of concept running at https://hosted.fedoraproject.org/projects/wevisor/ but no idea what the status is <jmbuser> couf: To be practical, I guess we need a "table of contents" and start with revisor and add the others as time permits - links to what exists today <couf> right <jmbuser> I really would like a volunteer since I promised a DUG for F8 <jmbuser> and don't want to be overcommitted <couf> jmbuser: I'll see what I can do <couf> I'll try to get kanarip and daMaestro on board and it could go fast then <jmbuser> couf: I didn't mean YOU had to be the volunteer :-) <jmbuser> but kanarip and daMaestro are more than welcome to help out <couf> jmbuser: yeah I know, but I just want to get this thing over with :-) <jmbuser> ok, shall we move on to agenda item 2? <couf> yep <jmbuser> 2 - Publishing howto's to docs.fp.o: increase visibility of the site and might have positive influence on our contributor flow-in <couf> give me 2 min, need to feed the dogs <jmbuser> OK <jmbuser> Does this refer to the COSS Summercode 2007 project by vpv - see http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio? * jmbuser waits for couf to return * couf returns <couf> ah sort off / might be part of it <jmbuser> vpv: ping * jmbuser sees vpv is away but hopes <couf> I just struck me that not many people know about docs.fp.o and that it could be usefull to get some more stuff on it to draw attention <couf> the idea basicly came from one guy how just joined this weekend having this great site full of howto's which he might transfer to us <jmbuser> That sounds promising * couf looks for the mail <couf> https://www.redhat.com/archives/fedora-docs-list/2007-October/msg00059.html <couf> site is: http://www.fedoraguide.info/index.php/Main_Page <couf> we will need to filter out stuff that's on it b/c of the legal stuff * jmbuser waits for his sluggish internet <couf> which actually leads to: what howto stuff is on our wiki that could/should be part off this new "thing" <jmbuser> I see the self-introduction <jmbuser> and the fedoraguide is slowly coming <couf> ah, this has some relationship with the kbase-idea of old <jmbuser> ok, got the website <jmbuser> Is the general ideas to bring over the "legal" topics and perhaps leave the other topics as an unofficial guide? <couf> I'm not sure, we should that with Marc (Strikeforce) <couf> probably the only way to go <jmbuser> couf: ok - I remember Strikeforce from the marketing meeting - is he seeking access so he can help bring it over - at least the permissible stuff? <couf> jmbuser: if I got it right, yes that's just it <couf> otoh, I could be really, really wrong too :-) <jmbuser> This would be a great contribution for an new FDP member to make - pretty easy to bring over with guidance with a quick and good payoff * jmbuser assumes Strikeforce would be agreeable to the official Fedora guidelines <couf> right * Libbe (n=espenas(a)178.80-202-101.nextgentel.com) has joined #fedora-docs * couf notes: I don't have much time left <jmbuser> couf: Any other topics or shall we wrap it up? <vpv> jmbuser: maybe somewhat, but you know my project dealt with man and info pages, not the documentation you write here * vpv notes he has midterm exams coming up, so he can't be very active right now <jmbuser> vpv: Thanks for tuning in - is your project ready for publication (when you have time, that is)? <couf> jmbuser: wrap up, unless you've got anything else? * jmbuser gives vpv a chance to respond <vpv> jmbuser: not really, it needs some work still, I have planned to send a "call for help" mail to the list <vpv> those who are interested could have a look at http://www.mindtrek.org/pdf/presentations/workshops/summer_coders/esitys-va… <jmbuser> vpv: fair enough - please send that email when you feel it is the appropriate time <vpv> that's my presentation in the OpenMind conference * couf needs to run <jmbuser> vpv: thanks - If there's nothing else, let's close the meeting - thanks * jmbuser declares end of meeting <couf> jmbuser: cool, thanks man <vpv> thanks :) <jmbuser> likewise

1 0

Self-Introduction: Zembutsu Masahito
by Zembutsu Masato 13 Oct '07

13 Oct '07

Full legal Name: Zembutsu Masahito City, Country; Tokyo, Japan Profession: Linux server administrator Company: link,Inc. My goals in the Fedora Project: I want to increase Japanese translation documents. My purpose is to popularize Linux among the Japanese children. I will write the document which aimed at the introduction. Historical qualifications: I did Japanese translation for the document (For example, CentOS FAQ). I have never join community. But, I introduced a translation document to the public at my own site. My skill is a server administration and a technical support. and programming skill in Perl. I have the experience of the technical support. Therefore, I contribute by making suitable Japanese document which is easy to understand. pub 1024D/983A72CB 2007-10-14 Key fingerprint = 2C3D 97A9 B8B8 E584 33D7 E179 C8B9 189D 983A 72CB uid ZEMBUTSU Masahito <zem(a)pocketstudio.jp> sub 1024g/B55B5CD0 2007-10-14

1 0

Self-Introduction: Marc Wiriadisastra
by Marc Wiriadisastra 13 Oct '07

13 Oct '07

Full legal name: Marc Wiriadisastra * City, Country: Perth, Western Australia * Profession or Student status: Student in Accounting and Business Law * Company, School, or other affiliation: Edith Cowan University www.ecu.edu.au * Your goals in the Fedora Project: To help improve the documentation so that new users are able to quickly get up to speed with using Fedora * What do you want to write about?: Anything provided I know it. * What other documentation do you want to see published?: Packaging, mini how to's, new information, equivalents list of packages from windows -> linux. * Anything else you'd like to do?: Not really to worried about what to do provided I can be of use. * Historical qualifications * What other projects or writing have you worked on in the past? fedorasolved.org, http://fedoraguide.info (my personal site based on ubuntuguide.org) * What level and type of computer skills do you have? Not to sure apart from using linux, some Java programming (uni level), some packaging knowledge will improve when I get organised and request a sponsor. * What makes you an excellent match for the project? I feel that I would be of benefit because I can relate to a new user in the sense that I was a new user not so long ago. I also get a lot of feedback from users relating to my website so I adjust it to improve it. * * [marc@strikeforce ~]$ gpg --fingerprint 5ADA6325 * pub 1024D/5ADA6325 2007-03-24 * Key fingerprint = EB34 04B8 7032 A2C5 3A34 7D9E 6603 4E4D 5ADA 6325 * uid Marc Wiriadisastra (strikeforce) <marc(a)mwiriadi.id.au> * sub 1024g/5ADDC4A9 2007-03-24 Cheers, Marc

1 0

CN=Darren Fields/OU=london/O=glen is out of the office.
by Darren.Fields＠glencore.co.uk 13 Oct '07

13 Oct '07

I will be out of the office starting 13/10/2007 and will not return until 29/10/2007. I will respond to your message when I return. LEGAL DISCLAIMER. The contents of this e-mail and any attachments are strictly confidential and they may not be used or disclosed by someone who is not a named recipient. If you have received this email in error please notify the sender by replying to this email inserting the word "misdirected" as the message and delete this e-mail from your system.

2 1

Fedora Documentation Platform
by Jonathan Steffan 12 Oct '07

12 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Team, So, after brief thought about the Fedora Documentation Platform (FDP) changes I'd like to do... here they are: * Replace Makefiles with config files and then use the FDP to do all building, allowing a user to specify they want to use the local cpu to do the building, or if they want to use the buildd. + We get to use python :-D + IMHO we would get much more flexibility and a tighter integration with our translators and translation systems (read: translators would be able to easily render for their language to check their results before pushing the build to zope + AFAIK, we have more combined skills with python, over Makefiles + Centralized code updates - Centralized code updates, this is because very little code will actually be in the buildd-cli. If the command is to run local, the buildd will just return an array of commands it would have run... allowing the buildd-cli to run them on the local cpu. This does require the buildd to be available and the contributor in question to have Internet access. Do we want to allow offline building? * Have better targets. It will be much easier for me to write more "stable" code if I am able to checkout a CVS module and then read (uniformly) into the buildd what this CVS module allows the buildd to do. For example, What languages are complete? What languages are there? When was the last build, the results? What is the target for this doc? Where do we have it published to? ... Stuff like this. I'd like to be able to programmatically read this information.. while also having it very easy to work with for a human (read: use something like ConfigParser) and storing most, if not all, information in the CVS tree itself. For example, I really wanted to add a "lock" to the CVS module when someone is doing TTW (through the web) editing. This will prevent data from being lost. Right now, it is possible for users via plone to be over written by a use editing via CVS and vice versa. I'd like to be able to checkout a CVS module and know "right away" if there has been an edit somewhere else... that has not been saved back to the module. If we had a nice system that I could easily make changes via the buildd to inform users of this.. it would be perfect. Example: User 1 is editing the README via plone. User 2 is leet and edits the docbook directly by checking out the module User 2 is informed with a DONTREALLYDOTHIS file that has the user info from plone stating the edit is going on, and when. [ OK, so yes.. we can do this anyways... and will] Any action User 2 takes via the buildd-cli, they will be directly warned and also questioned as to continue or not before they can render, or use the cli to commit (they could of course just use direct CVS commands, but yea) I also need the ability to have a document in different namespaces. Namespace = url request that retrieves rendered content. Example: CVS module harHar could have the namespaces /the/har/Har and also /documentation/this/is/answering/all/you/asked Such: Admin 1 authorizes Document 1 to go into official namespace as /howto/cure/luser/error This document is going through the standard process of translation, and updates. User 1 wants to contribute a fix to /howto/cure/luser/error but doesn't have access to that namespace. * Here, we want to enable anyone to help... on the team or not. User 1 either copies (if they can read they can copy :-D) or inits another document using the same CVS source. At this point I want User 1 to be able to edit the document. They will be able to, they are owners of the object. They will be restricted from being able to call a commit, but will be able to render from CVS (though the most likely don't want to as it would re-render over their changes.. good thing the document would be versioned in plone so they can revert that oops). * Here I want to illustrate why I really want a good way to work in multiple locations User 1 does some great work and informs Admin 1 (or 2, or 15) they should look at the changes. (Now, hopefully, I can get CMFDiff to work correctly, but lets assume it does) The Admin user will be able to look at the history tab and view all of the changes. If they are acceptable, the Admin user will be able to (from this user namespace) issue a commit to save the changes to CVS. Admin 1 has saved the changes.. and likes them enough they want to push them into the official namespace. Well, all that will need to happen is to issue a render in the official namespace. == At this point, having config files based in CVS is even more important. I briefly brought this up a while ago and have yet to solve it. == * What happens if we get an edit in English, for example, while translations are going on? Even if they are not? Do we render all languages... even when some languages have not been updated yet? Does this mean we will have multiple running versions? Do we block renders until all languages are updated? In our current system, it is very hard for me to programmatically tell/detect all of these situations and anything I've tried so far I was able to break quickly. Depending on the answers to the above, does it not make sense to be able to say "current render for language XY is already updated, don't render... *next*" to save CPU and rendering time? Does it not make sense to "ping" our translation system when we have stale detection? Do we ping and then block the render from going to the zope instance? I'm going to cut myself off to try to answer the rest of my questions from any responses I get from this. Basically, IMHO moving away from the current Makefile system will make what I think we are trying to achieve with the FDP less of a big "what can we get done building on top of our current system" and more of a "oh yeah, now that is cool" situation. Jonathan Steffan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHC8ZfrRJs5w2Gr1kRApJAAKDYbPkVxzxXzunpMpzH7qjnEVMZvACffmT/ aIQCuL+OBVNzQY9mh+ReR2s= =M3wF -----END PGP SIGNATURE-----

3 2

Setting the sights
by Paul W. Frields 09 Oct '07

09 Oct '07

The topic of our multiple task listings came up in the meeting. No, wait, that sounds like it just happened by itself; I raised the issue in the context of our contributor deficiency. In an only partially Swiftian moment, I suggested that we cull our task list, wiping clean any tasks that we can't get done with the people and resources we currently have. After a little further thought, I propose that we get rid of things on the list in the following order. This is just a proposal, and I'd be happy if people cared enough to argue about it one way or another. I'm prioritizing the list only so people can easily respond to any level they find objectionable. 1. Any unstarted task targeted for FC-5 or before which has no owner. 2. Any unstarted task for which we have no contributor who knows how to complete the task, regardless of ownership. 3. Any started task which has no current owner. 4. Any started task for which no updates have happened in >6 months, regardless of ownership. I know some people will find this very upsetting, and that's probably good. Maybe the idea sucks. But on the other hand, maybe a list full of tasks that aren't clearly going somewhere cause confusion and consternation to new contributors. If the task list we're working from doesn't have jobs with a clear "howto," we're not likely to get anyone to magically take those jobs over. The Docs Project is only going to thrive with the active participation of people who may not have the technical mastery to take care of multidisciplinary tasks. Therefore, we need to reduce the number of those tasks and skew the list more toward tasks that newcomers can do. Any task that requires ownership and for which there is not already an easy "howto" document for working on it, needs to have one. We can move forward and encourage what I somewhat frivolously called a culture of success in Sunday's meeting. But to do that, we have to be willing to pump out some bilgewater. Why do we want to track a huge number of tasks that no one is volunteering to do? Is that really a worthwhile pursuit, or is it creating unnecessary drag? Speaking of which, I would also like to move for using Bugzilla for task tracking, since (1) it's already there, (2) it has several components in place in the "Fedora Docs" product we can use for any tasks that come up, and (3) the rest of the project is using it. (If the task tracker changes for the rest of the project, any migration can include our tasks as well.) This may be a separate thread, though. If anyone wants to spin it off, please feel free. I have done a minimum of second-guessing and re-editing myself above, so that I get this out of my Drafts folder immediately. If anything above comes off as offensive or mean-spirited, I heartily apologize, since I did not mean it to be so. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

3 2

Release Notes sync
by Paul W. Frields 08 Oct '07

08 Oct '07

Just a quick note to the list to let people know that the Release Notes content has been synchronized with the wiki. I re-rolled the POT and PO files but will not notify L10N officially until tomorrow just in case. Most of their teams are and have been working on this content already, judging by the commits list activity. The total changes were on the order of approximately 60 strings. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

1 0

admin guide contributions
by Murray McAllister 08 Oct '07

08 Oct '07

Hi everyone, I have just joined the Fedora Docs project and have been browsing the task list. I've just started my new job at red hat so lately I haven't had a lot of free time. I was wondering if perhaps I would be able to contribute a section or two to the admin guide. I thought I could start with something small; I was thinking a section on setting up basic network settings (ip address, dns, hostname etc) using command line tools and system-config-network. Last year I did quite a bit of research and wrote a paper on BIND - maybe I can contribute that into here as well... Thanks, Murray. --------------------------------------------------------------------------------------------------------------------------------------------------------------- pub 1024D/81B3FDEB 2007-09-19 [expires: 2008-09-18] Key fingerprint = 4ED9 9907 5BF0 4132 2B46 20D1 C0C6 362D 81B3 FDEB Murray McAllister (Fedora Docs Project / mdious) <murray.mcallister(a)gmail.com> sub 2048g/B04CFA0C 2007-09-19 [expires: 2008-09-18]

5 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs October 2007