Fedora Project Mailing Lists reminder
by Elliot Lee
This is a reminder of the mailing lists for the Fedora Project, and
the purpose of each list. You can view this information at
http://fedora.redhat.com/participate/communicate/
When you're using these mailing lists, please take the time to choose
the one that is most appropriate to your post. If you don't know the
right mailing list to use for a question or discussion, please contact
me. This will help you get the best possible answer for your question,
and keep other list subscribers happy!
Mailing Lists
Mailing lists are email addresses which send email to all users
subscribed to the mailing list. Sending an email to a mailing list
reaches all users interested in discussing a specific topic and users
available to help other users with the topic.
The following mailing lists are available. To subscribe, send email to <listname>-request(a)redhat.com
(replace <listname> with the desired mailing list name such as
fedora-list) with the word subscribe in the subject.
fedora-announce-list - Announcements of changes and events. To stay
aware of news, subscribe to this list.
fedora-list - For users of releases. If you want help with a problem
installing or using , this is the list for you.
fedora-test-list - For testers of test releases. If you would like to
discuss experiences using TEST releases, this is the list for you.
fedora-devel-list - For developers, developers, developers. If you are
interested in helping create releases, this is the list for you.
fedora-extras-list - For users and developers of Fedora Extras
fedora-docs-list - For participants of the docs project
fedora-desktop-list - For discussions about desktop issues such as user
interfaces, artwork, and usability
fedora-config-list - For discussions about the development of
configuration tools
fedora-tools-list - For discussions about the toolchain (gcc, gdb,
etc...) within Fedora
fedora-devel-java-list - For discussions about Java-related Fedora
development
fedora-patches-list - For submitting patches to Fedora maintainers, and
used in line with BugWeek
fedora-legacy-announce - For announcements about the Fedora Legacy
Project
fedora-legacy-list - For discussions about the Fedora Legacy Project
fedora-selinux-list - For discussions about the Fedora SELinux Project
fedora-marketing-list - For discussions about marketing and expanding
the Fedora user base
fedora-de-list - For discussions about Fedora in the German language
fedora-es-list - For discussions about Fedora in the Spanish language
fedora-ja-list - For discussions about Fedora in the Japanese language
fedora-i18n-list - For discussions about the internationalization of
Fedora Core
fedora-trans-list - For discussions about translating the software and
documentation associated with the Fedora Project
German: fedora-trans-de
French: fedora-trans-fr
Spanish: fedora-trans-es
Italian: fedora-trans-it
Brazilian Portuguese: fedora-trans-pt_br
Japanese: fedora-trans-ja
Korean: fedora-trans-ko
Simplified Chinese: fedora-trans-zh_cn
Traditional Chinese: fedora-trans-zh_tw
19 years, 1 month
Sample: Release notes nagmail
by Greg DeKoenigsberg
This is your [ daily|weekly|fortnightly|monthly ] reminder, from your
friendly docs team, to remember the poor souls who toil in darkness to
write relevant release notes for all of our projects.
How can you help? It's simple!
1. If you're closing a bug, set the customer-facing flag. Read more
about how this work HERE [ wiki link tbd ].
2. If you're checking something into CVS that seems noteworthy,
include RELNOTE in the body of the checkin message. For example:
"RELNOTE: redhat-config-toast now accepts the --margarine switch."
Read more about how this works HERE [ wiki link tbd ].
3. If you'd rather just send a note about what you're doing and how
things are changing, just send a note HERE [ email address tbd ],
and we'll figure it all out.
===
And then maybe a funny story about how an engineer's failure to update
release notes resulted in an FC4-controlled trolley car running into a bus
full of nuns, and the resultant tragedy. Or some such. Keep 'em
guessing. :)
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
19 years, 1 month
Re: Wiki and first usage - relnotes for FC4test?
by Rahul Sundaram
--- Karsten Wade <kwade(a)redhat.com> wrote:
> On Sat, 2005-03-12 at 08:09 -0800, Karsten Wade
> wrote:
> > We have discussed in the past using a Wiki for
> Fedora docs needs, and
> > suddenly finding a desperate need for one, I
> filled out some pages and
> > started a Wiki page for release notes for
> FC4test1.
> >
> >
>
http://fedoraproject.org/wiki/FedoraDocs_2fRelNotes_2fCore4Test1RelNotes
>
> Note: The Wiki has a flat file structure under
> /wiki/, so it simulates
> slashes by making them part of the Wiki-name. For
> URLs, these slashes
> are converted to "_2f", so the above path on your
> Wiki screen is:
>
> FedoraDocs/RelNotes/Core4Test1RelNotes
>
the information in the release notes includes which
srpm packages where removed and which rpm packages
were added to the system. I guess this information is
available from redhat's build system. It would nice to
have a script or any automated way to find out what
has changed between say fc3 and fc4 test1 and so on.
Regards
Rahul Sundaram
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
19 years, 1 month
Some ideas
by Elliot Lee
Hey, thanks for the status info from everyone! From my perspective, there
are two main pieces of content that I'd like to suggest about focusing on:
Release notes
You are already on top of this for test2 by the sound of it. :-) The wiki
seems like it will work for now until we can get CVS for y'all. We do need
to figure out a good way to get change notices from the developers. The
previous relnotes maintainer said one of his big frustrations was getting
developers to respond to a request for notes.
Release announcements
The part where you get to have fun, be creative, and not work too hard.
The Fedora marketing people may have input here, and some coordination
with developers and mirror admins would be necessary. The way I imagine
this working is that you could maintain a template 'announcement'. About a
week before each release, you could start with the template fill in a few
highlights from the relnotes, start creating the list of mirrors, and
think up ideas for the "theme" of the announcement. The day before the
release, you'd fill in the final list of mirrors, and then post the
announcement on the day of the release.
These are two ongoing things that happen over and over at every release
point, and they really tie together as far as deadlines and content go.
This is not meant to take away from the install guide work at all - it can
still be worked on, and there's definitely a need for it. However, the
install guide is a lot of work, and I'd rather see you guys do well at a
few basic things than burn out not finishing a very big project. Once the
Fedora docs project has grown to have more infrastructure and more
contributors, you can add a focus on bigger projects like the install
guide.
One thing I did for the index.html page in FC4test1 was put in a link to
http://fedoraproject.org/wiki/FedoraDocsProject - hopefully that will help
you get more contributors.
These are just suggestions - you guys are the ones who are putting all the
hard work in, and that means you get the final say (e.g. if the install
guide is the only thing interesting to Stuart, it stands to reason that
he's going to keep working on it :-) It's really cool to see people active
in the docs project, and once docs CVS happens, hopefully you'll have
other ideas about infrastructure you need to make FDP successful.
Does this all make sense? Comments/questions welcome!
-- Elliot
19 years, 1 month
Wiki and first usage - relnotes for FC4test?
by Karsten Wade
We have discussed in the past using a Wiki for Fedora docs needs, and
suddenly finding a desperate need for one, I filled out some pages and
started a Wiki page for release notes for FC4test1.
http://fedoraproject.org/wiki/FedoraDocs_2fRelNotes_2fCore4Test1RelNotes
There is now a page about this project and a canonical page of Wiki
docs:
http://fedoraproject.org/wiki/FedoraDocsProject
http://fedoraproject.org/wiki/FedoraDocs
In anticipation, I have made up my own Q&A:
Why?
It hasn't been otherwise done and it needs to get done, but there isn't
time to gather notes in bugzilla and make a pretty DocBook page.
What release notes are shipping in FC4test1?
AIUI, not much. Probably just a copy of the FC3 relnotes. Essentially,
anything we can gather on a Wiki page will be useful for the short-term.
Should we continue to do the relnotes in a Wiki?
I don't know. We'll have to watch this experiment and see how it works
out.
What do we need to get this relnotes ready now?
Developers to contribute whatever they can think of that needs to be in
a release notes. A group of us to watch those contributions, edit them,
and add in whatever else we can.
This also lets us test the idea of gathering information from developers
via Wiki, and seeing if we can convert it to DocBook without too much
pain.
The older method of using bugzilla submissions was hard enough when all
the developers were paid to do documentation. Community developers need
to be able to work in a way that is comfortable to them, or we won't get
many docs out of them. Just MHO, but ...
How does a editor/writer get involved?
Create an account at fedoraprojects.org and contact a person in the
editing group (e.g., me) to get you added for editing permissions. I
decided to *not* do a separate docs editors, figuring having
writers/editors with full permissions to edit the Wiki is a Good Thing.
When you setup your preferences page, you need to mark the relnotes page
as a watched (subscribed) page, aiui.
Tell me what you think.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Learn, Network and Experience Open Source.
Red Hat Summit, New Orleans 2005 http://www.redhat.com/promo/summit/
19 years, 1 month
Re: Status of Fedora docs
by Rahul Sundaram
Hi
> Oops, I misspoke here. John is not doing Fedora
> release notes. FC
> relnotes are entirely a community affair at this
> point.
>
I am not sure how you call release notes written by
internal developers themselves a community affair
> Is there anyone interested in working on the
> relnotes? You get extra
> exposure to developers, if you don't have enough
> already :), learn lots
> of interesting and esoteric stuff, and often more
> know about a given
> test, rc, or release than you thought possible.
I am. I would prefer to work on it as a team. So It
would be nice to have a few more interested volunteers
to work with me on this
My first proposal, therefore, is that
> we use the Wiki to
> create a release notes page for every test, rc, and
> release, and
> browbeat developers into contributing.
Oh. I am pretty good at nagging people on technical
stuff :-)
Regards
Rahul Sundaram
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
19 years, 1 month
Status of Fedora docs
by Elliot Lee
Hi all,
I'm just learning about this corner of the Fedora world. :-) I'm wondering
what you Fedora documenters have been working on, who's involved, what the
frustrations are, and what plans you'd like to turn into reality. I did
notice Stuart's work on the Fedora Install Guide - very cool - and no
doubt there is a lot of other work that needs recognition and integration.
Thanks for your efforts - how can I help with them?
-- Elliot
19 years, 1 month
Re: Fedora Installation Guide Schedule
by Paul W. Frields
Portions of a conversation Stuart and I have been having offlist WRT the
Fedora Installation Guide:
On Sat, 2005-03-05 at 18:29 +0000, Stuart Ellis wrote:
> > There are significant sections on RAID and LVM that (I think) are pretty
> > much required, so that a new user can figure out how to set them up.
>
> Very much agree. I don't think that we can reasonably say that LVM is
> just an advanced option any more, even if it's a pain to document.
> Having mind-bending amounts of less reliable storage available for
> peanuts makes these technologies pretty much mandatory...
That said, I think that many hobbyists (and I'll put myself in among
them) still tend to use physical partitions as "directly formatted"
ext3. I'm not planning on adding and removing disks on my home
workstation, and neither are many users. Nevertheless, you and I are in
complete agreement that RAID/LVM must be fleshed out in the installation
guide... especially since anaconda uses LVM for automatic partitioning
these days.
> > If I have to sacrifice those sections to get this thing out for FC4
> > test2, I will, but I will keep working on them nonetheless.
> > I am currently using FC3 to do my writing, but I will have FC4 test1
> > (almost) as soon as it is issued.
>
> This was really what I felt we needed to work out - there's enough stuff
> in the TODO to keep Mayank and I busy until you are ready, and IMHO it
> helps if we all stick to the same version (whether it's the latest or
> not). If you are happy to move up to test 1 then I'll do a roll-up
> release and switch development after test 1 comes out, with a new target
> of test 2 for a public beta release. What worried me was the risk of
> things drifting or getting into a muddle later if we didn't agree
> something at this stage.
Mm, hadn't thought enough about the ramifications, you're right. Look, I
think it would be much easier to stick with FC3 until FC4 final is
issued. I know that means we might be "off target" for a week or two
until we update, but it's easier than trying to "track" changes between
FC3, FC4t1 and FC4t2 -- just in case anaconda has some niggling change
between test releases.
> > You can see what I've done at http://svn.frields.org if you are interested.
>
> OK, I've read through them, but won't make any nit-picky comments since
> they're works in progress. Following from the above, though, it might
> be worth assuming that LVM is the standard way of doing a manual
> partition layout, and push that further up the text, perhaps even
> deprecating directly partitioning the drives (just a thought - I don't
> know if this is entirely reasonable). As a parallel, I ended up
> deprecating static IP addressing for anything other than servers,
> because I realised that it wasn't actually the best approach in most
> scenarios any more (NetworkManager, plus cheap DHCPing routers and WAPs
> all over the place).
See my comments above; I still think LVM is not a requirement for an
installation just because the installer uses it in the "autopilot" mode.
It does that in order to support a broader base of administrators who
don't know yet that they might want LVM. As a consequence the guide must
address LVM.
However, injecting a discussion of LVM (or RAID) into the procedural
flow about how to use the anaconda installer is a bit distracting,
though. These sections exist to backstop the installation process rather
than to push people toward a technology. They are enabling technologies
for the situations that call for them. I'm not sure which version you
saw and what I'd completed by the time I'd emailed you. Right now I plan
on making frequent calls to the RAID and LVM subsections using <xref>
where called for, and I think that will make everyone comfortable when
they read it.
> Another vague suggestion is that the Appendix might be easier to tackle
> by structuring it around the use cases (workstations and laptops would
> be probably use Automatic partitioning, or just have a separate /home)
> and maybe de-emphasising the hardware specifics. Most servers and
> workstations I've seen use IDE CD drives with SCSI hard drives and
> tapes, or (recently) just SATA. (S)ATA RAID is apparently now fairly
> common on enthusiast mainboards too, so I guess that the boundaries are
> getting very blurry.
Many legacy boxes are being coverted to Linux, however... which really
proves your point. That's why I would like to de-emphasize the "let's
explain technology" angle, and instead focus on the procedure first and
foremost, referring to specific sections on enabling technologies where
appropriate.
> FWIW, I've written up a documentation plan to try to summarise for
> Mayank (and any future contributors) the aims and requirements I've been
> working towards with the text:
>
> http://www.mythic-beasts.com/~hobb/main/index.php?pagename=InstallationGu...
>
> The current version is just a brain dump - comments and corrections are
> very welcome.
This is good info for anyone trying to contribute to the IG. One thing
that occurred to me while reading: I think that relying on the built-in
help screens of a program is not a commonly accepted method for doing
system documentation. It definitely saves a little time, but in terms of
a readable document, simply providing extra material in the absence of
the basic procedural support is going to result in a document that's
much harder to read. There's nothing wrong, for example, with simply
reproducing what's already in anaconda in the IG, as long as the
terminology is supported and the style is consistent. We have a couple
documentation experts at work whom I will ask this question if I can get
them off the keyboards long enough.
--
Paul W. Frields, RHCE
19 years, 1 month
Re: Status of Fedora docs
by Rahul Sundaram
Hi
>
> I don't see the RHEL docs license changing from OPL
> to FDL, but the OPL
> seems to allow you to do quite a bit with the
> content. Does this help at
> all in providing a base for the content you want?
>
> Best,
> -- Elliot
>
unfortunately not. fedora docs are to be licensed
under GNU FDL. RHEL docs are licensed under OPL and
these two licenses are incompatible with each other
which means we will have to rewrite them for fedora
from scratch . If RHEL docs cannot be relicensed under
GNU FDL for any reason (I would like to know why) then
it would be a better idea to allow fedora docs to be
licensed under OPL
Regards
Rahul Sundaram
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
19 years, 1 month