we have 19:12:24 the sections have an 'id' attribute that you can use for links 19:12:33 sections always have a title 19:12:37 sorry. jas 19:12:53 those files are going to be under Common-Content? 19:13:19 no, the common content comes from the brand, it's the same for every guide 19:13:46 nvm. got it 19:14:01 ok 19:14:28 inside the sections we put whatever structural elements are appropriate; paragraphs, lists, notes, etc 19:14:39 ok 19:15:23 The important thing to remember is that XML tags must always be closed, like this: words 19:15:43 ok 19:15:53 and there are rules about what elements can be parents of others, and what they can be children of 19:16:16 Do we actually edit these files, or do we edit other ones and then after approval, bring it in? 19:16:33 Ok, let's talk about that process 19:16:49 Sounds like I need to get up to speed on XML... 19:17:03 :) this is specifically docbook XML 19:17:16 ok 19:17:35 docbook.org has a good overview, and out documentation guide has some on it - you'll get the feel for it as you go along, I think 19:18:01 will be up there later tonight to get the scoop 19:18:09 RogerB_TX, don't worry too much about all the possible tags and the xml and such at first. It's a lot easier to write first, and mark up later 19:18:22 great. whew! 19:19:13 if you keep the structure very basic, I can help with the markup from there. 19:19:38 that said, let's go over how to share your work 19:19:47 ok 19:20:20 if you have the appropriate privileges, you can commit your changes directly and push them. terms that might not mean anything right now, but we'll get there :) 19:20:29 :) 19:20:42 for now, pick a file to edit 19:21:14 ok.UEFI.xml 19:21:53 Sure 19:22:14 Make a simple change; an introductory sentence maybe. 19:22:20 ok. jas 19:22:59 you can also add or remarks have inheritance rules but don't appear in the build 19:23:09 those are useful for outlining and such 19:23:14 I wrote "First Time Edit": 19:23:15 19:23:15 First Time Edit 19:23:51 That won't work; you have content without a home in the XML structure 19:24:00 put it in a comment or remark block 19:24:15 ok. so. I should mark that with 19:24:58 19:25:03 yup 19:25:12 now save the file and go back to the terminal 19:25:13 ok 19:25:16 ok 19:25:34 done 19:26:04 one sec 19:26:32 now, we want to tell git to create a 'branch' for your work 19:26:38 ok 19:26:58 the branch will give you a personal workspace, and a way to track your changes against the 'master' branch 19:27:08 cool 19:27:16 like this: git branch callitwhatyouwantitisyourbranch 19:27:19 this is alot like using source code from a git repository 19:27:34 heh, it *is* source code from a git repo 19:28:03 then check out your branch, `git checkout branchname` 19:28:11 git branch RogerBTXContributions 19:28:56 great 19:29:01 Switched to branch 'RogerBTXContributions' 19:29:49 now you want to commit your change. like this: `git commit en-US/UEFI.xml -m "some message that explains to your fellow contributors the change you are committing" 19:31:34 [root@localhost en-US]# git commit en-US/UEFI.xml -m "First Time Edit performed under the tutilage of randomuser" 19:31:34 error: pathspec 'en-US/UEFI.xml' did not match any file(s) known to git. 19:32:13 wrong directory to issue the command? 19:32:21 wait a minute 19:32:25 k 19:32:26 why are you doing this as root? 19:32:36 dont know 19:32:42 drop root 19:33:16 yes; move your files to your normal user directory, chown -R username /path/to/directory, then drop root 19:33:23 the publication directory is off the root as /publish 19:33:29 ok 19:33:30 jas 19:33:58 as a rule of thumb, don't do anything as root unless you *know* there is a damn good reason to 19:34:55 and actually, let's hold off and not commit for a minute 19:35:02 there's one thing it would be good to do first 19:36:03 `git config --global user.name "Roger ROgerslastname"` and `git config --global user.email "your@email"` 19:36:07 ok. jas 19:36:50 then go ahead with the commit. You can execute git commands from anywhere inside the repo, but remember paths are relative 19:38:40 ok. got everything moved over, chown'd and exited root. doing next task... 19:38:47 ack 19:42:42 ok. ready to run the first commit 19:43:19 ok 19:44:21 [pentest@localhost Publish]$ git commit en-US/UEFI.xml -m "First Time Edit performed under the tutilage of randomuser" 19:44:21 fatal: Not a git repository (or any parent up to mount point /home) 19:44:21 Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). 19:44:47 sounds like you need to cd to the correct directory 19:44:54 ..... 19:46:13 I have to get to the guide level, right? 19:46:37 multiboot-guide 19:46:38 right; the root of the git repo will be the one with publican.cfg in it 19:46:42 ok 19:46:44 jas 19:47:16 woohoo! [pentest@localhost multiboot-guide]$ git commit en-US/UEFI.xml -m "First Time Edit performed under the tutilage of randomuser" 19:47:17 [RogerBTXContributions 41d3c67] First Time Edit performed under the tutilage of randomuser 19:47:17 1 file changed, 1 insertion(+), 1 deletion(-) 19:47:35 nice 19:47:39 :) 19:47:54 ok. so now I have my own branch to work with... 19:48:08 now, if you had commit privileges, you could do 'git push' and everyone would get those changes when the did a 'git pull' 19:48:24 until then, do this: `git format-patch master` 19:48:33 Who watches over my branch and decides what will be incorporated and what will not? 19:48:35 ok 19:49:32 it will create one file for each commit in your branch 19:50:20 you can email those files to me, or to the docs list, and we can apply them to the repo and bring your changes into the master branch 19:50:43 it will do content changes, commit messages and history, everything 19:50:54 email the files that are created by the commit process, right? 19:50:59 right 19:51:30 how often do I want to do a git format-patch master? Once before each writing session? 19:51:48 as often as you want to share your commits 19:52:08 How will we avoid duplication of effort on a given area? 19:52:20 We'll have to talk about it 19:52:57 I will be seeing everyone else's updated work each time I do a patch-master, right? 19:53:24 no, `git format-patch` only creates the patch files 19:53:25 format-patch master... 19:53:32 oh. ok 19:54:01 so here's what I'd suggest: create a branch for a specific task, ie 'git branch uefibootmgr-instructions' 19:54:18 then make a series of edits and commits related to that task 19:54:24 ok. so, that command is creating delta's against what i have changed and the master. Those files are the ones that you will look at... 19:54:30 yup 19:55:10 when they are applied, you can check out the master branch and do a `git pull` 19:55:52 ok. right now I have a branch established for the multiboot-guide. I will be establishing a separate branch for each project I am assigned to work on -- even within the same guide? 19:56:15 then, go back to your private branch and `git merge master` will bring it back in sync. Or, you can declare the work done and start a new branch after your branch is merged in 19:57:19 the main utility of having a separate branch from master is to generate that delta file. After that, it's whatever organizational structure seems appropriate 19:57:33 convention is to branch based on intent 19:58:09 honestly, we don't have a formal process for this part because not a lot of people have done it 19:58:35 ok. so, for now, I stick with the multiboot-guide as my branch (since I have already established it as a fork) and from there contribute to a particular section, and then send along the delta files... 19:58:51 right 19:58:56 got it 19:59:01 whew! 19:59:15 I now how hard it is to get those newbies inline! :) 19:59:19 hehe 19:59:23 you have done a great job! 19:59:42 I am saving this to a log for future reference... 19:59:53 Thanks! 20:00:21 Is there a handy-dandy cheat sheet for these commands/processes somewhere? 20:00:25 You might also want to grab the guide from https://git.fedorahosted.org/cgit/docs/documentation-guide.git/ 20:00:32 nvm. I will just write it myself. :) 20:00:34 it's rough, but it has a lot of this info 20:00:44 ok 20:01:07 and if you spot something missing, incorrect, etc feel free to make changes there, or at least complain :) 20:01:16 hehehe ok 20:01:43 any questions about that process so far? 20:01:50 ok. gonna run for now. Thank you again for your help. I will review the guides and get back with you soon. 20:01:58 No questions for right now 20:02:02 ok 20:02:06 take care! 20:02:24 I do think there are a few misconceptions in your ask post we should talk about later 20:02:31 but I too should move on with the day 20:02:53 ok. sounds good - lets talk tomorrow??? 20:03:04 give me a time... 20:03:42 BTW, all of my testing so far has been with NST 20. I should stick strictly to Fedora 20 for everything here, right? 20:03:45 well, I only block off daytime for this (UTC-0600) on thursdays, but I'm in and out all day 20:04:02 ok. 20:04:04 yes, you should very strictly stick to Fedora 20:04:13 got it. 20:04:27 Well, some Thursday soon then... 20:04:34 adios 20:04:40 evenings would be easier for me - and there's email too 20:05:16 randomuser: Bah... I'll just wait for nb_. It's not uber urgent. 20:05:26 RogerB_TX, later, thanks for stopping in! 20:05:37 randomuser: Plus, I think Fedora Infrastructure is already using the latest/greatest. 20:06:01 tsk tsk, Sparks - a missed opportunity to be disruptive 20:07:34 Sparks, that piratepad is still live, if you wanted to help make some headway on the firewall guide scope 20:13:08 It would be nice to have a defined scope, build an outline, and generally get it ready to farm out discrete tasks from 20:48:35 Good night 21:57:26 Does anyone know the command line to verify that hexchat is indeed using an encrypted connection? 21:58:14 I put in the settings to use SSL for all servers, but I am not sure how to verify it... 22:06:29 you could use SASL for IRC; that either fails or does not 22:06:29 nvm. All I need to do is fire up WireShark first, connect to HexChat, capture the connection and analyze. 22:06:42 tks 01:04:02 office hours are long nowadays 01:04:19 .listmeetings 01:04:19 nb: ('#fedora-docs', 'freenode'), ('#fedora-meeting', 'freenode') 01:04:21 wow 01:04:28 .addchair #fedora-docs freenode nb 01:04:28 nb: Chair added: nb on (#fedora-docs, freenode). 01:04:31 #endmeeting