free formats, CodecBuddy, and how you can help
by Karsten Wade
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
16 years, 6 months
FDSCo Meeting 2007-10-14 Summary
by John Babich
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
16 years, 6 months
FDSCo Meeting 2007-10-14 IRC Log
by John Babich
<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-...
<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
16 years, 6 months
Self-Introduction: Zembutsu Masahito
by Zembutsu Masato
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
16 years, 6 months
Self-Introduction: Marc Wiriadisastra
by Marc Wiriadisastra
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
16 years, 6 months
CN=Darren Fields/OU=london/O=glen is out of the office.
by Darren.Fields＠glencore.co.uk
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.
16 years, 6 months
Fedora Documentation Platform
by Jonathan Steffan
-----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-----
16 years, 6 months
Setting the sights
by Paul W. Frields
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
16 years, 6 months
Release Notes sync
by Paul W. Frields
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
16 years, 6 months
admin guide contributions
by Murray McAllister
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]
16 years, 6 months
