Guinea Pig Needed

[Draciron Smith]

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 at arrl.net> 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 at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/docs
>