4:34 p.m.
I've been discussing Publican problems since December of 2008. Many
have been discussing it longer. At tonight's (today's) Docs Project
meeting we will discuss Publican and how to go forward. Right now I can
see five options for moving forward:
1. Use Publican for a guide but munge through to an RPM that Fedora will
consume; use jjmcd's script or a new .spec file
2. Fork Publican and remove the variable that puts the version # in the
name
3. Get the Packaging Committee to amend the rules
4. Use Publican for HTML + PDF and fedora-doc-utils for RPM
5. Use f-doc-utils exclusively
Be thinking about this for tonight's meeting.
Thanks,
Eric
6:10 p.m.
----- Original Message -----
From: "Eric Christensen" <eric(a)christensenplace.us>
To: <fedora-docs-list(a)redhat.com>
Sent: Wednesday, March 25, 2009 5:34 PM
Subject: Publican Issues
meeting we will discuss Publican and how to go forward. Right now I
can
see five options for moving forward:
1. Use Publican for a guide but munge through to an RPM that Fedora will
consume; use jjmcd's script or a new .spec file
2. Fork Publican and remove the variable that puts the version # in the
name
3. Get the Packaging Committee to amend the rules
4. Use Publican for HTML + PDF and fedora-doc-utils for RPM
5. Use f-doc-utils exclusively
Let me provide some pre-meeting input here.
Last week I got thinking that I needed to learn more about how we implement
multiple languages. It wasn't clear to me that Publican creates these
various languanges in the same way f-doc-utils does, and I wanted to be
confident that I could come up with an equivalent RPM. I was very confident
about a single-language RPM, but I just don't understand how the language
gets selected.
So I tried to add a couple of languages to the F11 release notes and I kept
getting errors. I also tried making a small Publican doc and adding
languages, same errors. I fought this for a while without success, but last
night rudi grabbed my sources and discovered that the error was a known bug
(I had just assumed I was doing something wrong) to be fixed in 0.44. He
had a workaround, and I was able to get Publican to generate RPMs for my
test languages.
Well, that is the first problem. Publican generates an RPM per language.
Probably not insurmountable to munge these together, especially if we are
rebuilding the RPM. But I ran into some strangeness. It looks as if during
the rpmbuild Publican treats the non-English languages differently. I still
have more to explore to completely understand this, but it does make me less
confident that we can beat it into submission quickly.
That being said, I still, for obvious selfish reasons, lean toward
Publican-oriented solutions as opposed to f-docs-utils solutions. Even if
we have to use a forked Publican, I think we are better positioned for F12
when we might have our needs rolled back in.
--McD
9:07 p.m.
John J. McDonough wrote:
----- Original Message ----- From: "Eric Christensen"
<eric(a)christensenplace.us>
To: <fedora-docs-list(a)redhat.com>
Sent: Wednesday, March 25, 2009 5:34 PM
Subject: Publican Issues
> meeting we will discuss Publican and how to go forward. Right now I can
> see five options for moving forward:
>
> 1. Use Publican for a guide but munge through to an RPM that Fedora will
> consume; use jjmcd's script or a new .spec file
> 2. Fork Publican and remove the variable that puts the version # in the
> name
No need to do this, I'll move a copy internal and you can have the fedora
hosted repo if you want.
> 3. Get the Packaging Committee to amend the rules
Good luck getting the blind to see.
> 4. Use Publican for HTML + PDF and fedora-doc-utils for RPM
> 5. Use f-doc-utils exclusively
Let me provide some pre-meeting input here.
Last week I got thinking that I needed to learn more about how we
implement multiple languages. It wasn't clear to me that Publican
creates these various languanges in the same way f-doc-utils does, and I
wanted to be confident that I could come up with an equivalent RPM. I
was very confident about a single-language RPM, but I just don't
understand how the language gets selected.
So I tried to add a couple of languages to the F11 release notes and I
kept getting errors. I also tried making a small Publican doc and
adding languages, same errors. I fought this for a while without
success, but last night rudi grabbed my sources and discovered that the
error was a known bug (I had just assumed I was doing something wrong)
to be fixed in 0.44. He had a workaround, and I was able to get
Publican to generate RPMs for my test languages.
0.44 is in the testing repo waiting for enough karma to be pushed live. I
asked for it to be pushed live.
Well, that is the first problem. Publican generates an RPM per
language. Probably not insurmountable to munge these together,
especially if we are rebuilding the RPM. But I ran into some
strangeness. It looks as if during the rpmbuild Publican treats the
non-English languages differently. I still have more to explore to
completely understand this, but it does make me less confident that we
can beat it into submission quickly.
In the SVN repo look at old_srpm2 and old_spec2 in
publican-redhat/make/Makefile.Redhat. This is how we used to publish docs
for RHEL5. The related xsl files are in publican-redhat/xsl/
It very quickly became an unmaintainable approach for books of any size.
People get really pissed when they have to d/l 200MB to get a typo fixed
when they only read 1 language. This will be exacerbated for fedora where
many more languages are supported.
This is only kept around because we have to support the shipped books, it
really is a sub optimal distribution method and limits you ability to have
nifty yum groups and such.
i.e. 'yum installgroup latin-docs' for all you Latin docs needs.
Marginally useful for Release Notes for obvious reasons, however, being
able to ship the English to beta testers before the translations is likely
reduce the impact of errata on translations should they occur.
Cheers, Jeff.
--
Jeff Fearn <jfearn(a)redhat.com>
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom ... courage ... Commitment ... ACCOUNTABILITY
12:47 a.m.
Rahul Sundaram wrote:
Jeff Fearn wrote:
>>> 3. Get the Packaging Committee to amend the rules
>>>
> Good luck getting the blind to see.
>
We as a community need to show more respect for each other. Even if you
disagree with something, this is not the way to go about resolving it.
Rahul
Being a roadblock is not resolving it either. There is working with
developers and there is actively working against them. Respect is earnt,
not given to the wanting.
Just my .02AUD
1:02 a.m.
Christopher Curran wrote:
>
Being a roadblock is not resolving it either. There is working with
developers and there is actively working against them. Respect is earnt,
not given to the wanting.
How have you tried to solve the issue so far? Who have you approached?
All is I see is rude remarks and sarcasm. Nothing constructive. That's a
failure even before you get started.
Rahul
1:06 a.m.
Rahul Sundaram wrote:
Christopher Curran wrote:
>>
>>
> Being a roadblock is not resolving it either. There is working with
> developers and there is actively working against them. Respect is earnt,
> not given to the wanting.
>
How have you tried to solve the issue so far? Who have you approached?
All is I see is rude remarks and sarcasm. Nothing constructive. That's a
failure even before you get started.
Rahul
I'm a lurker. I sit and watch most of the time. My development and
documentation work probably sits off your radar. It's where I prefer to
stay because the more I have to deal with the fedora established
bureaucracy the less I want to have anything to do with fedora. I am
doing constructive work for fedora, I just have nothing to do with
packaging most of the time. Those two things are related.
Chris
1:16 a.m.
Christopher Curran wrote:
>
I'm a lurker. I sit and watch most of the time. My development and
documentation work probably sits off your radar. It's where I prefer to
stay because the more I have to deal with the fedora established
bureaucracy the less I want to have anything to do with fedora. I am
doing constructive work for fedora, I just have nothing to do with
packaging most of the time. Those two things are related.
Nobody is forcing you to work on Fedora but if you or anybody else here
want to solve any problems, you got to be a lot more specific about your
issues and work on resolving them constructively. Where have you raised
your issues?
Rahul
1:09 a.m.
Christopher Curran wrote:
Rahul Sundaram wrote:
> Jeff Fearn wrote:
>
>>>> 3. Get the Packaging Committee to amend the rules
>>>>
>> Good luck getting the blind to see.
>>
>
> We as a community need to show more respect for each other. Even if you
> disagree with something, this is not the way to go about resolving it.
>
> Rahul
>
>
Being a roadblock is not resolving it either. There is working with
developers and there is actively working against them. Respect is earnt,
not given to the wanting.
Considering that I don't even know what the problem is and no one who's
swinging the hate bat has yet to clarify that on this list or the
packaging list (where everyone in the FPC will see it rather than just
the one randomly subscribed to this list.) It's hard to see how I can
act as a very effective roadblock.
One note, though: while the FPC tries to implement goals in a way that's
as easy as possible for the developers involved, the goals themselves
are primarily about getting high quality packages to end-users, not
making developers lives easier. If you have a suggestion for
implementing a goal in a way that is easier for packagers, by all means
make it. If you just want to complain about how doing things the right
way takes time then you're going to find your complaints get no respect.
Respect, after all, is earned.
-Toshio
1:19 a.m.
Toshio Kuratomi wrote:
Christopher Curran wrote:
> Rahul Sundaram wrote:
>
>> Jeff Fearn wrote:
>>
>>
>>>>> 3. Get the Packaging Committee to amend the rules
>>>>>
>>>>>
>>> Good luck getting the blind to see.
>>>
>>>
>> We as a community need to show more respect for each other. Even if you
>> disagree with something, this is not the way to go about resolving it.
>>
>> Rahul
>>
>>
>>
> Being a roadblock is not resolving it either. There is working with
> developers and there is actively working against them. Respect is earnt,
> not given to the wanting.
>
>
Considering that I don't even know what the problem is and no one who's
swinging the hate bat has yet to clarify that on this list or the
packaging list (where everyone in the FPC will see it rather than just
the one randomly subscribed to this list.) It's hard to see how I can
act as a very effective roadblock.
One note, though: while the FPC tries to implement goals in a way that's
as easy as possible for the developers involved, the goals themselves
are primarily about getting high quality packages to end-users, not
making developers lives easier. If you have a suggestion for
implementing a goal in a way that is easier for packagers, by all means
make it. If you just want to complain about how doing things the right
way takes time then you're going to find your complaints get no respect.
Respect, after all, is earned.
-Toshio
I think that Jeff and Chris are referring to this:
https://bugzilla.redhat.com/show_bug.cgi?id=476471
and possibly this as well:
https://bugzilla.redhat.com/show_bug.cgi?id=482972
Josh
--
Joshua J Wulf
Engineering Content Services
Red Hat Asia Pacific
eml: jwulf(a)redhat.com
tel: +61 (0)7 3514 8140
mob: +61 (0)431 929 675
tmz: GMT +10
(0) - omit when dialling internationally
2:12 a.m.
Joshua Wulf wrote:
Thanks Joshua,
I think that Jeff and Chris are referring to this:
https://bugzilla.redhat.com/show_bug.cgi?id=476471
IIUC, this boils down to:
1) Publican creates a different documentation package for each Fedora
Release as it considers them to be separate documents. ie:
Fedora-10-Security-Guide, Fedora-11-Security-Guide.
2) This means a new package review for each documentation package each
release.
If you're willing to go through a new review each release, there's no
problem.
If you want a single review to cover you for all releases, we need a new
Guideline. I think if it's a potential goal to be able to install the
Fedora-10-Security-Guide on Fedora-11, then I'd be against such a
Guideline as separate packages really are what you want. If it's
specifically a non-goal to do that, then it's a possibility although
changing the name to not have the version in it strikes me as the better
option there. Following onto that, I'm not sure why you wouldn't want
to use publican to create an initial spec file and then modify it to
meet the specifics of the situation. This is the workflow for CPAN2RPM,
rpmdev-newspetemplate, and other tools.
Another option is to look at a streamlined set of review items for
publican-created doc packages... We've never explicitly done this but in
practice, people know they don't have to check, for instance, shared
library guidelines when writing and reviewing a pure python module.
and possibly this as well:
https://bugzilla.redhat.com/show_bug.cgi?id=482972
What's the problem here? That the .desktop is created inline in the
spec file instead of as a separate file? If that's all it is, I can
propose to the FPC to amend that. I can't recall a reason that it had
to be included in the SRPM as a file specifically.
Note that neither of these issues had reached the FPC's radar (they
still haven't, really, as I'm only one member and this isn't the
packaging mailing list) so blaming the FPC as the roadblock is a bit
misplaced.
-Toshio
2:31 a.m.
Thanks for your response and suggestions Toshio.
I think it's more venting frustration than actually blaming the FPC for
being a roadblock.
*Anything* that we can do to resolve these issues, keeping in mind the
limited resources we are working with and the need to work together and
forge stronger relationships going forward, will be great.
Josh
Toshio Kuratomi wrote:
Joshua Wulf wrote:
Thanks Joshua,
> I think that Jeff and Chris are referring to this:
> https://bugzilla.redhat.com/show_bug.cgi?id=476471
>
>
IIUC, this boils down to:
1) Publican creates a different documentation package for each Fedora
Release as it considers them to be separate documents. ie:
Fedora-10-Security-Guide, Fedora-11-Security-Guide.
2) This means a new package review for each documentation package each
release.
If you're willing to go through a new review each release, there's no
problem.
If you want a single review to cover you for all releases, we need a new
Guideline. I think if it's a potential goal to be able to install the
Fedora-10-Security-Guide on Fedora-11, then I'd be against such a
Guideline as separate packages really are what you want. If it's
specifically a non-goal to do that, then it's a possibility although
changing the name to not have the version in it strikes me as the better
option there. Following onto that, I'm not sure why you wouldn't want
to use publican to create an initial spec file and then modify it to
meet the specifics of the situation. This is the workflow for CPAN2RPM,
rpmdev-newspetemplate, and other tools.
Another option is to look at a streamlined set of review items for
publican-created doc packages... We've never explicitly done this but in
practice, people know they don't have to check, for instance, shared
library guidelines when writing and reviewing a pure python module.
> and possibly this as well:
> https://bugzilla.redhat.com/show_bug.cgi?id=482972
>
>
What's the problem here? That the .desktop is created inline in the
spec file instead of as a separate file? If that's all it is, I can
propose to the FPC to amend that. I can't recall a reason that it had
to be included in the SRPM as a file specifically.
Note that neither of these issues had reached the FPC's radar (they
still haven't, really, as I'm only one member and this isn't the
packaging mailing list) so blaming the FPC as the roadblock is a bit
misplaced.
-Toshio
--
Joshua J Wulf
Engineering Content Services
Red Hat Asia Pacific
eml: jwulf(a)redhat.com
tel: +61 (0)7 3514 8140
mob: +61 (0)431 929 675
tmz: GMT +10
(0) - omit when dialling internationally
7:48 a.m.
On Thu, 2009-03-26 at 00:12 -0700, Toshio Kuratomi wrote:
Joshua Wulf wrote:
Thanks Joshua,
> I think that Jeff and Chris are referring to this:
> https://bugzilla.redhat.com/show_bug.cgi?id=476471
>
IIUC, this boils down to:
1) Publican creates a different documentation package for each Fedora
Release as it considers them to be separate documents. ie:
Fedora-10-Security-Guide, Fedora-11-Security-Guide.
2) This means a new package review for each documentation package each
release.
If you're willing to go through a new review each release, there's no
problem.
And that's okay for certain documents (i.e. Release Notes, User
Guide,...) that are tied directly to a specific release of Fedora. The
Security Guide, however, is not. I'd much prefer the Security Guide
being just that, the Fedora Security Guide and not have to go through
review for each release.
So while it might be nice to include a release number in the package for
some documents it is not appropriate for all. Publican does not provide
that ability to not use the release number and if it did, and there were
writers who wanted to use the release numbering, I would have already
petitioned the FPC on behalf of the Docs Project to make the change.
So, no, the problem isn't with the FPC's decisions or current rules.
Eric
2:19 a.m.
Joshua Wulf wrote:
>
I think that Jeff and Chris are referring to this:
https://bugzilla.redhat.com/show_bug.cgi?id=476471
Comment #58 by Jens Petersen:
I am not veto'ing parallel install per se, but maybe it is worth considerng
what is so special about docs packages that warrants/necessitates parallel
install since we don't really do this for any other packages except
libraries/tools needed occasionally for back-compatibility.
The idea here is that people who are using Fedora in a production
capacity, rather than just as a beta test of RHEL, are able to install
multiple documentation sets.
The use case would be like this:
I'm a system administrator with a number of different servers on my
network running different versions of Fedora. Some are internal servers
and running the ancient Fedora 10. There is one running Fedora 15 that
I'm intending to upgrade later. The ones on the firewall I run at
latest-1, and are currently on Fedora 19. I'm running Fedora 20 on my
personal workstation, and I have a virtual machine running Fedora Rawhide.
On my Fedora 20 workstation I have the documentation for all of these
different versions installed (F10, F15, F19, F20, Rawhide), so that I
can refer to the relevant docs in my graphical user environment as I
administer them remotely via ssh.
That's the idea. It doesn't make much sense if you envision Fedora as a
RHEL beta test that you scrap each time a new version comes out, but if
it's a viable OS that can be deployed and used in a production capacity
like that described above, parallel documentation installation will be
useful.
What are your thoughts on this?
Josh
--
Joshua J Wulf
Engineering Content Services
Red Hat Asia Pacific
eml: jwulf(a)redhat.com
tel: +61 (0)7 3514 8140
mob: +61 (0)431 929 675
tmz: GMT +10
(0) - omit when dialling internationally
2:54 p.m.
On Thu, Mar 26, 2009 at 05:19:33PM +1000, Joshua Wulf wrote:
[snip reasonable use case]
That's the idea. It doesn't make much sense if you envision
Fedora as a
RHEL beta test that you scrap each time a new version comes out, but if
it's a viable OS that can be deployed and used in a production capacity
like that described above, parallel documentation installation will be
useful.
I find it to be a reasonable use case. Personally, I would move the
version number after the word "Fedora", to make it clear it is about the
version of the OS not the version of the document. Otherwise, the
reason for the implementation makes sense.
In fact, I doubt anyone will argue against the use case. The issue is
that the use case did not surface until the last few weeks, although
obviously it has been part of the Publican design scheme for some
time. It is rather late in the Fedora 11 lifecycle to make all of
this work, but that doesn't mean it's impossible. Just much more
"hurry up" work than should have been done.
Preferably, IMO, Publican makes it an option to include the version
number in the package or document name, for reasons well stated
elsewhere.
- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
6:22 p.m.
Eric Christensen wrote:
I've been discussing Publican problems since December of 2008.
Many
have been discussing it longer. At tonight's (today's) Docs Project
meeting we will discuss Publican and how to go forward. Right now I can
see five options for moving forward:
1. Use Publican for a guide but munge through to an RPM that Fedora will
consume; use jjmcd's script or a new .spec file
2. Fork Publican and remove the variable that puts the version # in the
name
3. Get the Packaging Committee to amend the rules
4. Use Publican for HTML + PDF and fedora-doc-utils for RPM
5. Use f-doc-utils exclusively
Be thinking about this for tonight's meeting.
Thanks,
Eric
6. Remove the release notes from anaconda. <<To me this is the most
logical solution as most users do not want to waste more time installing
than they already must.
7. Branch stack the packaging committee out with people who adhere to
more liberal packaging guidelines.
Chris
--
Chris Curran
Technical Writer for Virtualization and Emerging Technologies
Phone: +61735148302 (UTC+10)
Brisbane, Australia. Red Hat, Inc.
2:58 p.m.
On Thu, Mar 26, 2009 at 09:22:09AM +1000, Christopher Curran wrote:
6. Remove the release notes from anaconda. <<To me this is the
most
logical solution as most users do not want to waste more time installing
than they already must.
The release notes have been removed from Anaconda for several releases
of Fedora. Unless you mean something else?
7. Branch stack the packaging committee out with people who adhere to
more liberal packaging guidelines.
Must ... not ... feed ... the ... trolls ...
- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
8:10 p.m.
Karsten Wade wrote:
On Thu, Mar 26, 2009 at 09:22:09AM +1000, Christopher Curran wrote:
> 6. Remove the release notes from anaconda. <<To me this is the most
> logical solution as most users do not want to waste more time installing
> than they already must.
>
The release notes have been removed from Anaconda for several releases
of Fedora. Unless you mean something else?
They are removed now? That's awesome. I haven't noticed as all I've
been doing is automated installs.
8:57 a.m.
Name: Wolf DreamWalker (not a pseudonym)
Location: Toronto, Ontario, Canada
Profession: Software Trainer
Company: Currently enrolled in the Technical Communications program at Seneca@York,
Toronto
Background
Comfortable with Windows desktop and server products - certified systems engineer
Have
several years experience developing and presenting learning materials
to university students and workers within technical areas of various
companies.Have tested fan created missions for games such as Thief and even delved in
creating some of the readables.
Great
believer in KIS (keep it simple) and have found that screen shots, etc.
are excellent learning tools for those of us who are not computer
naturals
Knowledge of Linux / Fedora
Absolute
Newbie ... less than a week old. I'm somewhat intimidated by the new
concepts and perceptions encompassing Fedora but I'm excited to be able
to dig into a few area of expertise.
I've
jumped in with a dual-boot install. I thought that all I had to do was
to install Fedora on freed-up space on a single hard drive already
occupied by Microsoft Vista. However, I soon discovered that the two
systems handle "primary" drives somewhat differently and that the only
way I could get a viable working copy of Fedora on my computer was to
install it on what Vista designated as part of the "extended" drive
(this variant doesn't appear to be addressed in the installation guide).
Goals - Where I could help
Since I'm so new to Linux and Fedora I am less likely to miss or
overlook steps that a Fedora expert takes for granted. I'm also more
likely to query what appears to be outdated documentation (e.g. the
software's recommendation to follow what is actually a mandatory
procedure to create a user name and password during installation). At
the same time, I recognize I have somewhat of a learning curve to
overcome so probably the best place to use me is in testing and editing
of current material.
Availability
I'm between semesters and have plenty of free time between now and May
9 to devote myself to this project (at least 40 hrs a week). When I
return to school my time will be limited to only a few hours a week.
Wolf
GPG KEYID and fingerprint
Name: Wolf DreamWalker
Email: wolfdreamwalker(a)hotmail.com
ID: 3117A6BC / DSA / 1024
Created: 2009-03-26
Fingerprint:1462 3928 AF44 6770 F616 925D 6EA6 B659 3117 A6BC
Subkeys:6EA6B6593117A6BC (DSA),A0D3380DAD91D537 (EIGamal)
_________________________________________________________________
Share photos with friends on Windows Live Messenger
http://go.microsoft.com/?linkid=9650734
9 a.m.
New subject: Self Introduction
Whoops ... forgot to change the subject title
From: wolfdreamwalker(a)hotmail.com
To: fedora-docs-list(a)redhat.com
Date: Fri, 27 Mar 2009 09:57:56 -0400
Subject: RE: Publican Issues
Name: Wolf DreamWalker (not a pseudonym)
Location: Toronto, Ontario, Canada
Profession: Software Trainer
Company: Currently enrolled in the Technical Communications program at Seneca@York,
Toronto
Background
Comfortable with Windows desktop and server products - certified systems engineer
Have
several years experience developing and presenting learning materials
to university students and workers within technical areas of various
companies.Have tested fan created missions for games such as Thief and even delved in
creating some of the readables.
Great
believer in KIS (keep it simple) and have found that screen shots, etc.
are excellent learning tools for those of us who are not computer
naturals
Knowledge of Linux / Fedora
Absolute
Newbie ... less than a week old. I'm somewhat intimidated by the new
concepts and perceptions encompassing Fedora but I'm excited to be able
to dig into a few area of expertise.
I've
jumped in with a dual-boot install. I thought that all I had to do was
to install Fedora on freed-up space on a single hard drive already
occupied by Microsoft Vista. However, I soon discovered that the two
systems handle "primary" drives somewhat differently and that the only
way I could get a viable working copy of Fedora on my computer was to
install it on what Vista designated as part of the "extended" drive
(this variant doesn't appear to be addressed in the installation guide).
Goals - Where I could help
Since I'm so new to Linux and Fedora I am less likely to miss or
overlook steps that a Fedora expert takes for granted. I'm also more
likely to query what appears to be outdated documentation (e.g. the
software's recommendation to follow what is actually a mandatory
procedure to create a user name and password during installation). At
the same time, I recognize I have somewhat of a learning curve to
overcome so probably the best place to use me is in testing and editing
of current material.
Availability
I'm between semesters and have plenty of free time between now and May
9 to devote myself to this project (at least 40 hrs a week). When I
return to school my time will be limited to only a few hours a week.
Wolf
GPG KEYID and fingerprint
Name: Wolf DreamWalker
Email: wolfdreamwalker(a)hotmail.com
ID: 3117A6BC / DSA / 1024
Created: 2009-03-26
Fingerprint:1462 3928 AF44 6770 F616 925D 6EA6 B659 3117 A6BC
Subkeys:6EA6B6593117A6BC (DSA),A0D3380DAD91D537 (EIGamal)
Tell the whole story with photos, right from your Messenger window. Learn how!
_________________________________________________________________
Chat with the whole group, and bring everyone together.
http://go.microsoft.com/?linkid=9650735
9:15 a.m.
New subject: Self Introduction
Welcome!
With the Fedora 11 Beta scheduled for release "soon" (there is a
schedule here somewhere.....)
The Installation Guide and the User's Guide will need to be verified.
From your introduction, that sounds like something that might interest
you. I am sure those team leaders will have more information.
Meanwhile check out:
https://fedoraproject.org/wiki/Docs_Project_content_tasks_for_new_contrib...
Internally, the Docs Project is still in need of much cleanup for our
own process pages and documentation but you can now find most of them
in the Docs Project Category on the wiki:
https://fedoraproject.org/wiki/Category:Docs_Project
We know that they have some inconsistancies so please so not be shy
about asking questions.
Again, welcome.
-Susan
2009/3/27 Wolf DreamWalker <wolfdreamwalker(a)hotmail.com>:
Whoops ... forgot to change the subject title
________________________________
From: wolfdreamwalker(a)hotmail.com
To: fedora-docs-list(a)redhat.com
Date: Fri, 27 Mar 2009 09:57:56 -0400
Subject: RE: Publican Issues
Name: Wolf DreamWalker (not a pseudonym)
Location: Toronto, Ontario, Canada
Profession: Software Trainer
Company: Currently enrolled in the Technical Communications program at
Seneca@York, Toronto
Background
Comfortable with Windows desktop and server products - certified systems
engineer
Have several years experience developing and presenting learning materials
to university students and workers within technical areas of various
companies.
Have tested fan created missions for games such as Thief and even delved in
creating some of the readables.
Great believer in KIS (keep it simple) and have found that screen shots,
etc. are excellent learning tools for those of us who are not computer
naturals
Knowledge of Linux / Fedora
Absolute Newbie ... less than a week old. I'm somewhat intimidated by the
new concepts and perceptions encompassing Fedora but I'm excited to be able
to dig into a few area of expertise.
I've jumped in with a dual-boot install. I thought that all I had to do was
to install Fedora on freed-up space on a single hard drive already occupied
by Microsoft Vista. However, I soon discovered that the two systems
handle "primary" drives somewhat differently and that the only way I could
get a viable working copy of Fedora on my computer was to install it on what
Vista designated as part of the "extended" drive (this variant doesn't
appear to be addressed in the installation guide).
Goals - Where I could help
Since I'm so new to Linux and Fedora I am less likely to miss or overlook
steps that a Fedora expert takes for granted. I'm also more likely to
query what appears to be outdated documentation (e.g. the software's
recommendation to follow what is actually a mandatory procedure to create a
user name and password during installation). At the same time, I recognize
I have somewhat of a learning curve to overcome so probably the best place
to use me is in testing and editing of current material.
Availability
I'm between semesters and have plenty of free time between now and May 9 to
devote myself to this project (at least 40 hrs a week). When I return to
school my time will be limited to only a few hours a week.
Wolf
GPG KEYID and fingerprint
Name: Wolf DreamWalker
Email: wolfdreamwalker(a)hotmail.com
ID: 3117A6BC / DSA / 1024
Created: 2009-03-26
Fingerprint:1462 3928 AF44 6770 F616 925D 6EA6 B659 3117 A6BC
Subkeys:6EA6B6593117A6BC (DSA),A0D3380DAD91D537 (EIGamal)
________________________________
Tell the whole story with photos, right from your Messenger window. Learn
how!
________________________________
Windows Live Messenger makes it easier to stay in touch - learn how!
--
fedora-docs-list mailing list
fedora-docs-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-docs-list
--
Susan Lauber, (RHCX, RHCA, RHCSS)
Lauber System Solutions, Inc.
http://www.laubersolutions.com
gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974
5518
days inactive
5520
days old
21 comments
10 participants
participants (10)
-
Chris Curran -
Eric Christensen -
Jeff Fearn -
John J. McDonough -
Joshua Wulf -
Karsten Wade -
Rahul Sundaram -
Susan Lauber -
Toshio Kuratomi -
Wolf DreamWalker