Relicensing
by Paul W. Frields
In relicensing documentation, how do we document relicensing from
authors other than ourselves? For example, I am the sole author of the
mirror-tutorial, so that's a fait accompli. But I'm a contributing
author of the jargon-buster, and at least one of the other folks there
is no longer active in the FDP. As far as I know, it's not possible to
sign away a copyright, so I'd make the following suggestion:
An/the active author or editor should contact all contributing authors,
notify each of the proposed licensing change, including links to
pertinent documentation on the Wiki. Ask each to reply ASAP to
fedora-docs-list(a)redhat.com with a PGP/GPG-signed message approving the
change. If the list does not receive any word back from the authors, we
may have to proceed as on the Wiki -- in other words, removing that
author's contributions as shown in change history (CVS for us).
Any other suggestions or strategies?
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 2 months
Possible edits to the Overview wiki page
by Debbie Deutsch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Folks,
I have been staring at the Overview wiki page. It is the very first
page link in the project FAQ. I am thinking of making some changes to
make it more helpful and understandable to people who are very new to
the open source community. While I can see who has subscribed to the
page, I can't tell who owns it. (I thought page info would tell me
that.) So, I am posting here to see what people think about the
possible edits.
The main idea is to expand the page with some more explanation. There
would be a little restructuring, but nothing as dramatic as breaking up
the page. The additions would do the following:
- - Say a few words about what is open source software and why it is good.
Also, point to one or more references that give more in-depth
discussion about that. (Does anyone have some favorite references about
why open source is good?)
- - Build on the first point by explaining that Fedora contains 100% open
license software. Point out that the open source community frequently
provides equal or better alternatives to propriety software. Make this
point the context for the text that discusses ogg and mp3. Perhaps cite
some additional examples. (Anyone care to suggest some of their favorites?)
Beyond this, every time I look at that page I wonder what a new person,
who has only heard that Fedora is a Linux distribution that is worth
considering, might think about seeing "Freedom:", "Excellence:", and
"How You Can Help:" at the beginning of every line. By context, those
prefixes are organizing the page into sections that are about
a) the project in general and the fact that Fedora is open source
b) why Fedora is a leader in the Linux distribution market
c) how people can contribute to the Fedora project
This may not be entirely obvious to newcomers, especially people who are
so new to the Linux community that the fact that they can contribute to
it is a new idea. So, perhaps I am considering adding a few sentences
about how anyone can contribute to the project, and perhaps brief
paragraph to explain that there are many Linux distributions but we feel
that Fedora is one of the best for the reasons that follow. Given that,
I am thinking that it may be sensible to remove the "Freedom:" prefix
from the few places where it is used. Yes, it is one of the three words
that is used to describe Fedora, but "Infinity" and "Voice" are not
being used as heading prefixes either.
Comments, anyone? I would love to tackle this today or at least during
this nice long weekend. I have some time and the weather is such that
staying indoors and writing would be a fine thing to do.
Debbie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFD914tFsydcHPNKWkRArhIAKCDnXl2WH+hNjEUn2vlip9TVvsRjwCghQIb
7RrvL6YtD6t4U666xdpKAG0=
=6Nhd
-----END PGP SIGNATURE-----
18 years, 2 months
Re: [ANN] Fedora Project Wiki Policy Change
by Karsten Wade
Sorry, rejected this one by mistake, you weren't subscribed to some of
the lists.
Informative for all:
On Fri, 2006-02-17 at 23:27 +1030, n0dalus wrote:
> What should we do if we have already completed the CLA but our wiki
> account has a different username to our bugzilla/accounts system
> account?
The connection between Wiki and CLA is manual, that is, Patrick et al
are looking over the lists and making comparisons. If someone has
wildly different usernames, you'll be asked to sign a CLA, and you can
just reply back that you have one and under what name. Your GPG
signature on that email would seal the deal. :)
We'll be sure to make that point in the email to the people we request a
CLA from.
Thanks - Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months
New target
by Paul W. Frields
I didn't think was worth labeling as an ANN:
There is now a "make txt" target in Makefile.common, so you can generate
plain text versions of your doc (assuming you've updated it to build
correctly as noted in previous email from myself and Tommy). Note that
the current "txt" target strips the <revhistory> and <index> out of a
document -- the former because it is very much in the way of getting to
the text, and the latter because it is essentially useless without the
benefit of linking. Note also that "foonote" type links are not
provided, which jibes with our usage standard of always using the URL as
its own link text. Enjoy!
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 2 months
Re: install-guide/en fdp-info.xml, NONE, 1.1.2.1 fedora-install-guide-abouttoinstall.xml, NONE, 1.1.2.1 fedora-install-guide-acknowledgements.xml, NONE, 1.1.2.1 fedora-install-guide-adminoptions.xml, NONE, 1.1.2.1 fedora-install-guide-beginninginstallation.xml, NONE, 1.1.2.1 fedora-install-guide-bootloader.xml, NONE, 1.1.2.1 fedora-install-guide-diskpartitioning.xml, NONE, 1.1.2.1 fedora-install-guide-firstboot.xml, NONE, 1.1.2.1 fedora-install-guide-installingpackages.xml, NONE, 1.1.2.1 fedora-install-guid
by Tommy Reynolds
Uttered "Scott Glaser" (sonarguy) <fedora-docs-commits(a)redhat.com>, spake thus:
> Author: sonarguy
>
> Update of /cvs/docs/install-guide/en
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29808/en
>
> Added Files:
> Tag: FC5_SAG
> fdp-info.xml
Since "fdp-info.xml" is a derived file, CVS control is not
appropriate.
Cheers
18 years, 2 months
Licensing, what's coming
by Karsten Wade
Oh, this is the most fun email I've written in a while.
This project, Fedora Documentation, is changing our content license to
the OPL without options:
http://opencontent.org/openpub/
The relevant section that we are *not* using is VI. LICENSE OPTIONS.
Lots of questions are answered here:
http://fedoraproject.org/wiki/DocsProject/Licensing/FAQ
Please read that. Anything unanswered, bring it back here and we'll get
it answered and in the FAQ.
Right now we're working on the basics:
* Who doesn't have a CLA?
* What has to be changed?
* Where do we change it?
* How do we get everyone's approval?
* When (how fast) can we do this?
With this change, we are going to be able to use the content from Red
Hat documentation, which is switching to use the same OPL without
options. As a person who knows all of that content intimately, I tell
you that this is going to be a great boost to the Fedora Documentation
Project! No details from that yet, but I'll bring them out as I find
them in digestible form (real food == real facts).
We are not debating the merits of licenses and making decisions for the
Fedora Project on this list. Thankfully we have the Fedora Foundation
board and their lawyer friends to do that for us. We just get the good
results of their decision to implement. FWIW, I'm a fan of the OPL
without options. As a writer/creator, I find it is the cleanest and
most understandable open content license. Hurrah!
Happy writing/tooling/reading/enjoying.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months
Wiki Licensing
by Patrick W. Barnes
The Fedora Documentation Project has agreed to the OPL[1] for all formal
documentation. We now wish to apply this same license to the
fedoraproject.org wiki. This will require some dramatic actions and changes,
and will have a huge impact on contributions to the wiki. The single biggest
change would be the requirement of the CLA for EditGroup privileges. Rather
than make a closed and unilateral decision, this is now briefly open for
discussion. The currently-proposed plan is now on the wiki[2], and this wiki
page is the place to add your comments. You may subscribe to the page if you
wish to keep track of things.
If the decision is made to go through with this plan (and, no, it isn't a
vote), changes would happen quickly. The decision is ultimately up to the
Fedora Foundation board and a few key personnel. The idea already has the
backing of the Fedora Documentation Project, myself, and our top wiki
editors.
[1]
http://fedoraproject.org/wiki/Legal/Licenses/OPL
[2]
http://fedoraproject.org/wiki/WikiLicenseTalk
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
http://www.n-man.com/
--
Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/
18 years, 2 months
[ANN] Shape Of Things To Come
by Tommy Reynolds
My Fellow Contributors,
Now that the FC5t3 Release Notes panic is over, at least for some of
us, it is time to break things agai.. I mean, to add wonderful new
features.
To better fit the process model used by the I18N translating teams,
our file organization and toolchain need to be modified. Previously,
non-English documents have been committed to CVS based on their
translated XML files. However, translators do not work with XML
files the same way that document authors do. Translators use an
intermediate file format known as .POT or .PO files, edit those .PO
files, and then merge the translations back into XML form to produce
the translated XML files; translated XML files do not spring
fully-formed from the mind of Zeus but are derived via merging these
.PO files with the original XML files.
Regrettably, I cannot make all the accomodations necesssary for this
solely in the "Makefile.common" file. Document authors will need to
help. Happily, the changes should be trivial.
Here is a quick summary of the pending changes. Refer to the
"example-tutorial/" document to see the required changes.
1) Only one rpm-info.xml file, and that is in the top-level dir.
"One rpm-info file to rule them all, and in their XML bind them."
2) XML file names are now language independant (para.xml, not
para-en.xml).
This is necessary because the translated XML files are produced
by substituting replacement text directly into the original XML
document files, in an automated process. If referenced XML
files, such as <mediaobjects>, have language-specific names, the
translated XML file will reference the wrong picture.
Therefore, all filenames must not contain a "*-${LANG}.xml"
component.
3) The "Makefile" in the document directory has been completely
rewritten.
Since translated XML files are automatically created, the
original document language must be separated from the enumeration
of the translated locales.
A ${PRI_LANG} variable identifies the original language for
the document. Additional language translations are listed in the
${OTHERS} macro. The ${XMLEXTRAFILES-${LANG}} variable is no
more; instead an XMLFILES_template must be filled out to
enumerate the necessary XML files.
4) Translated XML files are automatically generated from .POT and
.PO files located in a "po/" directory.
The "po/" file need not exist until translations are created and
the ${OTHERS} "Makefile" list populated. The "po/" directory
must be under CVS control.
5) Translated XML files should NOT be archived in CVS, since they
are now generated files.
There should be real XML files in the "${PRI_LANG}/" directory
and that directory should be under CVS control.
Directories and files for the translations enumerated in the
${OTHERS} list are dynamically created and destroyed. For
example, if ${OTHERS} is defined as:
OTHERS=de no it ru
Then directories "de/", "no/", "it/", "ru/" need NOT exist and
should NOT be placed under CVS control.
XML files such as "de/example-tutorial.xml" will be dynamically
created from the "en/example-tutorial.xml",
"po/example-tutorial.pot", and "po/de.xml" files and should NOT
be placed under CVS control.
6) Many new virtual targets have been added to "Makefile.common",
such as "make xml-de", "make po-de", and the like.
Consult the "Makefile.common". You'll just have to look ;-)
As always, comments, suggestions, patches and bribes are cheerfully
accepted.
Cheers
18 years, 2 months
Minutes of FDSCo Meeting 14 February 2006
by Stuart Ellis
Attending Members:
------------------
Karsten Wade (quaid)
Tommy Reynolds (megacoder)
Paul Frields (stickster)
Gavin Henry (G2)
Stuart Ellis (elliss)
Also Participating:
-------------------
Patrick Barnes (nman64)
Ignacio Vazquez-Abrams (ignacio)
Schedule of Tasks:
------------------
http://www.fedoraproject.org/wiki/DocsProject/FedoraDocsSchedule
Highlights:
-----------
* Karsten: Fedora documentation to be relicensed under the OPL. The
optional "no-modification" clause will not be used, to ensure that the
documentation is freely modifiable as well as being freely
distributable.
The Wiki content will also be explicitly licensed under the OPL. This
requires the agreement of contributors. Each contributor to the Wiki
will be contacted for their approval.
Preliminary information is on Karsten's blog entry for February 14:
http://fedora.linux.duke.edu/fedorapeople/
More information to be posted on the Documentation mailing list shortly.
* Karsten: The documentation maintained by Red Hat is to be relicensed
to match the new Fedora documentation licensing. This will include the
Directory Server documentation, as well as the documentation for Red Hat
Enterprise Linux.
The common license will enable Red Hat Content Services and outside
contributors to collaborate through Fedora. It will also enable the
documentation to be redistributed with Fedora.
* Tommy: Documentation translators have agreed to transition to the PO
method of providing translations.
* Paul: A start page is required for the desktop help browsers. The
files will need to be included in the fedora-release package.
This bug tracks progress:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170847
Full IRC Log:
-------------
https://www.redhat.com/archives/fedora-dsco-list/2006-February/msg00012.html
--
Stuart Ellis
stuart(a)elsn.org
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
GPG key ID: 7098ABEA
GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA
18 years, 2 months
cvs import...
by Francesco Tombolini
During the configuration of cervisia, I do an import...
please, can someone help me to revert the previous condition?
Sorry
--
Francesco Tombolini <tombo(a)adamantio.net>
18 years, 2 months