Annotation notes. > will proceed quoted text from the instructions. * indicates question about procedure or instructions # indicates comment or suggestion #For a concrete example I'll assume we are going from FC34 to FC35 to just pick two #totally random version numbers. At one point you mention FC12 and that was a good #convention you should have applied all through the doc. * Any software that needs to be installed prior to attempting this? >Copy the contents of this directory to that scratch directory # What dir? Be more specific. # example syntax cp -r /fc34/* /data/scratch/ * Any hidden files that a recursive cp won't catch? Would making a tarball be easier and *more effective? >Copy the primary.sqlite from the previous version into old/. Note >that this should be a version saved from the previous release of >Fedora, NOT the current contents of that repo. The f12/ subdirectory >of this directory contains the original Fedora 12 file. *What? The previous instructions seem to assume just 2 versions old and the new/current. *This paragraph alludes to other versions which is rather confusing. Using the 34 to 35 *conversion example do you mean to copy the sqlite from 34 to old? # Give quick command line example cp /fc34/.sqlite /fc35/old/ >Note that this will have all sorts of junk on >the beginning of the name that must be removed. *Is the goal just to create a legal file name? Why not a quick bash script to take care of this *which takes an input of current or old version? This will ensure a consistent file name and *possibly allow further scripting down the line. >Note that the file will have some very long name, but the one you >want ends in primary.sqlite.bz2. Download it, rename it to >primary,sqlite.bz2, bunzip2 it, and you should be left with a >primary.sqlite in both the new/ and old/ directories. *If your going to just unpack the file why rename it? # move the new primary.sqlite to the /new dir >./doit.sh *What dir is this script located. If you were in /new would it work or do you need to be in */new to see the script or is that script something you have to download separately.? >Copy all the *.xml's to the en-US/ directory * Of /new I assume but would be good to specify. #Sample command line would be a good idea here. cp *.xml /new/en-US/ >Copy Changes.xml into Technical_Notes.xml * Did you mean Copy Changes.xml to Technical_Notes.xml # cp Changes.xml Technical_Notes.xml >Edit Technical_Notes.xml to group the includes into a few chapters. #Suggested groupings? Hopefully this helped. On Thu, Apr 22, 2010 at 10:59 AM, John J. McDonough <wb8rcr@xxxxxxxx> wrote: > As you may be aware, the Technical Notes are produced almost entirely > automatically. What you may not know is that, with the exception of the > first section, they are produced entirely from scratch. > > Up until now, I've been the only one producing these. This isn't good. > Someone else should be able to make these notes in my absence. > > To that end, I've tried to document the process, and heavily script it. > Trouble is, sometimes my writing sounds more like Klingon than English, > and I can't always tell the difference. > > What I need is for someone to follow those instructions and make an > updated Technical Notes, perhaps enhancing the instructions along the > way. > > This process is pretty quick, perhaps 15 minutes or so. If you would > like to try it out, my instructions are in the git for technical notes. > The direct link is: > <http://git.fedorahosted.org/git/?p=docs/technical-notes.git;a=blob_plain;f=build/README;hb=7a5b49619c903da6253c5f662d728403d4a30a9c> > > We actually need an update in the next couple of days, and it would be > good if that update came from someone other than me. > > Thanks > --McD > > > -- > 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
