docs February 2010

docs@lists.fedoraproject.org

23 participants
40 discussions

Live collaboration at Desktop Help Summit
by Paul W. Frields 20 Feb '10

20 Feb '10

Shaun, Here's a list of infrastructure resources to help with live collaboration: * IRC Freenode #desktop-help -- doesn't seem like there's anything more needed here, you're an auto-op and the channel is all ready with zodbot waiting for you to use to log proceedings. * Fedora Talk -- we have a local dial-in available in Chicago so any regular phone can be used with our conference rooms. You can record if needed, although you'll want to let us know ahead of time so we can make sure instructions are clear and everything's working. http://talk.fedoraproject.org * You had mentioned that you were going to check phone and projector availability. Any word on that? Let us know on the list if there's anything else we can do to help make the meeting a successful collaboration. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com

3 5

Sugar on a Stick Docs using Publican
by Sebastian Dziallas 19 Feb '10

19 Feb '10

Hi all, as some of you may have heard, Sugar on a Stick [1] is going to become a Fedora Spin for F13. I've had some spare time last weekend and took the chance to create this: http://people.sugarlabs.org/sdz/ (It's far from being complete, but I finally wanted to give Publican a try. It rocks.) If anybody has random comments or would be interested in helping out, please holler... :) --Sebastian [1] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick

3 7

Self Introduction
by Shivam 18 Feb '10

18 Feb '10

Hi everyone, I'm Shivam from New Delhi, India. I've been using GNU/Linux systems casually for a couple of years, and know a few basic Bash commands (this will improve in the near future as I'm currently going through RUTE). I can help in proof- reading and editing existing docs, and write some of my own when I'm experienced enough. Apart from editing, I can also help in translations as I'm fluent in Hindi. I am also an intermediate GIMP user, and can help out in designing logos, wallpapers, etc.; I'm not familiar with UI design, though. Here is my GPG information : [shivam@localhost ~]$ gpg --fingerprint 0F1CFA75 pub 1024D/0F1CFA75 2010-02-18 Key fingerprint = A381 A782 D746 8C4A B5CE 4079 71D5 B520 0F1C FA75 uid finkler <finkler(a)fastmail.fm> -- Shivam finkler(a)fastmail.fm -- http://www.fastmail.fm - A fast, anti-spam email service.

2 1

No Frozen Rawhide help
by Paul W. Frields 18 Feb '10

18 Feb '10

Hi Docs team, The release engineering team needs our help with some wiki revamping. Specifically Rawhide, our development branch for software packages, has changed in the Fedora 13 cycle, pursuant to what we call the "No Frozen Rawhide" (NFR) proposal. In the past, changes in Rawhide would slow as we got into the testing (Alpha, Beta) phases for a release. In theory, fewer changes would be allowed in the closer we get to release, and those allowed in would be subject to more scrutiny, to stabilize the release. As a result, right after the release is composed and tested successfully, Rawhide would be unblocked like a dam, and the resulting flood of changes would typically result in an unusable Rawhide for some time while people pick up the wreckage and fix things. Pursuant to NFR, we've just branched for Fedora 13 early, and separated that branch from Rawhide. Rawhide is now carrying those packages that will be in Fedora 14, about 9 months from now. As a result, we can apply a higher level of scrutiny to the Fedora 13 branch, while Rawhide will continue to roll on, only hopefully without a point of massive breakage. A team of people gathered last Friday to put together explanations of how this scheme works, and how it affects people in various categories, including packagers, testers, mirror admins, and others: https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan What we need now is for a few people to help with fixing wiki pages, most of which have been listed here on that page: https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Existing_Doc… You don't need to be an experienced Rawhide user or tester to understand the information on this page. But if there are any questions, everyone on the crew who participated in the NFR conference last week is available on IRC to answer questions. What do you need to do? * Show up on IRC Freenode at #fedora-docs -- instructions for doing that are here: https://fedoraproject.org/wiki/How_to_use_IRC * Ping me, "stickster," and tell me you want to help. I'll get you started on a specific page. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com

1 0

New Tx with Publican Support
by Dimitris Glezos 16 Feb '10

16 Feb '10

We now have an updated working Tx instance on our staging servers, so we can test support for Publican documents. Here's an example: https://translate.stg.fedoraproject.org/projects/p/publican/c/virt-guide-lo… Please feel free to test your projects on the staging servers (basically statistics generation), in order to proceed with the upgrade on the app servers soon. Let me or another admin know if you have a repo you need to test, we'd be glad to make you a maintainer of a project to play around. -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/

1 0

Fwd: Tx 0.7/0.8 question
by Paul W. Frields 16 Feb '10

16 Feb '10

Dimitris gave me permission to forward this to the list -- a followup on my action item from last week's meeting regarding the Transifex migration. Paul ---------- Forwarded message ---------- From: Dimitris Glezos <dimitris(a)glezos.com> Date: Thu, Feb 4, 2010 at 3:56 AM Subject: Re: Tx 0.7/0.8 question To: "Paul W. Frields" <stickster(a)gmail.com> On Thu, Feb 4, 2010 at 3:17 AM, Paul W. Frields <stickster(a)gmail.com> wrote: > In a little over a month, March 11, the Docs group will be approaching > a deadline for their guides. By that time, they need translate.fp.o > running Tx 0.7. There's a ticket open for that, and work is > progressing: > > https://fedorahosted.org/fedora-infrastructure/ticket/1455 > > I asked in tonight's Docs meeting about that deadline, and whether the > Docs team had considered any alternatives. One alternative is to > continue using the old system, with bad (and tedious) hacking required > on the part of Docs maintainers to split/merge Publican POT files for > use on the older Tx. This is a bit hairy and we should probably avoid it, like you implied. We need to channel resources into more creative and important stuff. > Another alternative might be using transifex.net for one release. As > transifex.net is a completely free software platform, doing this would > not go against the Fedora mission or methodologies. However, it would > depend heavily on the portability of 0.8 data/schema back to 0.7. How > hard is that, and is this viable at all if it comes to an emergency? 0.8-alpha is out, so Fedora could upgrade straight to 0.8 in a few weeks anyway. Additionally, the work needed to re-create a few projects on translate.fpo is very small -- just a few clicks away. For these reasons I wouldn't worry too much about migration. =) We'd be happy to help in any way we can. Adding Docs on Txn should be a few minutes' work. There's a ticket open to enable Transifex.net submit to Fedora Hosted: https://fedorahosted.org/fedora-infrastructure/ticket/1687 For the record, Transifex offers migrations both in a forward way as well as backwards. We haven't done heavy tests on the latter, but they should work. > Just to be clear, I have full faith in our Infrastructure team; > they're true genii. But it's always good to have a backup plan. I too believe we have an excellent Infrastructure team. Our challenge is resources, since we don't have people actively maintaining and pushing our L10n infrastructure. We could try this out and see how it goes. It's how we first tested Transifex itself, right? First it was docs, then we moved more projects. By the way -- we could consider switching to transifex.net in general. We roll out incremental upgrades there and, as a plus, using an upstream instance will help in many areas. If you consider projects like Pulseaudio and Packagekit, this makes total sense. If you remember, we have had complaints in the past about system-config-printer. Even for projects like Anaconda it makes sense: Moblin is using Anaconda and it's a pity to lose translators. Examples of projects using a hosted free software are Qt and Maemo using Gitorious (qt.gitorious.org and maemo.gitorious.org) Even Moblin is considering to switch to something like moblin.translate.org. This way they can channel resources in competitive advantages instead of Infrastructure. In any way, this should be a separate discussion. If we would have "good multilingual support" a primary goal of us, we should start thinking more strategically about how we are pursuing it, why Launchpad is investing so heavily in Rosetta (Launchpad's L10n tool) etc. Just some food for thought. =) -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/

2 2

Self-Introduction
by Eliot Smith 16 Feb '10

16 Feb '10

Greetings, My name is Eliot Smith and I am eager to join the Fedora Documentation Project. I live in Helena, Montana. I have studied at St. John's College in Santa Fe, NM, receiving a MA in Liberal Arts and at Sierra Nevada College in Incline Village, NV, receiving a BA in Humanities. I have worked, informally, on a Linux system, beginning with Ubuntu and moving to Fedora, for the past 3 years. My computer knowledge is limited, but I am enthusiastic about learning new skills and have done well learning so far. I have tutored and taught writing at the college level. Thus, my editing skills are first rate and I would very much like to focus on editing the Fedora Documentation. Best Regards, Eliot Smith

2 1

[Bug 514046] New: Oracle-xe page for Spacewalk doesn't work
by Red Hat Bugzilla 16 Feb '10

16 Feb '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Oracle-xe page for Spacewalk doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=514046 Summary: Oracle-xe page for Spacewalk doesn't work Product: Fedora Hosted Projects Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Deployment_Guide AssignedTo: mhideo(a)redhat.com ReportedBy: mschwage(a)gmail.com QAContact: rlerch(a)redhat.com CC: fedora-docs-list(a)redhat.com Classification: Fedora Description of problem: Sorry about the classification of this. I didn't see Spacewalk anywhere in Bugzilla! Anyway, on the webpage https://fedorahosted.org/spacewalk/wiki/OracleXeSetup#Install, the install instructions don't work as advertised. There, it says "Configure the Oracle XE database by running # /etc/init.d/oracle-xe configure" This did not set the system/sys name correctly. Yes, I know, the oracle-xe command comes from Oracle themselves, but on my RHEL53 machine it just refused to set the password correctly. Did I try to do it 10 times or more? Yes I did, and it did not work at all. Did I fat finger my password every single lousy time I tried it? No I did not, for I was able to create my password as easy as you please using my workaround below. Version-Release number of selected component (if applicable): oracle-xe-univ-10.2.0.1-1.0 oracle-instantclient-basic-10.2.0.4-1 oracle-instantclient-sqlplus-10.2.0.4-1 How reproducible: Every time. Steps to Reproduce: 1. Do this on RHEL53 x86_64. Install the Oracle-XE software as listed. 2. Follow the instructions on https://fedorahosted.org/spacewalk/wiki/OracleXeSetup#Install, up to and including the "Test Your Connection with SQLPlus" part. 3. You fail to login. Actual results: Fail to login. Expected results: Successful login. Additional info: The workaround is to perform the following after running /etc/init.d/oracle-xe configure : su - oracle . /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle_env.sh /usr/lib/oracle/10.2.0.4/client64/bin/sqlplus /NOLOG CONNECT / AS SYSDBA alter user sys identified by password; alter user system identified by password; sqlplus64 'sys@xe as sysdba' -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

Upcoming Fedora 13 Schedule Tasks
by John Poelstra 15 Feb '10

15 Feb '10

Start End Name Wed 18-Nov Tue 04-May Create POT files for All Guides Tue 23-Feb Tue 23-Feb Start Alpha Beat and Feature Page Review Tue 23-Feb Thu 25-Feb Comb Beats and Feature Pages for Alpha Thu 25-Feb Thu 25-Feb Alpha Project Wide Release Readiness Meeting Thu 25-Feb Fri 26-Feb Prepare Alpha Release Notes (1 page) Thu 25-Feb Mon 01-Mar Create Alpha Announcement (Marketing & Docs) Mon 01-Mar Mon 01-Mar Post Alpha Release Notes One-Page Tue 02-Mar Tue 02-Mar Alpha Public Availability Tue 02-Mar Wed 10-Mar Write Unclaimed Wiki Beats

1 0

Guide branching
by Susan Lauber 12 Feb '10

12 Feb '10

The time rapidly approaches when we need to start updating the guides for a new version. In this example - start work on F13 version of the guides. Basically - I wanted to know where to start contributing changes intended for the F13 version on guides. And where to point new contributors as well. In the meeting tonight, a discussion started about branching philosophies. #action laubersm Bring branching topic to docs list to decide how we want to do this going forward, and record it for posterity. I have looked at a couple of guides in git. They seem to have a master, F11, F10, etc, and various F??-tx branches. I think we generally agree that the F??-tx branches are for the translation teams. The rest seems to indicate a need for a F12 branch and then master becomes F13. But when should the F12 branch appear so that work on F13 can begin? I did not look at all the guides - there may be other schemes in use already. So I see 2 major parts to the question: 1. Is this the branching scheme that works best for Fedora Docs group and guides? What are the alternatives? pros/cons? etc 2. WHEN do we branch? Should the F12 branch been made at release of F12 so that master moves to the next version right away? If so, how do we handle mid release updates to a guide? Should master stay the current version until the next release alpha? Which is about now. Or even longer? Let the debate begin (be nice folks). -Susan -- Susan Lauber, (RHCX, RHCA, RHCSS) Lauber System Solutions, Inc. http://www.laubersolutions.com gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974

4 4

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 February 2010