Hi Pete
Is it a good idea to ask for teams of three to work together on a single part. As it is listed below, without a project leader, many individuals are going to duplicate the efforts of others. That will be too much wheel spinning.
I would divide the challenges into what would be a 4 hour shot. I would then repost saying, please submit your name if you are able to handle one of the quantums of work.
Grub2 and yum (its replacement) are under documented. Parcel it out. No "free for all" please.
Is it a good idea to ask for teams of three to work together on a single part. As it is listed below, without a project leader, many individuals are going to duplicate the efforts of others. That will be too much wheel spinning.
I would divide the challenges into what would be a 4 hour shot. I would then repost saying, please submit your name if you are able to handle one of the quantums of work.
Grub2 and yum (its replacement) are under documented. Parcel it out. No "free for all" please.
Regards
Leslie
alternative: leslie.satenstein@xxxxxxxxx
SENT FROM MY OPEN SOURCE LINUX SYSTEM.
Leslie
Mr. Leslie Satenstein
An experienced Information Technology specialist.
Yesterday was a good day, today is a better day,
and tomorrow will be even better.
lsatenstein@xxxxxxxxxAn experienced Information Technology specialist.
Yesterday was a good day, today is a better day,
and tomorrow will be even better.
alternative: leslie.satenstein@xxxxxxxxx
SENT FROM MY OPEN SOURCE LINUX SYSTEM.
From: Pete Travis <me@xxxxxxxxxxxxxx>
To: jreed@xxxxxxxxxx; For participants of the Documentation Project <docs@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, May 27, 2013 4:56 PM
Subject: Improving copy about GRUB
Hi Jack, writers:Grub problems are relatively common, and intimidating to the average end user. UEFI compounds these difficulties. While we have solid content on these topics in the Installation Guide, I think it could be updated and organized. Related issues come up often in #fedora, http://ask.fedoraproject.org, mailing lists, and forums. I've put together a change proposal for your review, with the aim of providing information that more directly addresses the users' needs. Here's what I came up while with skimming through the IG:==============================================- Gather notes from other docs members on grub. If anyone has some content stashed away that could be useful, it would be great to use it instead of rewriting.- Build on the section dedicated to manual installation of the bootloader. This will cover:* Booting into rescue mode, via reference to rescue mode section* Manually setting up a chroot if rescue mode is not available.* Regenerating grub config, ie `grub2-mkcondig` .* Installing grub on BIOS/MBR UEFI systems* Choosing default and next boot selection* usage of efibootmgr. Limit explanations of hand-writing of config files to the existing grub appendix.- In section 9.10.1 - In addition to usage during installation, this section addresses the general definition and purpose of a bootloader. Move the general explanation to the bootloader section, and provide a link to it. Also insert a link to new bootloader section.- Move relevant information, ie regenerating config files, from the troubleshooting section to the new bootloader section and refer to it.- Update procedurals and examples in the troubleshooting section to make sure they apply to GRUB2 usage and not GRUB legacy, especially with regard to grub prompt usage. Possibly substitute grub prompt usage for a more detailed section of the GRUB appendix.- Provide a description of appending and editing boot arguments. if appending or removing arguments is required, simply state ie 'append "single" to the boot arguments' and refer to this description.- Update the "Installing without media" as needed, with most if not all of the procedure staying instead of substituting with references.- remove widespread references to grub splash image; we don't ship that by default any longer. Add something about splash images to a grub customization section.- Substitute references to GRUB sections for procedural content in FedUP section as needed. Ensure enough of a high level overview remains in the fedup section that users know how to use the information referenced, but remove exact commands, etc. A lot of this is related to the F17 -> F18 upgrade and change from grub-legacy to grub2-efi, and not as relevant after.- Admonishment that fedup is only for F17-> F18 should read F17 and after, or be removed entirely. Not really in the scope of this proposal, but notable anyway.- Update grub features copy to include support for non-ext2 volumes, or defer list of supported volume types for a dedicated paragraph or section.-Generally verify the content of the GRUB section as a whole, and make changes if needed.- Update Changing runlevels section to reference new 'appending boot arguments' copy and refer to systemd target list in systemd appendix- Give a brief but more thorough overview of creating custom boot configurations, including usage and purpose of /etc/grub.d/40_custom and friends- Examine boot-init-shutdown and grub appendix for overlap, leaving boot process info in the former and detailed grub information in the latter.- Examine rescue mode section and grub appendix for overlap, and removing redundancies and adding references if needed.==================================================Does this work with your plans for the Guide? I'd like to get your thoughts, and change the plan based on input from you and the group before beginning.Thanks,-- Pete
--
docs mailing list
docs@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/docs
-- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
