docs March 2005

docs@lists.stg.fedoraproject.org

21 participants
34 discussions

Fedora Project Mailing Lists reminder
by Elliot Lee 16 Mar '05

16 Mar '05

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

1 0

Sample: Release notes nagmail
by Greg DeKoenigsberg 16 Mar '05

16 Mar '05

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

1 0

Re: Wiki and first usage - relnotes for FC4test?
by Rahul Sundaram 16 Mar '05

16 Mar '05

--- 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/

3 3

package diff between FC4 and FC3
by Karsten Wade 15 Mar '05

15 Mar '05

If anyone has time to replace the cruft at: http://fedoraproject.org/wiki/FedoraDocs_2fRelNotes_2fCore4Test1RelNotes with this: http://people.redhat.com/kwade/fedora-docs/relnotes-wip/added.out http://people.redhat.com/kwade/fedora-docs/relnotes-wip/removed.out http://people.redhat.com/kwade/fedora-docs/relnotes-wip/changed.out that would be great. :) I ran a script against dist-fc3 and dist-fc4 to generate a big list of added, removed, and changed, then parsed them into separate files and cleaned them up a bit for easier insertion in the Wiki. For ease, we can probably just include the package changes with version numbers and change arrow -> in a bulleted list. We haven't historically (afaict) done a changed list. Deprecated is subjective. We'll have to get developer input or seek another method to find out what is deprecated. This is probably a good 90% of the truth, possible 100% of the truth, in terms of the difference between the two base installs. - 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/

2 2

Some ideas
by Elliot Lee 15 Mar '05

15 Mar '05

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

1 0

Wiki and first usage - relnotes for FC4test?
by Karsten Wade 12 Mar '05

12 Mar '05

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/

1 1

Re: Status of Fedora docs
by Rahul Sundaram 12 Mar '05

12 Mar '05

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/

3 2

Status of Fedora docs
by Elliot Lee 11 Mar '05

11 Mar '05

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

2 2

Re: Fedora Installation Guide Schedule
by Paul W. Frields 11 Mar '05

11 Mar '05

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=InstallationGuid… > > 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

5 8

Re: Status of Fedora docs
by Rahul Sundaram 09 Mar '05

09 Mar '05

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/

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

docs March 2005