[fedora-badges] #259: Fedora Cookbook Contributions
by fedora-badges
#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
7 years, 9 months
[Bug 1008149] New: Contraficting info about the need of shared storage for storing guest images to be migrated
by Red Hat Bugzilla
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...
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
8 years, 1 month
[Bug 846864] New: Need a list of toolsets and when they are appropriate in the virt Getting Started guide
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=846864
Bug ID: 846864
QA Contact: docs-qa(a)lists.fedoraproject.org
Severity: unspecified
Version: devel
Priority: unspecified
CC: docs(a)lists.fedoraproject.org
Assignee: laine(a)redhat.com
Summary: Need a list of toolsets and when they are appropriate
in the virt Getting Started guide
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: laine(a)redhat.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: virtualization-getting-started-guide
Product: Fedora Documentation
The Getting Started Guide needs an overview of all the different toolsets, and
when each would be appropriate. In particular I'm talking about the following:
1) gnome-boxes
2) virt-manager
3) virsh, virt-install
4) ovirt
5) Should we point some people to OpenStack?
I will write up a first draft of this, and hand it to a qualified docs person
to edit and correctly place in the guide.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 5 months
RFC: docs website layout demo
by Jeff Fearn
Hi, Rudi asked me to do a demo of how Fedora could make a rebuilt docs website look, so I've made a demo site & tweaked it a bit. Before I spend too much effort on it I thought I'd open it up for input.
I wanted to get a bit more done before the weekend, but time slipped away. I wanted to get it out for some feedback over the weekend so I can do some more on Monday, so I'd thought I'd just put it out there and hope people can understand it is only half baked.
Some of the stuff I did for this I liked so I've started migrating the template changes back in to publican, leaving this site with just some colour changes on what a default web_style 2 site will look like. I'll update my fedora people site next week so show what a default site will look like.
I've made a script to pull out most of the docs packages from git, and run through a bunch of branches per book, and try to build them with the latest publican. I'll make the script available next week for people who want to build their own copy. It should be useful to QA the process as it spits out a log file out for each repo and branch so you can get a good list of what's broken and what's not. I'll also put those up on my fedora people site next week ... If I have any quota left :D
Demo site is https://jfearn.fedorapeople.org/fdocs/en-US/index.html
I think this is a pretty good layout https://jfearn.fedorapeople.org/fdocs/en-US/index.html#Fedora
Colours are hard :-/
Note if you click a group, below the versions, then it filters out all the other groups.
Note that in the "System administration" group for Fedora 20 there is an external link "The Ways And Means Of Pants" which is a fake URL, if you have a couple of examples of real external links you'd like in that group, or any other group, I'd be happy to swap out the fake one.
I haven't changed the brand XSL for the html payload, I'd like to remove the old left and right logos at the top of the pages. They aren't really needed given the menu content.
e.g. https://jfearn.fedorapeople.org/fdocs/en-US/Fedora/20/html/Installation_G...
bah I just noticed a bug on that page, the first two items in the navigation menu are swapped ... :(
I'm sure there are lots more :}
I've built html, html-single, epub & pdf.
The site is only in en-US, it's 417M and I'm not sure the hosting people would be happy if I hosted more languages :)
Anyway, it's Friday evening and the wine is calling, please reply if you have any ideas or feedback, beware that I'm currently hacking on the publican devel branch, so I might steal any really cool ideas for publican.next ;)
Cheers, Jeff.
P.S. All the RSS feeds on there should work, but you probably do not want to sign up for that site!
8 years, 7 months
Fedora Working Group Writers
by Pete Travis
Hi all,
The Fedora 21 release is a huge accomplishment for us and the Fedora
Project as a whole. We have a new lineup of deliverables[0], a new
organizational structure[1], and a new leadership body[2]. Some of the
changes have been hard to miss, and some have had subtle impacts; all of
them promise continuing change for Fedora's users and contributors.
To keep up, we should rethink the work that we do, and the service we
provide to the user and developer community. Okay, I'll address the
obvious caveat before getting into it: We're all volunteers, probably
already putting in the time we have available, working on things of
unquestionable value. We've done a fair job of improving our welcome
for newcomers. That said, a lot of our work is structured for
yesterday's grab-bag Fedora, not today's product-ized (flavorized?
editioned?) Fedora. We should be looking at what we can do to better
represent the Workstation, Server, or Cloud images being offered to the
users, and better support the majority of developers whose work isn't in
those default package sets.
I would like to hear everyone's thoughts on where the fedora.next path
should lead the Docs Project - especially those of you that are
subscribed but haven't been active lately. Your perspective might
provide some valuable contrast.
My idea so far is a simple one. We have three deliverable-oriented
working groups, and there should be a bridge between these groups and
Docs. We should provide that bridge by volunteering to actively
communicate with and monitor the working groups. They might be fine
with just a simple list in the Release Notes, or they might enjoy having
a fully developed guide to their work, or want more than we can actually
fulfill, or they don't know what they want yet. We can't know without a
solid channel for ideas to flow though.
These are dynamic and active groups, and keeping up with them will be a
considerable time investment. For some perspective, here's where you
should watch for, and participate in, the action:
- #fedora-devel, #fedora-cloud, #fedora-server, #fedora-workstation,
others on freenode[3]
- related channels, like #cockpit or #fedora-desktop on irc.gnome.org[4]
- Lots of Fedora mailing lists. devel@, desktop@, infra@, releng@,
server@[5]
- Trac instances for each working group, infra, releng, and FESco[6]
- "watching" wiki pages maintained by each group.
- "watchcommits" and "watchbugzilla" on pivotal packages in pkgdb[7]
- upstream mailing lists and commit flows
- ... then write it down somewhere :)
It's really a lot to go through. Hopefully, there are some folks
already in tune, or people looking for a good way to contribute, that
can jump in, at least one per working group. If not, let's talk about
dividing some of this up to make it work. Docs will produce much better
results if we're organized about how we discover the material.
[0] https://getfedora.org
[1] http://fedoraproject.org/wiki/Fedora.next
[2] https://fedoraproject.org/wiki/Council
[3] https://fedoraproject.org/wiki/Communicating_and_getting_help
[4] https://wiki.gnome.org/Community/GettingInTouch/IRC
[5] https://lists.fedoraproject.org/mailman/listinfo
[6] https://fedorahosted.org/web/
[7] https://admin.fedoraproject.org/pkgdb
--
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
8 years, 10 months
Request for a Zanata update
by Robert Antoni Buj i Gelonch
I've translated some documents into Catalan language using zanata
translation portal, but when I was reviewing the translations I saw some
messages as untranslated.
Please, can you update the translations in Zanata? Then, I will translate
the messages that aren't displayed as translated. I use the upstream source
to review the translations.
Translated documents:
elections-guide
openssh-guide
release-notes
technical-notes
Review process:
git clone https://git.fedorahosted.org/git/docs/upstream-doc.git
cd upstream-doc
zanata-cli -B pull --src-dir=./ --trans-dir=./ -l ca
publican build --formats=html-single,pdf --langs=ca
Regards,
Robert
--
http://about.me/rbuj
8 years, 10 months
DNF is the default for F22
by Pete Travis
Barring contingencies, dnf has been approved[0] as the default package
manager for Fedora 22 and subsequent releases. dnf is effectively a
complete rewrite of yum and the underlying dependency solving logic, so
it's a substantial change. If you have been using it, and especially if
you've been following bug reports[1], you probably know that the
behavior of dnf can differ[2] subtly or surprisingly from what we've
come to expect from yum.
Because of the potential confusion, I propose that we make documenting
dnf a priority for the F22 release. Specifically, the System
Administrators Guide deals with package management the most, but
essentially *every* guide will have scattered yum invocations. Let's
branch each guide slated for F22, work through the changes, then review
and merge the branch. The System Administrators guide is going to really
need some special attention, as it should probably address all the
quirks and snags that users will run into.
This is an excellent opportunity for new contributors. For most guides,
the changes required are very straightforward. It would be a
closed-ended endeavor and a manageable time investment - *if* we start
soon. If you're able to take on a guide, please reply.
[0] https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
[1] https://bugzilla.redhat.com/buglist.cgi?component=dnf&product=Fedora
[2] http://dnf.readthedocs.org/en/latest/cli_vs_yum.html
--
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
8 years, 10 months
