Self-introduction
by Brad Ackerman
I've been using Linux since 1993ish, and professionally since 2003. I'm
currently just a user at work, but was a system administrator for a few
years (RHEL5/6, Solaris, Windows, SANs, networks, and anything else with
a CPU and an Ethernet port). In that job, I wrote a hundred pages or
thereabouts of DocBook, so I'm fairly familiar with that tool chain
(including Publican).
As for projects to work on - what's currently in need of proofreading?
I'm mostly busy with unpacking outside of work still as I recently
moved, but once I have more time at home I'd probably want to pick some
of the outdated documentation to bring up to F19/F20.
--
Brad Ackerman N1MNB PGP: 0x9F49A373
brad(a)facefault.org <*> http://bsa.smugmug.com/
10 years, 7 months
ARM Getting Started Guide
by Zach Oglesby
I started working on moving some of the information from the ARM "Secret
Decoder Ring"[1] page into the ARM Getting Started Guide. Right now I have
everything up to the section "Currently Supported ARM Architecture". I was
going to work down to the section title "What is U-Boot", but I am not sure
if that should all be in Introduction.xml or not.
Jared or Pete, do either of you have a working outline for this yet? I
would like to see this document ready for F20.
(I am including the ARM list of this to solicit feedback as well)
[1]: https://fedoraproject.org/wiki/Architectures/ARM/Secret_Decoder_Ring
Zach
10 years, 8 months
My friend git
by John J. McDonough
Chris Wickert posted this link on Facebook:
http://t.co/865gbg2S4o
The biggest take-away from that page is hidden toward the bottom:
Here’s the golden rule of git: if you lose data but you checked
it in somewhere, you can probably recover it. If you didn’t
check it in, you probably can’t. So check in often!
You've heard a lot of us say commit early and commit often - that's why.
I use git for a LOT of my personal stuff. It lets me go back easily
when I've shot myself in the foot (as I do often), and it also lets me
go off on several tangents all at once (yeah, scatterbrained).
I have a "remote" repo on my LAN that I push to as often as I commit.
That way if I happen to be at a different computer I can just clone the
repo and have the same thing I had on the first computer, and if my
laptop should die, my important stuff is in the repo even between
backups.
And not only that, when I have something I want to share with others, I
simply push my LAN remote repo to gitorious and my friends can follow
along.
So get real friendly with git. It isn't just one of those process
things you put up with for your guide, it is an amazing tool.
--McD
10 years, 8 months
Badges
by Pete Travis
So, I'm excited about Badges. It's a lot of fun to pursue them, to come
up with new badge ideas, to collect the one-off badges for bragging
rights. If you don't know, check out https://badges.fedoraproject.org/
and play around for a while.
We've tossed around some ideas for Docs-related badges on IRC, but we're
a relatively asynchronous group and we're doing a lot of echoing each
other and repeating the same ideas. Let's talk about it here on the
list, refine it to something feasible, and open tickets after. This will
work much better than redundantly hassling poor threebean about it :)
Here are some rough ideas, please opine and append:
Commits to Docs repos:
5 commits - Apprentice Wordsmith - simple inkwell graphic
25 commits - Journeyman Scribe - inkwell with scroll
100 commits - Docbook Guru - the Wood Duck, as from the cover of the
O'reilly book, maybe?
500 commits - Master Publican - book graphic, as with the Publican logo
1,000 commits - The Great Senex - reading glasses graphic
-- The high targets here give even our experienced writes something to
aim for. It misses the point if you already have all the badges, right?
Contributions to Release Notes
-- I initially tossed the idea out of watching the Beats wiki pages, but
I now prefer the later suggestion of awarding this one manually - one
badge per release, with pertinent release-name based name and description.
Publishing content:
* to web.git
1 commit - Gutenberg - screw-actuated printing press graphic
5 commits - Stanhope - lever-actuated printing press graphic
20 commits - Koenig - steam actuated printing press graphic
50 commits - Starkweather - laser printing-like graphic
* Yes, I'm proposing a separate badge set for the Publican3 publishing
system. There will probably have to be some switches flipped to enable
that system for fedmsg, if someone knows what to ask for. I'm thinking
something library themed, but it's getting late here and this part isn't
a rush.
--
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
10 years, 8 months
Fedora Docs Meeting Reminder - 1400UTC 18 August 2013
by Pete Travis
Hey Docs Team,
Please join me in meeting at 1400UTC in #fedora-meeting on freenode today, 18 August 2013
Thanks,
--
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
10 years, 8 months
could we fix the scary upload wiki page?
by Matthew Miller
http://fedoraproject.org/wiki/Upgrading
I'm not excatly sure what this page *should* look like, but I just saw
someone give the well-meaning advice that Fedora 17 was the latest release
that one could upgrade to. The big warning sure looks scary.
Now that F18 is our latest supported release, could we tone down the message
a little bit? Something like "You can upgrade to a new Fedora release with
FedUp, which has replaced the old Anaconda-based process." and then a little
later, in a non-warning box, "If you are using an older unsupported version
of Fedora, we recommend backing up your data and overwriting the old
installation with a fresh install."
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10 years, 8 months
[Bug 768731] Transifex file submissions disable f14 and enable f16
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=768731
--- Comment #16 from Pete Travis <me(a)petetravis.com> ---
Right, hub is the term I was searching for. To clarify, I know that a new
project must (at least now, perhaps not always) be created with source lang
'en', or the option to add to the Fedora hub to be available for selection.
It may then be possible to define the transifex configuration for another
source lang, or otherwise work around the issue - if a workaround is even
required.
I suspect it is a technical issue with transifex, and wanted to share to avoid
frustration if it was encountered but unknown.
--
You are receiving this mail because:
You are the assignee for the bug.
10 years, 8 months
